Logging | Stack trace gets truncated

[Former Member]

I'm trying to diagnose a deployment issue I have with an EJB, and am examining the default trace log. I'm seeing a log entry related to my problem, but the stack trace is truncated:

...
 at com.sap.engine.services.ejb.EJBAdmin.deploy(EJBAdmin.java:2161)
at com.sap.engine.services.deploy.server.application.DeploymentTransaction.makeComponents(DeploymentTransaction.java:606)
... 16 more

Is there any way I can configure the application server to not truncate stack traces and log them in their entirety? Or is there a better method of getting a look at what's going on when I'm trying to deploy my EAR file?

[former_member185954]

Hello Kar,

You can configure the size and the storage location for trace files, using the Log Manager in Visual admin.

By default, logs are written to five files, each file with a maximum size of 10 MB. If archiving is enabled, when the fifth file is completed, the set of five files is backed up into a ZIP file. Then, the new logs start overwriting the old log files.

check the following link for an overview of [monitoring and tracing|http://help.sap.com/saphelp_nw70/helpdata/EN/ac/e9d8a51c732e42bd0e7de54b9ff4e2/frameset.htm]

Use the [Log Manager|http://help.sap.com/saphelp_nw70/helpdata/EN/2b/09343e32ff1033e10000000a114084/frameset.htm] to set the following parameters:

DefaultTraceFile_Count

DefaultTraceFile_Limit

DefaultTraceFile_Pattern

etc.

Hope that helps.

Regards,

Siddhesh

[Former Member]

You can configure the size and the storage location for trace files, using the Log Manager in Visual admin.

The trace files themselves are fine, that's not the problem. I'm talking about the actual stack traces themselves. Once again, here's a snippet from a stack trace:

Caused by: java.lang.NoClassDefFoundError: nl.hagaziekenhuis.medisurf.ejbs.favorieten.FavorietenException
at java.lang.Class.getDeclaredMethodsImpl(Native Method)
at java.lang.Class.getDeclaredMethods(Class.java:599)
at java.lang.Class.getInterfaceMethodCountImpl(Class.java:848)
at java.lang.Class.getInterfaceMethodsImpl(Class.java:863)
at java.lang.Class.getMethods(Class.java:808)
at com.sap.engine.services.ejb.deploy.verifier.RmiIiopUtils.isValidRmiIIOPInterface(RmiIiopUtils.java:52)
at com.sap.engine.services.ejb.deploy.verifier.RemoteInterfaceCheck.check(RemoteInterfaceCheck.java:40)
at com.sap.engine.services.ejb.deploy.verifier.session.SessionBeanCheck.check(SessionBeanCheck.java:76)
at com.sap.engine.services.ejb.deploy.verifier.Verifier.checkBean(Verifier.java:82)
at com.sap.engine.services.ejb.deploy.verifier.Verifier.check(Verifier.java:46)
at com.sap.engine.services.ejb.deploy.DeployAdmin.generate(DeployAdmin.java:254)
at com.sap.engine.services.ejb.EJBAdmin.deploy(EJBAdmin.java:2161)
at com.sap.engine.services.deploy.server.application.DeploymentTransaction.makeComponents(DeploymentTransaction.java:606)
... 16 more

Now, note that I didn't add the trailing "...16 more" line; something in the system did that. I need the AS to log the entire trace for me, not just the first bit and then saying how much it didn't log.

[Former Member]

Well, I've poked around in the Visual Administrator a bit. Under Server > Kernel > ConfigurationManager I found a set of properties, one of which is called call.trace.level, which is currently set to 0. Google hasn't been very helpful in revealing what it does, though. Can anyone tell me what it does before I start tinkering with it?

[former_member185954]

Maybe this can help:

http://help.sap.com/saphelp_nw70/helpdata/EN/fe/5309417a25f023e10000000a155106/frameset.htm

Regards,

Siddhesh

[Former Member]

Hi Kars,

The property call.trace.level just switches on/off the logging by configuration manager. It won't help I belive in your case.

Also, please check the log files from log viewer, I guess it displays entire content.

regards, Shantanu

Edited by: Shantanu Bansal on Mar 20, 2008 11:50 AM

[Former Member]

Thanks, Siddhesh! That looks like a very useful tool.

I've used it to find the process ID of the server0 process, and issued the following command:

kill -USR1 <server0_pid>

to increase the trace level of the server process.

After that, I tried to deploy the EAR file again, but I'm still getting the exact same truncated stack trace. I repeated the above step one or two times, but to no avail. I even tried it on the SDM process, but that didn't help either. I also tried it using command 15 in JCMON, but that caused JCMON to hang.

[former_member185954]

Hello Kars,

Are you able to stop/start the server (j2ee and SDM) after increasing the trace level.

Regards,

Siddhesh

[Former Member]

D'oh! I can't believe I missed that in the documentation... Restarting now. It's a slow development server though, so that'll take about 30 minutes. Argh..!

Anyway, many thanks!

[Former Member]

Ok, the server's restarted (both server0 and SDM), but to no avail. I've repeated it several times, with server0 running at trace level 3 and the SDM running at trace level 2, but I still don't get a full stack trace.

I did, however, find the cause of the deployment problem I was having. So unless there are other suggestions, I'll regard this topic as: question unanswered, problem solved.

In any case, thanks for helping, Siddhesh and Shantanu!