[
https://issues.apache.org/jira/browse/QPID-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ritchie updated QPID-1431:
---------------------------------
Description:
Summary:
Due to our desire to reduce synchronization on the client it is possible to
fail to notify a client of an exception state.
As highlighted by the two thread processes below, the _frameListeners can be
updated such that the notification fails to take place.
Thread 1.
Thread 2.
Synchronous Op.(Commit, Create...) Error Occurs
AMQProtocolHandler
AMQProtocolHandler
syncWrite(frame)
propagateExceptionToFrameListeners(error)
writeCommandAndWait(frame,listener)
synchronize(_frameListeners) if
(_frameListeners.isEmpty())
frameListener.add(listener)
_frameListeners.iterator();
This is due to our use of CopyOnWrite lists. As the Exception handler is
propagating the exception a new syncWait can occur, which will fail as the
connection is closed. There is a question of why the socket write does not fail
but that may be because the close has not yet occurred.
Suggested change:
All uses of the _frameListeners should be synchronized and the syncWrite should
check to see if the connection is closed before allowing the adding the
listener. Throwing any exception that has already been set.
was:
Summary:
Due to our desire to reduce synchronization on the client it is possible to
fail to notify a client of an exception state.
As highlighted by the two thread processes below, the _frameListeners can be
updated such that the notification fails to take place.
Thread 1. Thread 2.
Synchronous Op.(Commit, Create...) Error Occurs
AMQProtocolHandler AMQProtocolHandler
syncWrite(frame)
propagateExceptionToFrameListeners(error)
writeCommandAndWait(frame,listener)
synchronize(_frameListeners) if
(_frameListeners.isEmpty())
frameListener.add(listener) _frameListeners.iterator();
This is due to our use of CopyOnWrite lists. As the Exception handler is
propagating the exception a new syncWait can occur, which will fail as the
connection is closed. There is a question of why the socket write does not fail
but that may be because the close has not yet occurred.
Suggested change:
All uses of the _frameListeners should be synchronized and the syncWrite should
check to see if the connection is closed before allowing the adding the
listener. Throwing any exception that has already been set.
> Client can fail to notify all framelisteners
> --------------------------------------------
>
> Key: QPID-1431
> URL: https://issues.apache.org/jira/browse/QPID-1431
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M2.1, M3
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Priority: Critical
> Fix For: M4
>
> Attachments: Threading.txt
>
>
> Summary:
> Due to our desire to reduce synchronization on the client it is possible to
> fail to notify a client of an exception state.
> As highlighted by the two thread processes below, the _frameListeners can be
> updated such that the notification fails to take place.
> Thread 1.
> Thread 2.
> Synchronous Op.(Commit, Create...) Error Occurs
> AMQProtocolHandler
> AMQProtocolHandler
> syncWrite(frame)
> propagateExceptionToFrameListeners(error)
> writeCommandAndWait(frame,listener)
> synchronize(_frameListeners) if
> (_frameListeners.isEmpty())
> frameListener.add(listener)
> _frameListeners.iterator();
> This is due to our use of CopyOnWrite lists. As the Exception handler is
> propagating the exception a new syncWait can occur, which will fail as the
> connection is closed. There is a question of why the socket write does not
> fail but that may be because the close has not yet occurred.
> Suggested change:
> All uses of the _frameListeners should be synchronized and the syncWrite
> should check to see if the connection is closed before allowing the adding
> the listener. Throwing any exception that has already been set.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
