Multiple worker threads and replaying decoder impl issues

["Trustin Lee (이희승)"]

Hi Galder,

I suspect that you are not creating a new decoder instance for each
connection, and that's why you observe mixed / messed-up data.

For example, this is bad:

  ServerBootstrap b = ...;
  b.getPipeline().addLast("decoder", new MyDecoder());

this is bad, too:

  final MyDecoder d = new MyDecoder();
  b.setPipelineFactory(new ChannelPipelineFactory() {
    public ChannelPipeline getPipeline() {
      ChannelPipeline p = ...;
      p.addLast("decoder", d);
      ...
      return p;
    }
  });

this one is correct:

  b.setPipelineFactory(new ChannelPipelineFactory() {
    public ChannelPipeline getPipeline() {
      ChannelPipeline p = ...;
      p.addLast("decoder", new MyDecoder());
      ...
      return p;
    }
  });

Some older examples were using the first pattern for certain special
cases, but they turned out to mislead users.  All examples were
rewritten to use the third pattern since then.  You might want to take a
look at the examples of 3.2 if you were referring to the 3.1 examples.

HTH,
Trustin

Galder Zamarreno wrote:
> Hi,
> 
> I've created a decoder based on the ReplayingDecoder and I'm seeing some  
> funny issues happening when the number of worker threads is more than one.
> 
> For example, the buffer passed on the decode() call-back come sometimes be  
> null.
> 
> 010-04-06 16:59:53,644 ERROR [AbstractProtocolDecoder$] (New I/O server  
> worker #1-4) Exception reported
> java.lang.RuntimeException: Buffer is null, how can it be???
> 	at scala.Predef$.error(Predef.scala:74)
> 	at  
> org.infinispan.server.core.transport.netty.DecoderAdapter.decode(DecoderAdapter.scala:18)
> 	at  
> org.infinispan.server.core.transport.netty.DecoderAdapter.decode(DecoderAdapter.scala:13)
> 	at  
> org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:461)
> 
> On top of that, we're seeing issues where thread-1 starts reading the  
> request and then waits for more bytes to come but when these bytes come  
> in, they're read by thread-2 which does not know what thread-1 read and  
> fails since it expects the start of a request.
> 
> So, is worker threads being single thread the only option here? What else  
> do you suggest? We currently use no state management. Would adding it  
> solve these issues?
> 
> Cheers,

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100407/fa2da447/attachment-0001.bin