• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is it possible to do remote debugging without block the server normal functioning?

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I work on a huge Java web application that runs on a Weblogic server.
Every time that an issue occurs I have to replicate the whole environment on a local Weblogic server to run the Java debugger (and this causes a lot of configuration problems and time wasting).
I would like to know if there is some method to connect the debugger directly to the original server without block the whole server when I reach my breakpoint (the server should continue to serve the normal requests as usual during my debugging session).
Maybe there is a manner, for example, to automatically create a separate JVM instance when I connect my debugger to the remote debug port so that only this instance is blocked at the breakpoint and the server continue to work as usual?
I have not much experience about the remote debugging but I suppose that I'm not the first one to have this need, how this situation is managed as best practice in general?
Thanks and best regards,
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all, if you were to attempt to run a debugger against a production machine in most shops I've worked in, management would be descend on you with fists and clubs (or the business equivalent). And in a lot of cases, I'd be one of the senior support persons who would also be extremely unhappy. I won't even let myself do that.

I design my webapps in such a way that the exact same WAR (or EAR) will run on a test machine as it does on the production machine precisely so that when a production app breaks down I can replicate the exact code byte for byte on a "safe" platform. I realize that it's difficult, expensive and painful to replicate a large and complex database and/or a heavy workload in a test environment, but that's the kind of practice that distinguishes a true Enterprise operation from a bunch of school children playing programmer. Since the test and production servers should be using separate databases and other such services, the instance-specific configuration should all be coming from the application's deployment descriptor for that WLS instance, not hard-coded into the WAR or EAR.

I'm afraid that a single instance of WLS is expected to be the sole application running in its JVM and that a WLS instance cannot span over multiple JVMs. It's strictly 1-to-1, so again, you need to do your debugging on a test WLS instance. You DEFINITELY don't want production and test webapps running in the same WLS instance/JVM.

Beyond that, a remote debugger's breakpoints operate at the thread level. If an application hits a breakpoint, that particular thread will suspend while you debug it, but all other threads continue running unless either A) they, too hit breakpoints or B) they go into a wait state waiting for action from one of your suspended threads. So technically, the rest of the server does continue to function normally.
 
Goshfil Thomausen
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes my question was exactly about this, to see if there is a manner that allows that only the debug session is blocked on the breakpoints and not the other sessions. The fact that the other threads continue running just till they hit the breakpoint means that almost all the requests will be blocked.
In any case if it was possible to isolate a single session and to do the debug only on it, what was the problem on running it against a production environment? I mean, currently to see if the bug is reproducible we replicate the request done by a user to see how the error occurs, what was the problem in doing the same but with a debugger attached that meanwhile shows the various steps/data/variables content till the error occurs?
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can set breakpoints with conditions on them so that only threads that meet certain conditions will break there. All that's required is to identify some characteristic of the session of interest and test to see if that characteristic matches.



... what was the problem on running it against a production environment?



Two things. First of all, you are taking direct control of production resources. Back in mainframe days, there was an entirely independent group of people who interacted that closely with production. We were (allegedly) much more skilled than average and commanded significantly higher salaries as a result. But even then we weren't supposed to actually get our fingers into the actual production runs - just set stuff up and collect/analyze failures off the production systems. The closest modern analogue would be a DevOps person.

Secondly, auditors get really upset if unauthorized people can see production data. They get really, really upset if unauthorized people can modify production data. When a large company has its annual audit done one of the things the auditors usually has to do is to verify that no one can see or modify that data. Companies that fail to adhere to such practices tend to be the ones you hear about on the news where millions of customer records end up in the hands of people who will gladly sell them to people even less scrupulous than themselves. A professional shop should have test databases that closely mimic the characteristics of the production data without actually being real information about real people and real accounts. There are many data generators designed to help in creating such data.

Of course, there are cases so subtle that only the actual production system and data can trigger the problem, but that's when the top people should be involved - not a daily occurrence. For everything else, there's test data, test procedures and lots and lots of logging.
 
Goshfil Thomausen
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok thanks a lot for your explanation.
So I've to find an alternative solution. The alternative of conditional breakpoints is interesting but inapplicable in this case because the breakpoints (and so also the conditions) are applied by the developers and there is always the risk to put a wrong condition that blocks the entire production environment that is unacceptable in this context (also if for some second).
When I wrote the question I was thinking more to some kind of virtualization mechanism that allowed to run the debug session in a completely isolated environment respect the one that manages the ordinary requests.
BTW it seems to be not possible so I have to think to something else.
Thanks for your help.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic