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."