[jboss-jira] [JBoss JIRA] (JGRP-1617) Sync dispatcher castMessage does not awake blocked thread on ACK

[Bela Ban (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1617:
---------------------------

    Fix Version/s: 3.3
      Description: 
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.

  was:

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.



Calling castMessage() with a message that has a no-null destination is an error. I'll either throw an exception when this is detected, or (silently?) ignore the non-null destination as solution
                
> 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
>             Fix For: 3.3
>
>         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