Thanks you all for your reply. I managed to resolve it, actually mina functionality is that if it receive less bytes to read it tries to shrink the read buffer size, and when next line is longer then read buffer size at that time it reads data in two chunks I just set the min read buffer size as max and that solve the issue
-----Original Message----- From: Jonathan Valliere [mailto:jon.valli...@emoten.com] Sent: Tuesday, January 15, 2019 1:43 AM To: users@mina.apache.org Subject: Re: MINA filter chains breaking under stress Upon a quick review of your email, I have the following notes. The filterchain is not thread safe. You have to write threadsafe filters. You must also make your encoded message system threadsafe. Just as with SSL the actual encoding process must occur within a synchronized block. As far as ProtocolCodecFilter goes, I will have to look into that. On Mon, Jan 14, 2019 at 8:37 AM Max Larsson <max.lars...@facilityboss.biz> wrote: > I don't yet have a test case for the issues, but i have a description > from a colleague in German under which circumstances this behavior > occurs using Apache Mina 2.0.19: > > - There must be multiple Threads (at least two) calling nearly > simultaneously session.write and there must be multiple > ProtocolCodecFilter in the FilterChain, whereas the first encoder > doesn't produce messages of type IoBuffer > > - For example if thread A calls session.write and the first > ProtocolCodecFilter has processed the write request, there will be an > encoded message in the WriteRequestQueue of the session. Lets assume > that it is an byte array. > > - Now if another thread B even called session.write in such > circumstances that the call of thread B has passed all FilterChain and > it is in progress to call > AbstractPollingIoProcessor$Processor.flushNow(), the encoded message > from thread A (which still is in process to complete FilterChain) > result in the known error "Don't know how to handle message of type > 'xyz'. Are you missing a protocol encoder?' > > - all following calls to session.write (regardless which thread) will > even produce the error, because the following snippet (somewhere in mina): > > // Check for pending writes. > req = session.getCurrentWriteRequest(); > if (req == null) { > req = writeRequestQueue.poll(session); > if (req == null) { > break; > } > session.setCurrentWriteRequest(req); > } > > always return the same incomplete encoded message at line 'req = > session.getCurrentWriteRequest();', > because it isn't removed from initial first faulty processing. > > > I hope someone understand whats going on, and if someone could tell > me, if it is a bug in mina or a faulty usage of mina. > > best regards > > Max Larsson > > > > -- > Sent from: > http://apache-mina.10907.n7.nabble.com/Apache-MINA-User-Forum-f31345.h > tml > -- CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html <http://www.techmahindra.com/Disclaimer.html> externally http://tim.techmahindra.com/tim/disclaimer.html <http://tim.techmahindra.com/tim/disclaimer.html> internally within TechMahindra. ============================================================================================================================
