JavalangStackOverflowError

[gandharibr]

Hi,
I get java.lang.StackOverflowError error after every 1 hour the server is started and the server shuts down abruptly. We are running 4.0.1. This happens on the production. Did anybody see this error or has a solution / possible explanation? If so, please let me know. This is very urgent.The stack trace is as follows...

java.lang.StackOverflowError
at com.wm.app.tn.cm.IDataCoderHash.put(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled

Code))
at com.wm.app.tn.cm.TempCoder._encode(TempCoder.java(Compiled
...................................
.....................
at

com.wm.app.tn.cm.InvocationStep.process(InvocationStep.java:282)
at com.wm.app.tn.cm.Step.performJump(Step.java:220)
at

com.wm.app.tn.cm.InvocationStep.process(InvocationStep.java:282)
at com.wm.app.tn.cm.Step.performJump(Step.java:220)
at

com.wm.app.tn.cm.InvocationStep.process(InvocationStep.java:282)
at com.wm.app.tn.cm.Step.performJump(Step.java:220)
at

com.wm.app.tn.cm.InvocationStep.process(InvocationStep.java:282)
at com.wm.app.tn.cm.Step.performJump(Step.java:220)
at

com.wm.app.tn.cm.InvocationStep.process(InvocationStep.java:282)
at

com.wm.app.tn.cm.ConversationScript.process(ConversationScript.java:2
94)
at

com.wm.app.tn.cm.ConversationAgent.process(ConversationAgent.java:194
)
at

com.wm.app.tn.cm.ConversationThread.synchRun(ConversationThread.java:
194)
at

com.wm.app.tn.cm.ConversationThread.run(ConversationThread.java:90)
at com.wm.util.pool.PooledThread.run(PooledThread.java:103)
at java.lang.Thread.run(Thread.java:498)

Thank you
Bharat

[dgreen]

Hi, Bharat.

Is this a new error or has it been happening since you have deployed the server in production?

Do you have a scheduled service that runs each hour that may be triggering the error?

What other leads or thoughts do you have about this?

Thanks.

[gandharibr]

Hi Dan,
This is a new error and it has been happening since we had a release last week. We do not have any scheduled service that runs every hour. We have a service (wm.tn.cm:cleanup) scheduled to run every 30 mins. The number of system threads was showing as 183. I cleaned up the repository (WmRepository2) files (number of files wasn't very large - around 350) and the system looks good since last night. It is behaving very well now. The number of system threads is around 40 now. But, i wouldn't prefer to do that next time it happens. Do you suggest any other solution?
Also, can any one give an insight into the TN property setting tn.cm.restart.disable? This property is set to true on our production.

Thank you
Bharat

[sonam]

Hi Bharat - Your stacktrace showed some WM conversation manager code making many nested function calls. I don't know anything about CM, but a stack overflow can occur if a Java thread made too many nested function calls, or it went into an endless recursive loop. I think you could may have the latter bug.

This site: http://simplethread.sourceforge.net/ says:
"Be aware of the -X memory options available with the JVM, which affords the easiest and most effective performance increase. Effective because allocating and freeing memory is the slowest operation for the JVM.
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size."

You could try disabling the wm.tn.cm:cleanup scheduled service to see if multiple instances of it are causing the problem. Check with WM support first. If WM Support insists their software is fine, you could then try checking your JVM thread stack size and maybe even increase Xss, if this option is offered by your JVM. Be careful - the default JVM settings should really be adequate.

As a side note, if you have TN, try running the wm.tn.enumerate:deleteQueryResults service as a weekly scheduled service - this clears up TN query cache files from WmRepository2. Also, my 4.6 servers work fine with about 130 system threads.

[tschoenoff]

I have seen similar errors several times...

It is most often caused by a bug in your code that has created a record structure that contains a circular reference (a reference back to itself)....Then when you call "pub.web:recordToDocument" or some other service that manipulates your record, it gets stuck in an infinite loop...

Hopefully this will jar your thinking...If not please provide more details...

Tony