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

[Sanne Grinovero (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767180#comment-12767180 ] 

Sanne Grinovero commented on JGRP-1617:
---------------------------------------

I've been filtering out most irrelevant events from the logs, but not wanting to risk removing something useful they are still quite large.

The thread being blocked is (http-/127.0.0.1:8080-1), but it initially performs some Cache operations which have no problems; then at 19:58:46,629 it sends a JGroups message (direct JGroups usage with no Infinispan, but sharing the same Channel via the Mux implementation of the AS).

The relevant timestamps in the logs:

Node A:
19:58:46,629 Message #116 is sent; this is thread (http-/127.0.0.1:8080-1) using the castMessage code mentioned above

Node B:
19:58:46,630 Delivered to Hibernate Search on the other node
19:58:46,854 Hibernate Search is done with processing
19:58:46,854 Sending RSP id=116 (Request 49)

Node A:
19:58:46,856 delivering #116 via thread (Incoming-3,shared=udp)
19:58:47,449 A sends stable to B for #116

[9 seconds later]

19:58:56,631 First signs of progress for thread (http-/127.0.0.1:8080-1)

Attaching full logs















                
> 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
>
>
> 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