You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Olivier Letellier (JIRA)" <ji...@apache.org> on 2014/03/08 17:40:42 UTC
[jira] [Updated] (PROTON-530) MessengerImpl.processActive() does
not rethrow IOException
[ https://issues.apache.org/jira/browse/PROTON-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Olivier Letellier updated PROTON-530:
-------------------------------------
Summary: MessengerImpl.processActive() does not rethrow IOException (was: MessengerImpl.processActive() do not rethrow IOException)
> MessengerImpl.processActive() does not rethrow IOException
> ----------------------------------------------------------
>
> Key: PROTON-530
> URL: https://issues.apache.org/jira/browse/PROTON-530
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
> Affects Versions: 0.6
> Environment: JDK 7
> Reporter: Olivier Letellier
>
> Test case :
> A connection has been established successfully from Messenger in Proton-j, and the client is waiting (possibly with a timeout) on recv().
> Then the peer resets this connection.
> Effect :
> In MessengerImpl.processActive(), a IOException("Connection reset by peer") is raised and catched. Until now everything is fine.
> A log is emitted, but the exception is not re-thrown, not registered, and the method continues to process other connections.
> From the client point of view :
> - if recv() has a positive timeout, a TimeoutException is raised, but the client cannot discriminate it from a timeout when nothing is received on a well established session. My client, for example, re-do a recv() , exits immediately with a TimeoutException, and then consumes 100% of the CPU of the JVM.
> - if recv() is blocking (negative timeout), an infinite loop is happening inside waitUntil(), then consuming 100% of CPU.
> I would suggest to throw a new RuntimeException(IOException) after having done the log in the catch clause.
> This problem may be linked to PROTON-525 and PROTON-214.
--
This message was sent by Atlassian JIRA
(v6.2#6252)