[JBoss JIRA] Created: (JBESB-1944) The InVM courier is not completely valid from concurrency point of view
2:28 a.m.
The InVM courier is not completely valid from concurrency point of view
-----------------------------------------------------------------------
Key: JBESB-1944
URL: https://jira.jboss.org/jira/browse/JBESB-1944
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.4
Reporter: Jiri Pechanec
Fix For: 4.4 CP1
There are few problems with current implementation of InVM courier.
1) The message queue uses ConcurrentLinkedQueue as backing data structure. Unfortunately
the synchronized primitive is used as lock on this queue whicm means that all advanatages
of using it are negated. I guess that this approch is used for lockstep. The correct
soultion is should be to have messageQueue unsychchronized and have separate Event object
or separate regular object as lock holder if lockstep is in place.
2) The lockstep does not work correctly when there are multiple threads on input/output of
the queue. The notify call does not guarantee that the correct delivery/pickup threads are
waken up. For example the notify call in one delivery thread can wake up another delivery
thread waiting up for the notify from pickup thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:20 a.m.
New subject: [JBoss JIRA] Assigned: (JBESB-1944) The InVM courier is not completely valid from concurrency point of view
[
https://jira.jboss.org/jira/browse/JBESB-1944?page=com.atlassian.jira.plu...
]
Tom Fennelly reassigned JBESB-1944:
-----------------------------------
Assignee: Tom Fennelly
The InVM courier is not completely valid from concurrency point of
view
-----------------------------------------------------------------------
Key: JBESB-1944
URL: https://jira.jboss.org/jira/browse/JBESB-1944
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.4
Reporter: Jiri Pechanec
Assignee: Tom Fennelly
Fix For: 4.4 CP1
There are few problems with current implementation of InVM courier.
1) The message queue uses ConcurrentLinkedQueue as backing data structure. Unfortunately
the synchronized primitive is used as lock on this queue whicm means that all advanatages
of using it are negated. I guess that this approch is used for lockstep. The correct
soultion is should be to have messageQueue unsychchronized and have separate Event object
or separate regular object as lock holder if lockstep is in place.
2) The lockstep does not work correctly when there are multiple threads on input/output
of the queue. The notify call does not guarantee that the correct delivery/pickup threads
are waken up. For example the notify call in one delivery thread can wake up another
delivery thread waiting up for the notify from pickup thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:20 a.m.
New subject: [JBoss JIRA] Work started: (JBESB-1944) The InVM courier is not completely valid from concurrency point of view
[
https://jira.jboss.org/jira/browse/JBESB-1944?page=com.atlassian.jira.plu...
]
Work on JBESB-1944 started by Tom Fennelly.
The InVM courier is not completely valid from concurrency point of
view
-----------------------------------------------------------------------
Key: JBESB-1944
URL: https://jira.jboss.org/jira/browse/JBESB-1944
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.4
Reporter: Jiri Pechanec
Assignee: Tom Fennelly
Fix For: 4.4 CP1
There are few problems with current implementation of InVM courier.
1) The message queue uses ConcurrentLinkedQueue as backing data structure. Unfortunately
the synchronized primitive is used as lock on this queue whicm means that all advanatages
of using it are negated. I guess that this approch is used for lockstep. The correct
soultion is should be to have messageQueue unsychchronized and have separate Event object
or separate regular object as lock holder if lockstep is in place.
2) The lockstep does not work correctly when there are multiple threads on input/output
of the queue. The notify call does not guarantee that the correct delivery/pickup threads
are waken up. For example the notify call in one delivery thread can wake up another
delivery thread waiting up for the notify from pickup thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:15 a.m.
New subject: [JBoss JIRA] Closed: (JBESB-1944) The InVM courier is not completely valid from concurrency point of view
[
https://jira.jboss.org/jira/browse/JBESB-1944?page=com.atlassian.jira.plu...
]
Tom Fennelly closed JBESB-1944.
-------------------------------
Resolution: Done
Fixed concurrency issue - returning to wait state while message is still in queue (issue
#2 outlined by Jiri).
Not changing the basic concurrency semantics at this stage (issue/point #1 raised by
Jiri).
The InVM courier is not completely valid from concurrency point of
view
-----------------------------------------------------------------------
Key: JBESB-1944
URL: https://jira.jboss.org/jira/browse/JBESB-1944
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.4
Reporter: Jiri Pechanec
Assignee: Tom Fennelly
Fix For: 4.4 CP1
There are few problems with current implementation of InVM courier.
1) The message queue uses ConcurrentLinkedQueue as backing data structure. Unfortunately
the synchronized primitive is used as lock on this queue whicm means that all advanatages
of using it are negated. I guess that this approch is used for lockstep. The correct
soultion is should be to have messageQueue unsychchronized and have separate Event object
or separate regular object as lock holder if lockstep is in place.
2) The lockstep does not work correctly when there are multiple threads on input/output
of the queue. The notify call does not guarantee that the correct delivery/pickup threads
are waken up. For example the notify call in one delivery thread can wake up another
delivery thread waiting up for the notify from pickup thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:42 a.m.
New subject: [JBoss JIRA] Reopened: (JBESB-1944) The InVM courier is not completely valid from concurrency point of view
[
https://jira.jboss.org/jira/browse/JBESB-1944?page=com.atlassian.jira.plu...
]
Jiri Pechanec reopened JBESB-1944:
----------------------------------
I must reopen the issue - solution is based on usage of
messageQueue.contains(addedObject).
The problem is that the message implementations does not override equals method, so when
pass-by-value is used then the semantics is broken.
The InVM courier is not completely valid from concurrency point of
view
-----------------------------------------------------------------------
Key: JBESB-1944
URL: https://jira.jboss.org/jira/browse/JBESB-1944
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.4
Reporter: Jiri Pechanec
Assignee: Tom Fennelly
Fix For: 4.4 CP1
There are few problems with current implementation of InVM courier.
1) The message queue uses ConcurrentLinkedQueue as backing data structure. Unfortunately
the synchronized primitive is used as lock on this queue whicm means that all advanatages
of using it are negated. I guess that this approch is used for lockstep. The correct
soultion is should be to have messageQueue unsychchronized and have separate Event object
or separate regular object as lock holder if lockstep is in place.
2) The lockstep does not work correctly when there are multiple threads on input/output
of the queue. The notify call does not guarantee that the correct delivery/pickup threads
are waken up. For example the notify call in one delivery thread can wake up another
delivery thread waiting up for the notify from pickup thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:58 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-1944) The InVM courier is not completely valid from concurrency point of view
[
https://jira.jboss.org/jira/browse/JBESB-1944?page=com.atlassian.jira.plu...
]
Tom Fennelly commented on JBESB-1944:
-------------------------------------
You sure Jiri?
If pbv is used, a byte array is added to the message queue and in that case the contains()
call will result in a simple object reference check against the byte[] object. If the
byte array is in the queue, contains will return true on one of the entries... if not it
will return false etc
Re pbr the same applies because none of the Message implementations we have override
equals, so they'd also use the Object.equals(Object) impl.
As I see it, there's no risk here re CP1, but we could add a task for a future release
to replace the queue.contains() call with a call to a new local method that only does a
reference comparisons i.e. doesn't rely on the equals behavior in case someone
overrides the equals method in one of the Message impls. I don't think it makes any
sense to do that, but if we wanted to be extra careful.... :-)
The InVM courier is not completely valid from concurrency point of
view
-----------------------------------------------------------------------
Key: JBESB-1944
URL: https://jira.jboss.org/jira/browse/JBESB-1944
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.4
Reporter: Jiri Pechanec
Assignee: Tom Fennelly
Fix For: 4.4 CP1
There are few problems with current implementation of InVM courier.
1) The message queue uses ConcurrentLinkedQueue as backing data structure. Unfortunately
the synchronized primitive is used as lock on this queue whicm means that all advanatages
of using it are negated. I guess that this approch is used for lockstep. The correct
soultion is should be to have messageQueue unsychchronized and have separate Event object
or separate regular object as lock holder if lockstep is in place.
2) The lockstep does not work correctly when there are multiple threads on input/output
of the queue. The notify call does not guarantee that the correct delivery/pickup threads
are waken up. For example the notify call in one delivery thread can wake up another
delivery thread waiting up for the notify from pickup thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:13 a.m.
New subject: [JBoss JIRA] Resolved: (JBESB-1944) The InVM courier is not completely valid from concurrency point of view
[
https://jira.jboss.org/jira/browse/JBESB-1944?page=com.atlassian.jira.plu...
]
Jiri Pechanec resolved JBESB-1944.
----------------------------------
Resolution: Done
You are right, I have confused myself :-)
It is OK
The InVM courier is not completely valid from concurrency point of
view
-----------------------------------------------------------------------
Key: JBESB-1944
URL: https://jira.jboss.org/jira/browse/JBESB-1944
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.4
Reporter: Jiri Pechanec
Assignee: Tom Fennelly
Fix For: 4.4 CP1
There are few problems with current implementation of InVM courier.
1) The message queue uses ConcurrentLinkedQueue as backing data structure. Unfortunately
the synchronized primitive is used as lock on this queue whicm means that all advanatages
of using it are negated. I guess that this approch is used for lockstep. The correct
soultion is should be to have messageQueue unsychchronized and have separate Event object
or separate regular object as lock holder if lockstep is in place.
2) The lockstep does not work correctly when there are multiple threads on input/output
of the queue. The notify call does not guarantee that the correct delivery/pickup threads
are waken up. For example the notify call in one delivery thread can wake up another
delivery thread waiting up for the notify from pickup thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:13 a.m.
New subject: [JBoss JIRA] Closed: (JBESB-1944) The InVM courier is not completely valid from concurrency point of view
[
https://jira.jboss.org/jira/browse/JBESB-1944?page=com.atlassian.jira.plu...
]
Jiri Pechanec closed JBESB-1944.
--------------------------------
Verified in IR4
The InVM courier is not completely valid from concurrency point of
view
-----------------------------------------------------------------------
Key: JBESB-1944
URL: https://jira.jboss.org/jira/browse/JBESB-1944
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.4
Reporter: Jiri Pechanec
Assignee: Tom Fennelly
Fix For: 4.4 CP1
There are few problems with current implementation of InVM courier.
1) The message queue uses ConcurrentLinkedQueue as backing data structure. Unfortunately
the synchronized primitive is used as lock on this queue whicm means that all advanatages
of using it are negated. I guess that this approch is used for lockstep. The correct
soultion is should be to have messageQueue unsychchronized and have separate Event object
or separate regular object as lock holder if lockstep is in place.
2) The lockstep does not work correctly when there are multiple threads on input/output
of the queue. The notify call does not guarantee that the correct delivery/pickup threads
are waken up. For example the notify call in one delivery thread can wake up another
delivery thread waiting up for the notify from pickup thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5959
days inactive
5984
days old
7 comments
2 participants
participants (2)
-
Jiri Pechanec (JIRA) -
Tom Fennelly (JIRA)