SonicMQ 6.1 Build 385
My customer has a problem. An openedge soniclistener sometimes stops listening to incoming messages, the error in the soniclistener.broker.log can be seen here:
S-0001>Server Port = 2008 PID = 5648. (8114)
S-0002>Server Port = 2009 PID = 2072. (8114)
S-0002>(17-feb-15 08:00:05:493) ServerSocketsIPC read() IOException : java.net.SocketException: Connection reset by peer: JVM_recv in socket input stream read : Connection reset by peer: JVM_recv in socket input stream read (8127)
S-0002>(17-feb-15 08:00:05:493) ServerIPCException in getServerIPCMsg() : ServerIPC error. (8119)
S-0002>Posted EAbnormalShutdownServerEvent for PID: 2072
C-0001>(17-feb-15 08:00:05:555) Cannot write error message (8420)
java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite(Native Method)
at java.net.SocketOutputStream.write(SocketOutputStream.java:91)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:67)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:125)
at com.progress.ubroker.broker.ubClientThread.sendClientRsp(ubClientThread.java:1918)
at com.progress.ubroker.broker.ubClientThread.sendClientRsp(ubClientThread.java:1892)
at com.progress.ubroker.broker.ubClientThread.processFatalError(ubClientThread.java:1597)
at com.progress.ubroker.broker.ubASclientThread.processFatalError(ubASclientThread.java:373)
at com.progress.ubroker.broker.ubClientThread.processEvent(ubClientThread.java:1040)
at com.progress.ubroker.broker.ubClientThread.mainline(ubClientThread.java:298)
at com.progress.ubroker.broker.ubClientThread.run(ubClientThread.java:213)
C-0001>(17-feb-15 08:00:05:555) Error Unspecified Error ... disconnecting client. (8091)
S-0001>(17-feb-15 08:00:05:868) ServerSocketsIPC write() IOException : java.net.SocketException: Connection reset by peer: socket write error : Connection reset by peer: socket write error (8127)
main>(17-feb-15 08:00:06:868) Log Closed
No errors to be seen in the oe appserver log.
There is an article in the kb http://knowledgebase.progress.com/articles/Article/P97921 with Fault Tolerance Sample Code, this still has to be completely implemented by the developers. But in the meantime I would like to know if the error above will indeed be detected by the samplecode and exactly what would would be detected. So during which call to the adapter can the error above happen and what is returned to openedge. Is it a stop condition, is it an error condition, is it only a return-value?
--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
www.linkedin.com/in/stefanhoutzager
Hi Stefan,
It depends on when the error is raised.
If the error in the log occurred while the client was in a wait-for, listening for the next message, then the error would eventually be reported asynchronously through the errorConsumer.
If the error in the log occurred while the listener was processing a message (either making ABL or ABL/JMS calls) then it would be a synchronous run-time condition and either an ABL STOP or ERROR condition could be raised.
Bottom line, if you want to bullet proof your ABL/JMS listener from any type of connection loss then you need to implement the complete strategy shown in the sample subscriber code at the bottom of the article.
Another option would be to upgrade your Sonic brokers to a new version and a fault tolerance license.
You can then make use of the setFaultTolerant() ABL/JMS call which was introduced in OE 10.x with the symbiotic ClientConnect/ServerConnect adapters.
HTH,
Thanks Paul, I know/believe (the adapter is closed source) the exceptionhandling in the kb has to be implemented, I've read the article thoroughly. I just liked to know if anyone knows if this particular exception will be catched and info send to the ablclient. But never mind, I'll do my best to convince the projectmanagers. Feel a bit ridiculous asking premature support. ;-) But the other option you name I will keep in mind, thanks for your reply!
--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
www.linkedin.com/in/stefanhoutzager
A follow-up on my question: we only see the error above in the soniclistener.broker.log in production. We do not know how to simulate errors like this in a test. Does anyone know how to do this?
--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
www.linkedin.com/in/stefanhoutzager