mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hanson Char" <hanson.c...@gmail.com>
Subject Re: Data Corruption in Mina 0.8.2
Date Tue, 04 Jul 2006 18:03:06 GMT
Hi Trustin,

I've just created an issue in JIRA, with an attached test case you can run
on Linux 7.2 to see the problem.  (Actually I will also include a log file
to give you a sample run in case you don't have access to Linux 7.2.)

  http://issues.apache.org/jira/browse/DIRMINA-224

Note there is no use of thread pool.

Any idea of how to get around this problem (besides changing the OS) ?
Would Mina 0.9.4 happen to have this problem already fixed ?

Hanson

On 6/26/06, Hanson Char <hanson.char@gmail.com> wrote:
>
> > Do you write messages to one session from multiple threads?
>
> I don't think so.  I am using only 1 thread to do multiple write to
> the same session.  Not explicitly using any thread pool.
>
> Will confirm and send you more details next week.  (Currently on a
> vacation trip/camping.)
>
> Cheers,
> Hanson
>
> On 6/25/06, Trustin Lee <trustin@gmail.com> wrote:
> > Hello Hanson,
> >
> > On 6/24/06, Hanson Char <hanson.char@gmail.com> wrote:
> > >
> > > I think I found a bug in Mina 0.8.2 that leads to data corruption when
> > > Mina is under high load.  Specifically, in Mina 0.8.2, when invoked
> > > from
> > >
> > >   IOAdapter$SessionHandlerAdapter.dowrite()
> > >
> > > the
> > >
> > >   Queue.isEmpty()
> > >
> > > is not properly synchronized.  I also found a get around to this
> > > problem with Java 5.  More details here:
> > >
> > > http://hansonchar.blogspot.com/2006/06/bug-patch-mina-082.html
> > >
> > > Any comment?  Is this already fixed in later releases ?
> >
> >
> > Thank you for reporting a problem first of all.
> >
> > Do you write messages to one session from multiple threads?
> >
> > I have looked into our code and I found an obvious flaw both in encoding
> and
> > decoding, in 0.8 and 0.9, when encoding/decoding code is executed at the
> > same time.  For encoding, it can happen very easily by user.  But
> decoding
> > problem won't happen because we're using a leader-followers thread pool.
> > Decoding problem can appear if a user uses a different thread model such
> as
> > a simplistic thread pool model other than L-F thread pool model.  A
> possible
> > solution is to synchronize the execution block using
> ProtocolEncoderOutput
> > or ProtocolDecoderOutput.  Otherwise, we can create a new output
> instances
> > every time.  I cannot decide which side is more efficient easily.  Any
> idea?
> >
> > Trustin
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > --
> > PGP key fingerprints:
> > * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
> > * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message