[jboss-jira] [JBoss JIRA] (JGRP-1617) Sync dispatcher castMessage does not awake blocked thread on ACK
Dan Berindei (JIRA)
jira-events at lists.jboss.org
Mon Apr 15 14:00:54 EDT 2013
[ https://issues.jboss.org/browse/JGRP-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767336#comment-12767336 ]
Dan Berindei commented on JGRP-1617:
------------------------------------
Bela, I was able to reproduce the timeout using your test, with this modification:
{code}
Message msg = new Message();
msg.setDest(b.getAddress());
RspList<Object> rsps=disp.castMessage(null, msg,RequestOptions.SYNC());
{code}
It seems that, if the destination address is already set in the message, UDP will only send the message to that address, but MessageDispatcher will still wait for responses from all the members of the cluster.
I think at the very least this should warrant a warning.
> Sync dispatcher castMessage does not awake blocked thread on ACK
> ----------------------------------------------------------------
>
> Key: JGRP-1617
> URL: https://issues.jboss.org/browse/JGRP-1617
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Attachments: bla.java, filtered.log.bz2
>
>
> On version 3.3.0.CR1 we observed that the following code:
> {code}final RequestOptions options = RequestOptions.SYNC();
> dispatcher.castMessage( null, message, options );
> {code}
> will always block until the timeout defined in _RequestOptions_, even if the remote operation is very quick in responding.
> We could workaround the issue by setting a custom _RspFilter_, but this filter is otherwise not needed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list