[infinispan-dev] mux usage

[Bela Ban]

Hi Ales,

I looked into this, and - yes - a MessageListener passed to an 
RpcDispatcher or MessageDispatcher or MuxRpcDispatcher (subclass of 
RpcDispatcher) is ignored.

This is intentional; or else a MessageListener's receive() callback 
could eat the message destined for the internal Receiver, which calls 
handleMessage() in case of MessageDispatcher or invokes a method in case 
of the RpcDispatcher.

I'll create a JIRA to remove the MessageListener from 
{Rpc/Message}Dispatcher.

What are you trying to do ? Why don't you simply implement a method you 
want to call (say foo()) and then invoke foo() from your caller ?


On 5/15/12 11:13 PM, Ales Justin wrote:
>>
>>         public Object up(Event evt) {
>>             if(corr != null) {
>>                 if(!corr.receive(evt)) {
>>                     try {
>>                         return handleUpEvent(evt);
>>
>> Meaning msg listener only get's hit if corr::receive returns false.
>> Is this the case ever - with Ispans handles in place - here?
>
> I think it managed to see why no listener kicks in -- if my debug was right.
> And the above code -- as suspected -- is the culprit.
>
> corr.receive invokes
>
>          case Event.MSG:
>              if(receiveMessage((Message)evt.getArg()))
>                  return true; // message was consumed, don't pass it up
>
> Where "receiveMessage" goes here:
>
>          switch(hdr.type) {
>              case Header.REQ:
>                  if(request_handler == null) {
>                      if(log.isWarnEnabled()) {
>                          log.warn("there is no request handler installed to deliver request !");
>                      }
>                      return true;
>                  }
>
>                  handleRequest(msg, hdr);<----------------------- HERE
>                  break;
>
> 	..... // other code
>
>          return true; // message was consumed
>
> ----
>
> Our Msg dispatcher is the request_handler,
> but since we don't setup any explicit hander on it, it does nothing, retval == null.
>
> And then
>
>          if(!hdr.rsp_expected) // asynchronous call, we don't need to send a response; terminate call here
>              return;
>
> is true, since I put back async usage, so we return nicely.
>
> If you go back "receiveMessage" on ReqCorr returns true, hence we think msg was properly consumed,
> so no need for listener to handle it.
>
> Bug in JGroups?
>
> ---
>
>      protected void handleRequest(Message req, Header hdr) {
>          Object        retval;
>          Object        rsp_buf; // either byte[] or Buffer
>          Header        rsp_hdr;
>          Message       rsp;
>          boolean       threw_exception=false;
>
>          // i. Get the request correlator header from the msg and pass it to
>          // the registered handler
>          //
>          // ii. If a reply is expected, pack the return value from the request
>          // handler to a reply msg and send it back. The reply msg has the same
>          // ID as the request and the name of the sender request correlator
>
>          if(log.isTraceEnabled()) {
>              log.trace(new StringBuilder("calling (").append((request_handler != null? request_handler.getClass().getName() : "null")).
>                        append(") with request ").append(hdr.id));
>          }
>
>          try {
>              retval=request_handler.handle(req);
>          }
>          catch(Throwable t) {
>              // if(log.isErrorEnabled()) log.error("error invoking method", t);
>              threw_exception=true;
>              retval=t;
>          }
>
>          if(!hdr.rsp_expected) // asynchronous call, we don't need to send a response; terminate call here
>              return;
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)