Just curious, why is it trying to decomplile xerces? Do we not filter on customer
packages yet?
Brad Davis
Senior Manager, Red Hat Consulting
Email: bdavis(a)redhat.com | c: 980.226.7865 |
http://www.redhat.com
----- Original Message -----
From: "Jess Sightler" <jsightle(a)redhat.com>
To: windup-dev(a)lists.jboss.org
Sent: Wednesday, October 15, 2014 12:14:44 PM
Subject: Re: [windup-dev] Windows Issues
When I ran it on Windows with decompiling set to all packages (as I assumed you did), it
hung while decompiling xercesImpl.jar (I could tell this from the logs). Looking on disk,
there was a 0 byte file CoreDocumentImpl.java that appeared to be the last thing it was
working on.
So, I ran both Procyon 0.5.25 and 0.5.26 on it on Fedora, and both have hung in exactly
the same place. This is obviously not a platform specific bug. I'll try to file this
upstream with the procyon maintainer.
On 10/15/2014 10:06 AM, Ondrej Zizka wrote:
I am getting to it tomorrow (going to a JBUG with Mark Little today).
I have a SSD on linux and HDD on Windows. Not sure how I/O heavy decompilation is, I
assume not much. I don't have/know any free I/O analysis tools on Windows. But
I'll set up breakpoints and check what's going on.
Ondra
On 14.10.2014 20:53, Jess Sightler wrote:
We also need to know whether it is actually getting stuck (and taking >1 minute/class).
Do we maintain any stats like that at the moment?
On 10/14/2014 02:52 PM, Lincoln Baxter, III wrote:
In theory, this is a good idea, we probably do want to limit the amount of time spent on
each class.
However, simply running decompilation in a separate thread will likely not allow us to
interrupt the thread. We'll need to figure out where Procyon is running, and if it
actually responds to Thread.interrupt() (I'm betting it doesn't.) (And how to make
sure that it does, which will likely take some extension or modification of Procyon
itself.)
This is definitely something to look in to over the next few weeks/months as we harden
this first version of the tool.
On Tue, Oct 14, 2014 at 1:42 PM, Brad Davis < bdavis(a)redhat.com > wrote:
I think we could maybe create the decompiler as a runnable, and interrupt the thread with
a timeout if the decompiler takes more than a minute for a class, which should be plenty
of time. We should log this, though, to make sure they are aware that one of the classes
did not successfully decompile.
Brad Davis
Senior Manager, Red Hat Consulting
Email: bdavis(a)redhat.com | c: 980.226.7865 |
http://www.redhat.com
----- Original Message -----
From: "Ondrej Zizka" < ozizka(a)redhat.com >
To: "Windup-dev List" < windup-dev(a)lists.jboss.org >
Sent: Tuesday, October 14, 2014 11:55:17 AM
Subject: [windup-dev] Windows Issues
Hi,
I've tried on Windows 7 64bit, Oracle JDK 1.7.0_67.
The tests fail with WINDUP-335 and WINDUP-332 .
The run against Tim's EAR get stuck on Decompilation for about 8 hours, seems it's
in an endless loop. WINDUP-337
Is Windows a priority? Do we have estimation on what portion of users will run on Windows?
Ondra
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
_______________________________________________
windup-dev mailing list windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev