Thread View: borland.public.jbuilder.java.api
10 messages
10 total messages
Started by Victor Ceban
Tue, 18 Jan 2005 19:32
method calls logging
Author: Victor Ceban
Date: Tue, 18 Jan 2005 19:32
Date: Tue, 18 Jan 2005 19:32
19 lines
1563 bytes
1563 bytes
Hi, we have a complex J2EE application that runs on Tomcat 5/Linux and uses struts heavily. We also have a couple extra libraries used in the system. The system started to crash on the server and it crashes JVM with no useful information written to the log file. I was wondering if there is a mechanism to track all method calls sent to Java for us to identify which method crashes the system. We would like to avoid adding logging methods to every method: methodIn, methodOut and time (may be). Any JVM triggers we can use ? additional libraries ? As far as I know JRun does method timing , but its too late for us to transfer to it. Would appreciate any help. Thank you Vic
Re: method calls logging
Author: Victor Ceban
Date: Wed, 19 Jan 2005 14:16
Date: Wed, 19 Jan 2005 14:16
53 lines
3228 bytes
3228 bytes
Both this solutions require code to be altered (all methods) to show the debugging information. What I was looking for is more of an adapter/Listener that logs when my application enters a method in any class and leaves that method in that class. Any suggestions ? Victor "Paul Nichols (TeamB)" <paul@comp.net> wrote in message news:41edc04c@newsgroups.borland.com... > > "Victor Ceban" <vceban@eei1.com> wrote in message > news:41ed63d6$1@newsgroups.borland.com... >> Hi, >> >> we have a complex J2EE application that runs on Tomcat 5/Linux and uses >> struts heavily. We also have a couple extra libraries used in the system. >> >> The system started to crash on the server and it crashes JVM with no > useful >> information written to the log file. >> >> I was wondering if there is a mechanism to track all method calls sent >> to >> Java for us to identify which method crashes the system. We would like to >> avoid adding logging methods to every method: methodIn, methodOut and >> time >> (may be). Any JVM triggers we can use ? additional libraries ? >> > Two ways, youmight go about this, but it will drag the response time from > the server. > > (1) Use debugging with log4j. This will dump to your log4j files the full > stack trace from the running application. > > (2) Start your catalina session with the debug option. You will need to > start the catalina.sh or .bat file in a local terminal and this too will > produce a stack trace of output. Unless you want to monitor all activity, > I > would suggest redirecting this info to a file. > > > Info on log4j: http://logging.apache.org/log4j/docs/documentation.html > > Info on Catalina debugging: > http://www.fawcette.com/javapro/2003%5F06/online/debugging%5Fkjones%5F06%5F23%5F03/ > Look toward the bottom for command line info on using the debug mode. > > Again, expect your app to slow down dramatically, as the stack trace goes > through class loaders and methods.. > > > >
Re: method calls logging
Author: Paul Nichols (TeamB)
Date: Wed, 19 Jan 2005 15:21
Date: Wed, 19 Jan 2005 15:21
14 lines
1619 bytes
1619 bytes
"Victor Ceban" <vceban@eei1.com> wrote in message news:41ee6b3b$1@newsgroups.borland.com... > Both this solutions require code to be altered (all methods) to show the > debugging information. What I was looking for is more of an adapter/Listener > that logs when my application enters a method in any class and leaves that > method in that class. Any suggestions ? > > Victor Neither of them will require you to redo your methods. If you opt for the log4j solution, only the startup class will need to include it. The second method, only requires you to start Tomcat with the switch. It works on the same principle of java -debug
Re: method calls logging
Author: Lori M Olson [TeamB]
Date: Wed, 19 Jan 2005 22:57
Date: Wed, 19 Jan 2005 22:57
31 lines
1958 bytes
1958 bytes
Victor Ceban wrote:
> Both this solutions require code to be altered (all methods) to show the
> debugging information. What I was looking for is more of an adapter/Listener
> that logs when my application enters a method in any class and leaves that
> method in that class. Any suggestions ?
>
> Victor
>
I haven't done much with it myself, but this sounds like something
AspectJ would do well at.
--
Regards,
Lori Olson [TeamB]
------------
Save yourself, and everyone else, some time and search the
newsgroups and the FAQ-O-Matic before posting your next
question.
Google Advanced Newsgroup Search
http://www.google.ca/advanced_group_search
Other Newsgroup Searches:
http://www.borland.com/newsgroups/ngsearch.html
Joi Ellis's FAQ-O-Matic:
http://www.visi.com/~gyles19/fom-serve/cache/1.html
Re: method calls logging
Author: Paul Nichols (TeamB)
Date: Thu, 20 Jan 2005 02:12
Date: Thu, 20 Jan 2005 02:12
37 lines
2558 bytes
2558 bytes
"Victor Ceban" <vceban@eei1.com> wrote in message news:41ed63d6$1@newsgroups.borland.com... > Hi, > > we have a complex J2EE application that runs on Tomcat 5/Linux and uses > struts heavily. We also have a couple extra libraries used in the system. > > The system started to crash on the server and it crashes JVM with no useful > information written to the log file. > > I was wondering if there is a mechanism to track all method calls sent to > Java for us to identify which method crashes the system. We would like to > avoid adding logging methods to every method: methodIn, methodOut and time > (may be). Any JVM triggers we can use ? additional libraries ? > Two ways, youmight go about this, but it will drag the response time from the server. (1) Use debugging with log4j. This will dump to your log4j files the full stack trace from the running application. (2) Start your catalina session with the debug option. You will need to start the catalina.sh or .bat file in a local terminal and this too will produce a stack trace of output. Unless you want to monitor all activity, I would suggest redirecting this info to a file. Info on log4j: http://logging.apache.org/log4j/docs/documentation.html Info on Catalina debugging: http://www.fawcette.com/javapro/2003%5F06/online/debugging%5Fkjones%5F06%5F23%5F03/ Look toward the bottom for command line info on using the debug mode. Again, expect your app to slow down dramatically, as the stack trace goes through class loaders and methods..
Re: method calls logging
Author: Victor Ceban
Date: Thu, 20 Jan 2005 15:08
Date: Thu, 20 Jan 2005 15:08
28 lines
2271 bytes
2271 bytes
Thank you. I read all documentation files and still unsure how to do it ;-( Here is the output I'm looking for: 01/13 10:57:37 info METHOD ENTER SimpleServlet 7126423 doSomething 1101/13 10:57:37 info METHOD EXIT SimpleServlet 7126423 doSomething 25 0The only part in the documentation I found close to this is Nested Diagnostic Context. Is that what you meant ? If you have a second can you drop me a few lines of code that woul do this ?Vic "Paul Nichols (TeamB)" <paul@computer-logic.net> wrote in message news:41ee7ae2$1@newsgroups.borland.com... > > "Victor Ceban" <vceban@eei1.com> wrote in message > news:41ee6b3b$1@newsgroups.borland.com... >> Both this solutions require code to be altered (all methods) to show the >> debugging information. What I was looking for is more of an > adapter/Listener >> that logs when my application enters a method in any class and leaves >> that >> method in that class. Any suggestions ? >> >> Victor > Neither of them will require you to redo your methods. If you opt for the > log4j solution, only the startup class will need to include it. The second > method, only requires you to start Tomcat with the switch. It works on the > same principle of java -debug > >
Re: method calls logging
Author: Victor Ceban
Date: Thu, 20 Jan 2005 15:13
Date: Thu, 20 Jan 2005 15:13
47 lines
2371 bytes
2371 bytes
let me give you some more info on my problem. Here is what we have Class foo method doThis methid doThat What we would like is for the app to put info anywhere (console is an option) that would show when it entered methods and left them. Example 1/1/2005 Class foo, method doThis Enter 1/1/2005 Class foo, method doThis Exit 1/1/2005 Class foo, method doThat Enter 1/1/2005 Class foo, method doThat Exit It would be nice to not have to set it up in every method and class. and as you said log4j can do this. Any examples you can point me to ? Thank you. Victor "Paul Nichols (TeamB)" <paul@computer-logic.net> wrote in message news:41ee7ae2$1@newsgroups.borland.com... > > "Victor Ceban" <vceban@eei1.com> wrote in message > news:41ee6b3b$1@newsgroups.borland.com... >> Both this solutions require code to be altered (all methods) to show the >> debugging information. What I was looking for is more of an > adapter/Listener >> that logs when my application enters a method in any class and leaves >> that >> method in that class. Any suggestions ? >> >> Victor > Neither of them will require you to redo your methods. If you opt for the > log4j solution, only the startup class will need to include it. The second > method, only requires you to start Tomcat with the switch. It works on the > same principle of java -debug > >
Re: method calls logging
Author: Victor Ceban
Date: Fri, 21 Jan 2005 15:01
Date: Fri, 21 Jan 2005 15:01
26 lines
1892 bytes
1892 bytes
we solved the problem by replacing the JVM from Sun's to IBM's and setting just 2 parameters in the JVM. Vic "Paul Nichols (TeamB)" <paul@computer-logic.net> wrote in message news:41ee7ae2$1@newsgroups.borland.com... > > "Victor Ceban" <vceban@eei1.com> wrote in message > news:41ee6b3b$1@newsgroups.borland.com... >> Both this solutions require code to be altered (all methods) to show the >> debugging information. What I was looking for is more of an > adapter/Listener >> that logs when my application enters a method in any class and leaves >> that >> method in that class. Any suggestions ? >> >> Victor > Neither of them will require you to redo your methods. If you opt for the > log4j solution, only the startup class will need to include it. The second > method, only requires you to start Tomcat with the switch. It works on the > same principle of java -debug > >
Re: method calls logging
Author: John McGrath [TeamB]
Date: Fri, 21 Jan 2005 17:27
Date: Fri, 21 Jan 2005 17:27
15 lines
1613 bytes
1613 bytes
On 1/21/2005 at 10:01:41 AM, Victor Ceban wrote:
> we solved the problem by replacing the JVM from Sun's to IBM's and
> setting just 2 parameters in the JVM.
It would be nice if you would tell people what those parameters are.
--
Regards,
John McGrath [TeamB]
---------------------------------------------------
Before sending me e-mail, please read:
http://www.JPMcGrath.net/newsgroups/e-mail.html
Re: method calls logging
Author: Victor Ceban
Date: Fri, 21 Jan 2005 21:19
Date: Fri, 21 Jan 2005 21:19
52 lines
2511 bytes
2511 bytes
If you have 10.000 lines of code and you would like to instantly add debug info ofthis type: **** 21:06:48.284 0x83d3330 040014 < com/myClass.getBegColNLP Bytecode method 21:06:48.284 0x83d3330 04000D > com/myClass.getLenColNLP Bytecode method, This = 0x78139f68, Signature: ()[I 21:06:48.284 0x83d3330 040014 < com/myClass.getLenColNLP Bytecode method 21:06:48.284 0x83d3330 04000D > com/myClass.getConstTypes Bytecode method, This = 0x78139f68, **** All you need is an IBM JDK (available for Linux ? ) and 2 parameters to be added to your catalina.sh file *** -Dibm.dg.trc.print=mt -Dibm.dg.trc.methods=*.* *** This has helped us find one of code in that big application that used to crash JVM and thus leave us no debug info. Victor "John McGrath [TeamB]" <ng-b@JPMcGrath.net> wrote in message news:xn0dxioumqr4t7o001@newsgroups.borland.com... > On 1/21/2005 at 10:01:41 AM, Victor Ceban wrote: > >> we solved the problem by replacing the JVM from Sun's to IBM's and >> setting just 2 parameters in the JVM. > > It would be nice if you would tell people what those parameters are. > > -- > Regards, > > John McGrath [TeamB] > > --------------------------------------------------- > Before sending me e-mail, please read: > http://www.JPMcGrath.net/newsgroups/e-mail.html
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads