9:56 a.m.
It's really a pain when you are developing a multifaceted change to the
application server and it hangs. Sometimes, if you're lucky, you can
stick jconsole on there and figure out at least a general idea of what
is going on, or reproduce the problem by running a test, a test class,
or a test module in isolation with debugging turned on. Sometimes
you're not so lucky, or sometimes the hang happens in the manualmode
test suite where you have to attach a debugger 9,000 times only to find
out that the hang doesn't happen when you do that.
I think we should introduce a new build profile which activates the
remote debugging port, but with suspend=n. This would allow entire full
test suite runs to be done while allowing debugger to be attached for
exploratory surgery in the event that something goes wrong. While it's
possible that having debugging activated might actually prevent the hang
you care about, at least there's a chance that something can be done.
--
- DML
5:20 p.m.
You could just make it a property too. Maybe something like debug.suspend
that defaults to "y". Either way I think it would make sense.
On Fri, Apr 14, 2017 at 7:56 AM, David M. Lloyd <david.lloyd(a)redhat.com>
wrote:
It's really a pain when you are developing a multifaceted change
to the
application server and it hangs. Sometimes, if you're lucky, you can
stick jconsole on there and figure out at least a general idea of what
is going on, or reproduce the problem by running a test, a test class,
or a test module in isolation with debugging turned on. Sometimes
you're not so lucky, or sometimes the hang happens in the manualmode
test suite where you have to attach a debugger 9,000 times only to find
out that the hang doesn't happen when you do that.
I think we should introduce a new build profile which activates the
remote debugging port, but with suspend=n. This would allow entire full
test suite runs to be done while allowing debugger to be attached for
exploratory surgery in the event that something goes wrong. While it's
possible that having debugging activated might actually prevent the hang
you care about, at least there's a chance that something can be done.
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
3:46 a.m.
Welcome to the WildFly debugging hell David.
The situation is even more complicated than it seems at first sight.
There are tests (in domain test suite for example) when
there are started multiple host controllers
and servers there, each of them binding
to different port. The 'new build profile' proposal should also
address different debugging ports for
all those 'domain controller', 'host controller' and 'server'
processes.
Richard
On 04/14/2017 04:56 PM, David M. Lloyd wrote:
It's really a pain when you are developing a multifaceted change
to the
application server and it hangs. Sometimes, if you're lucky, you can
stick jconsole on there and figure out at least a general idea of what
is going on, or reproduce the problem by running a test, a test class,
or a test module in isolation with debugging turned on. Sometimes
you're not so lucky, or sometimes the hang happens in the manualmode
test suite where you have to attach a debugger 9,000 times only to find
out that the hang doesn't happen when you do that.
I think we should introduce a new build profile which activates the
remote debugging port, but with suspend=n. This would allow entire full
test suite runs to be done while allowing debugger to be attached for
exploratory surgery in the event that something goes wrong. While it's
possible that having debugging activated might actually prevent the hang
you care about, at least there's a chance that something can be done.
2774
days inactive
2778
days old
2 comments
3 participants
participants (3)
-
David M. Lloyd -
James Perkins -
Richard Opalka