I have the following scenario:

All sessions are ended with an exception and staying unclosed, after an IC request error occurred in a DD session.
This is the exception at the end of all sessions:
04/06/2009 09:34:13 INFO - BA61B17BF197BA0F7106B71D94121172:/TComHR_Dispatcher : ***!!*** Setting Exit Timer
04/06/2009 09:34:13 ERROR - BA61B17BF197BA0F7106B71D94121172:/TComHR_Dispatcher : channel:41 | Error processing request
EXCEPTION>
java.lang.IllegalStateException: Timer already cancelled.
   at java.util.Timer.sched(Timer.java:354)
   at java.util.Timer.schedule(Timer.java:170)
   at com.avaya.sce.runtimecommon.SCESession.setExitTimer(SCESession.java:1783)
   at com.avaya.sce.runtime.vxml.OutputGenerator.completeBegin(OutputGenerator.java:1842)
   at com.avaya.sce.runtime.Return.handleRequest(Return.java:105)
   at com.avaya.sce.runtime.AppDocument.processRequest(AppDocument.java:163)
   at com.avaya.sce.runtime.SCEServlet.requestHandler(SCEServlet.java:215)
   at com.avaya.sce.runtime.SCEServlet.doGet(SCEServlet.java:157)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
.....

It causes unclosed sessions (all sessions), and unsent VOX.gone commands, and large number of alarms in AIC with "Unknown vduid ... seen in VOX.gone" and "VOX.AmbiVDUID". The VOX.gone is only sent after 30 minutes, when Tomcat timeouts the session.

Could you please check why an IC request error causes this strange behaviour.

I would like to make the description more precise:
The IC request error occurred only one time, in only one session. IC integration worked fine before and after that. The main problem is that all DD sessions ended with the mentioned exception after that, and therefore none of the sessions were closed properly (missing session remove step, and gone).

It seems that the timer thread had been canceled. If you are running 4.1.10 I don't see how this is possible.

Can you check to see if you have >1 scertcommon-<version>.jar file in your common/lib folder.

There is only one jar in common/lib:
scertcommon-04.01.10.01.jar

Hmm... I don't know how the timer thread was canceled. Perhaps some Tomcat problem stopped the thread, but that's just a guess.
Can you zip up and send me (ejohnson@avaya.com) the trace log. I'll need to see the logs for a period of time before/during and after the Timer already canceled error.

I have sent you the log.

I don't see anything in the log that identifies what happened. I'm speculating that there was some problem with Tomcat around 9:34:13 which led to this problem.

I see that there was a socket failure (Connection reset) which the ICC reported.

At the same time a different session was about to end and tried to add a TimerTask to a Timer thread and you see the Timer already canceled exception.

The timer thread runs as a daemon thread and is never explicitly closed by the runtime--it will shut down when the application server is stopped. So this is why I'm thinking that there was some transient error on Tomcat which caused the socket error and the timer to stop, but then Tomcat was able to recover ~2 seconds later.

Have you seen this type of thing before or after?

We have another project with same DD version, and experienced the same error there as well.
I have sent you trace log.

In this case, problems started with some VOX request timeouts. I think it can happen in a live environment, but i wonder how it can cause hanging of timer thread.

I sent a response via email.. I think we need to look at your system a bit as the only way in 4.1.10 that the timer thread is cancelled is if the garbage collector thinks that the timer object is no longer referenced, which should never happen.

Hi,

I am also getting the same error, while transferring the call through IC. Also the same application, we are running with DD ver 4.1.7 and it is working fine.

Is it related to DD ver or something else?

DD ver 4.1.10
VP 4.1
Application Server: Tomcat
OS: Linux

Thanks in advance.

Please create a new thread.

You will also need to post both the IC connector log as well as the DD application trace.log for a failure condition. Without seeing those logs we cannot determine if you are seeing the same issue or something different.