The logs after 3:45:34.157 show that your application creates a new session then creates a new sender, then closes a previous sender and then its session, then sits idle a bit until after a few minutes Service Bus remotely closes all the links and sessions and then the connection itself, without any errors specified which will provoke various 'unknown error from remote peer' exceptions, with those for consumers with listeners and the connection closure being delivered to the exception listener. A second connection is then established, and 8 consumers established on it, then eventually a sender.
I would theorise what is happening is that because there are likely to be multiple exceptions raised here, first for the message listener remote closures and then one for the connection remote closure, and the exception listener is necessarily fired async from their actual arrival as they are processed, and you are doing your own 'detect closure' in the ExceptionListener, you are quite possibly noticing the connection has become failed during an ExceptionListener run prompted by an earlier (consumer related?) exception delivery, either in your detection check or because attempting to create a consumer/session throws if the connection is now failed, before you then receive the exception that explicitly resulted from the connections actual remote closure. You might then be repeating your checks during subsequent exception delivery for either a consumer or the connection closure and indicating the connection isnt closed (which again per previous mails, it must be for the connection closure exception as the exception delivered was itself only created after that point) quite possibly because what you checked isnt the same connection, if your exception handling already replaced it and the listener can access and operate on that connection object (this would go back to my earlier notes around whether your exception listener can only interact with the connection object it was set on). That would also fit in with your followup mail. The 'connection listener' events are also fired async, in the same executor thread as the ExceptionListener, so you could well see one ExceptionListener handling after e.g a consumer closure do work that creates a new connection (as thats also become failed) and cause things leading to its logging, before the 'connection listener' report is actually made aware of the prior connections failure. Note there is no 'connection listener' event for opening consumers/producers/sessions and thus no related logging. On Thu, 18 Mar 2021 at 11:06, akabhishek1 <[email protected]> wrote: > > Hi Robbie, > > We got 'Unknown error from remote peer' today in both applications QPid-56 > and Qpid-57, surprisingly both applications are working fine and consuming > messages as expected. > > However I would like to share interesting details of "QPid-56" application. > Note - In this application, I am not considering connection is closed for > JmsConnectionRemotelyClosedException/JmsConnectionFailedException. I am > relying on “isConnectionActive” method to check connection status– details > are in the first post of this issue. > > ## JMS Infra ## > JMS connection - 1 > Exception listener - 1 > 2 listener - (8(2*4) consumers) - Every listener have 4 consumers and > sessions > (a)topic:A/subscriptions/a1 > (b)topic:B/subscriptions/b1 > 1 publisher – (session + producer) > qpid-jms-client - 56.0 > > Steps - > 1) > 3/18/2021, 3:48:18.380 AM - Received error on "onException" - Connection > exception from 'servicebus_2', isConnectionActive 'true', Reason 'Unknown > error from remote peer' - 'class > org.apache.qpid.jms.JmsConnectionRemotelyClosedException' > StackTrace - > https://github.com/abhikt48/servicebus/blob/master/18-March/ConnectionActive_true_JmsConnectionRemotelyClosedException.txt > 2)Checked "isConsumerActive" for first receiver(A/a1) - It was active, so no > need to reconnect > 3)Checked "isConsumerActive" for first receiver(B/b1) - it was active, so no > need to reconnect > > 4) Published message at 3/18/2021, 10 AM - Both receiver consumed message > successfully > > We have enable proton TRACES logs. I attach TRACES of last 12 hour, so we > can't miss anything, you can check after "3/18/2021, 3:45:34.157 AM". > Please refer - > https://github.com/abhikt48/servicebus/blob/master/18-March/Proton_Traces.txt > > As we have received "JmsConnectionRemotelyClosedException", so we are > assuming that connection should be broken, but connection and receiver > wasn't broken. Both receivers are consuming message perfectly. > > I am not sure this is expected behaviour or not. Could you please take a > look on this and suggest your suggestion. > > P.S. - I haven't shared TRACES and log details on Qpid-57 application for > comparison, as expected it is working fine. But if you need TRACES and log > details of Qpid-57 application as well, then please let me know. I can > extract and share with you. > > Regards, > Abhishek Kumar > > > > > -- > Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
