🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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
#31
Author: Victor Ceban
Date: Tue, 18 Jan 2005 19:32
19 lines
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
#33
Author: Victor Ceban
Date: Wed, 19 Jan 2005 14:16
53 lines
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
#34
Author: Paul Nichols (TeamB)
Date: Wed, 19 Jan 2005 15:21
14 lines
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
#35
Author: Lori M Olson [TeamB]
Date: Wed, 19 Jan 2005 22:57
31 lines
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
#32
Author: Paul Nichols (TeamB)
Date: Thu, 20 Jan 2005 02:12
37 lines
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
#36
Author: Victor Ceban
Date: Thu, 20 Jan 2005 15:08
28 lines
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
#37
Author: Victor Ceban
Date: Thu, 20 Jan 2005 15:13
47 lines
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
#39
Author: Victor Ceban
Date: Fri, 21 Jan 2005 15:01
26 lines
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
#40
Author: John McGrath [TeamB]
Date: Fri, 21 Jan 2005 17:27
15 lines
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
#41
Author: Victor Ceban
Date: Fri, 21 Jan 2005 21:19
52 lines
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