You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@mina.apache.org by Max Larsson <ma...@facilityboss.biz> on 2025/07/21 09:20:00 UTC
Possible bug in CumulativeProtocolDecoder
Hi everyone,
especially to Emmanuel for driving mina forward.
I think I found a bug in mina core 2.1.10 in 2.1.9 I cannot reproduce it.
It has to do with CumulativeProtocolDecoder class and I think it was introduced with the following patch:
https://github.com/apache/mina/commit/88cb55397c414c6d09ce2d085ce912ab4bf45bf3
The bug isn’t easily reproducible, so I will first describe how the bug expresses. Best to describe is
A simple visualization. We have real messages t1 to tx which are really send via a TCP/IP connection
And we have decoded message m1 to mx, which appears finally in the messageReceived method
Of my IOHandler. During the communication the following happens “out of the blue”:
t1 -> m1
t2 -> m2
t3 -> m3
t4 -> m3 m4
t5 -> m3 m4 m5
…..
I don’t know if it ever “resets” itself, because my business logic is getting panic at t4.
The prerequisite for triggering this behaviour is that the MessageDecoder returns a NEED_DATA,
but it isn’t always the case that a NEED_DATA triggers the behaviour.
Now comes my observations:
* The NEED_DATA converts the IoBuffer used into a session buffer
* It copies un the unprocessed data into the session buffer
* Waits for more data to received
* No if new data arrives it is appended to the session buffer
* The message encoder decodes the messages return OK
* There aren’t any remaining bytes in the session buffer
* Lets assume position in the session buffer is 256
* Now the session buffer gets “freed”
* If now new data arrives it is appended to the session buffer
* Than flip gest called on the session buffer
That sets the position of the buffer to 0, at that position is still
The data from the previous successful decoded data.
To “fix” it the position should either be set to 256 or the “freed”
Operation should really discard the successful decoded data.
HTH and is understandable. In doubt ask me.
Kind regards
Max
Mit freundlichen Grüßen
Best regards
Dipl.-Inform. Max Larsson
Geschäftsleitung
________________________________
[https://facilityboss.biz/themes/gavias_tico/facilitybossCCS.png]<https://apps.apple.com/us/app/capture-codes-scanner/id6503239357>
Need to easily scan multiple codes in one go?
Use our app facilityboss Capture Code Scanner!
Müssen Sie mehrere Codes in einem Durchgang scannen?
Verwenden Sie unsere App facilityboss Capture Code Scanner.
[Download on the App Store]<https://apps.apple.com/us/app/capture-codes-scanner/id6503239357?itsct=apps_box_badge&itscg=30200>
________________________________
[LinkedIn - facilityboss]<https://www.linkedin.com/company/facilityboss-gmbh>
________________________________
email: max.larsson@facilityboss.biz<ma...@facilityboss.biz>
web: https://facilityboss.biz
[facilityboss]<https://facilityboss.biz>
Bad Nauheimer Str. 4
64289 Darmstadt
Germany
Sitz der Gesellschaft: Darmstadt
Registergericht: Amtsgericht Darmstadt, HRB 86193
Geschäftsführer: Dipl.-Inform Max Lars Robert Larsson
________________________________
Diese E-Mail enthält unter Umständen vertrauliche und/oder rechtlich geschützte Informationen, die allein für den Adressaten bestimmt sind. Wenn Sie nicht der zutreffende Adressat sind oder diese E-Mail irrtümlich erhalten haben, ist jede Verwendung, Verbreitung, Kopie oder Bezugnahme auf den Inhalt dieser E-Mail verboten. Bitte informieren Sie uns über einen eventuellen Irrtum per Telefon, per Telefax oder E-Mail.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reference on the contents of this e-mail is strictly prohibited. If you have received this e-mail in error please notify us by e-mail, facsimile or phone call.
Re: Possible bug in CumulativeProtocolDecoder
Posted by Max Larsson <ma...@facilityboss.biz>.
Hi Emmanuel,
not the gathering of the data is stopped. Instead (already successful) the processed data
is repeatedly process again by my implementation of
class XXX extends MessageDecoderAdapter implements MessageDecoder {
…
public MessageDecoderResult decodable( final IoSession session,final IoBuffer buffer ) {
try {
final int index = CONTENT_LENGTH_HEADER.length();
if( buffer.remaining() < index )
return MessageDecoderResult.NEED_DATA;
final CharsetDecoder UTF_DECODER = StandardCharsets.UTF_8.newDecoder();
if( !CONTENT_LENGTH_HEADER.equals( buffer.getString( index,UTF_DECODER ) ) )
return MessageDecoderResult.NOT_OK;
final StringBuilder contentLengthStr = new StringBuilder();
while( buffer.remaining() > 0 ) {
final byte digit = buffer.get();
if( digit == LF )
break;
contentLengthStr.append( (char)digit );
}
if( buffer.get() != LF )
return MessageDecoderResult.NEED_DATA;
final int contentLength = Integer.parseInt( contentLengthStr.toString().trim() );
if( buffer.remaining() < contentLength )
return MessageDecoderResult.NEED_DATA;
if( !decodeableXML( session,buffer.getString( contentLength,UTF_DECODER ) ) )
return MessageDecoderResult.NOT_OK;
return MessageDecoderResult.OK;
}
catch( final BufferUnderflowException buf ) {
buffer.reset();
return MessageDecoderResult.NEED_DATA;
}
catch( final CharacterCodingException cce ) {
throw new RuntimeException( cce.getMessage(),cce );
}
}
...
}
(Sorry I cannot post the whole code, but the code is more than 5 years old and reliably working in production
environments.)
Thus I don’t use a limiter directly, it has a header the bytes is send of the payload.
HTH
Max
From: Emmanuel Lecharny <el...@gmail.com>
Date: Thursday, 24. July 2025 at 10:27
To: users@mina.apache.org <us...@mina.apache.org>
Subject: Re: Possible bug in CumulativeProtocolDecoder
Hi Max,
if I understand correctly,n the message that the Handler receives may
contain more than one protocol message (m3 m4), as if the gathering of
data is not stopped?
I'll try to check the code, there may be something fishy...
Could you tell which limiter you use?
On 21/07/2025 11:20, Max Larsson wrote:
> Hi everyone,
>
> especially to Emmanuel for driving mina forward.
>
> I think I found a bug in mina core 2.1.10 in 2.1.9 I cannot reproduce it.
> It has to do with CumulativeProtocolDecoder class and I think it was introduced with the following patch:
> https://github.com/apache/mina/commit/88cb55397c414c6d09ce2d085ce912ab4bf45bf3
>
> The bug isn’t easily reproducible, so I will first describe how the bug expresses. Best to describe is
> A simple visualization. We have real messages t1 to tx which are really send via a TCP/IP connection
> And we have decoded message m1 to mx, which appears finally in the messageReceived method
> Of my IOHandler. During the communication the following happens “out of the blue”:
>
> t1 -> m1
> t2 -> m2
> t3 -> m3
> t4 -> m3 m4
> t5 -> m3 m4 m5
> …..
>
> I don’t know if it ever “resets” itself, because my business logic is getting panic at t4.
>
> The prerequisite for triggering this behaviour is that the MessageDecoder returns a NEED_DATA,
> but it isn’t always the case that a NEED_DATA triggers the behaviour.
>
> Now comes my observations:
>
>
> * The NEED_DATA converts the IoBuffer used into a session buffer
> * It copies un the unprocessed data into the session buffer
> * Waits for more data to received
> * No if new data arrives it is appended to the session buffer
> * The message encoder decodes the messages return OK
> * There aren’t any remaining bytes in the session buffer
> * Lets assume position in the session buffer is 256
> * Now the session buffer gets “freed”
> * If now new data arrives it is appended to the session buffer
> * Than flip gest called on the session buffer
>
> That sets the position of the buffer to 0, at that position is still
>
> The data from the previous successful decoded data.
>
>
>
> To “fix” it the position should either be set to 256 or the “freed”
>
> Operation should really discard the successful decoded data.
>
>
>
> HTH and is understandable. In doubt ask me.
>
>
>
> Kind regards
>
>
>
> Max
>
>
>
>
>
> Mit freundlichen Grüßen
> Best regards
>
> Dipl.-Inform. Max Larsson
> Geschäftsleitung
>
> ________________________________
> [https://facilityboss.biz/themes/gavias_tico/facilitybossCCS.png]<https://apps.apple.com/us/app/capture-codes-scanner/id6503239357<https://facilityboss.biz/themes/gavias_tico/facilitybossCCS.png%5d%3chttps:/apps.apple.com/us/app/capture-codes-scanner/id6503239357>>
>
> Need to easily scan multiple codes in one go?
> Use our app facilityboss Capture Code Scanner!
>
> Müssen Sie mehrere Codes in einem Durchgang scannen?
> Verwenden Sie unsere App facilityboss Capture Code Scanner.
>
> [Download on the App Store]<https://apps.apple.com/us/app/capture-codes-scanner/id6503239357?itsct=apps_box_badge&itscg=30200>
> ________________________________
> [LinkedIn - facilityboss]<https://www.linkedin.com/company/facilityboss-gmbh>
> ________________________________
>
> email: max.larsson@facilityboss.biz<ma...@facilityboss.biz>
> web: https://facilityboss.biz
>
> [facilityboss]<https://facilityboss.biz>
>
> Bad Nauheimer Str. 4
> 64289 Darmstadt
> Germany
>
> Sitz der Gesellschaft: Darmstadt
> Registergericht: Amtsgericht Darmstadt, HRB 86193
> Geschäftsführer: Dipl.-Inform Max Lars Robert Larsson
>
> ________________________________
>
> Diese E-Mail enthält unter Umständen vertrauliche und/oder rechtlich geschützte Informationen, die allein für den Adressaten bestimmt sind. Wenn Sie nicht der zutreffende Adressat sind oder diese E-Mail irrtümlich erhalten haben, ist jede Verwendung, Verbreitung, Kopie oder Bezugnahme auf den Inhalt dieser E-Mail verboten. Bitte informieren Sie uns über einen eventuellen Irrtum per Telefon, per Telefax oder E-Mail.
>
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reference on the contents of this e-mail is strictly prohibited. If you have received this e-mail in error please notify us by e-mail, facsimile or phone call.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@mina.apache.org
For additional commands, e-mail: users-help@mina.apache.org
Mit freundlichen Grüßen
Best regards
Dipl.-Inform. Max Larsson
Geschäftsleitung
________________________________
[https://facilityboss.biz/themes/gavias_tico/facilitybossCCS.png]<https://apps.apple.com/us/app/capture-codes-scanner/id6503239357>
Need to easily scan multiple codes in one go?
Use our app facilityboss Capture Code Scanner!
Müssen Sie mehrere Codes in einem Durchgang scannen?
Verwenden Sie unsere App facilityboss Capture Code Scanner.
[Download on the App Store]<https://apps.apple.com/us/app/capture-codes-scanner/id6503239357?itsct=apps_box_badge&itscg=30200>
________________________________
[LinkedIn - facilityboss]<https://www.linkedin.com/company/facilityboss-gmbh>
________________________________
email: max.larsson@facilityboss.biz<ma...@facilityboss.biz>
web: https://facilityboss.biz
[facilityboss]<https://facilityboss.biz>
Bad Nauheimer Str. 4
64289 Darmstadt
Germany
Sitz der Gesellschaft: Darmstadt
Registergericht: Amtsgericht Darmstadt, HRB 86193
Geschäftsführer: Dipl.-Inform Max Lars Robert Larsson
________________________________
Diese E-Mail enthält unter Umständen vertrauliche und/oder rechtlich geschützte Informationen, die allein für den Adressaten bestimmt sind. Wenn Sie nicht der zutreffende Adressat sind oder diese E-Mail irrtümlich erhalten haben, ist jede Verwendung, Verbreitung, Kopie oder Bezugnahme auf den Inhalt dieser E-Mail verboten. Bitte informieren Sie uns über einen eventuellen Irrtum per Telefon, per Telefax oder E-Mail.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reference on the contents of this e-mail is strictly prohibited. If you have received this e-mail in error please notify us by e-mail, facsimile or phone call.
Re: Possible bug in CumulativeProtocolDecoder
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Max,
if I understand correctly,n the message that the Handler receives may
contain more than one protocol message (m3 m4), as if the gathering of
data is not stopped?
I'll try to check the code, there may be something fishy...
Could you tell which limiter you use?
On 21/07/2025 11:20, Max Larsson wrote:
> Hi everyone,
>
> especially to Emmanuel for driving mina forward.
>
> I think I found a bug in mina core 2.1.10 in 2.1.9 I cannot reproduce it.
> It has to do with CumulativeProtocolDecoder class and I think it was introduced with the following patch:
> https://github.com/apache/mina/commit/88cb55397c414c6d09ce2d085ce912ab4bf45bf3
>
> The bug isn’t easily reproducible, so I will first describe how the bug expresses. Best to describe is
> A simple visualization. We have real messages t1 to tx which are really send via a TCP/IP connection
> And we have decoded message m1 to mx, which appears finally in the messageReceived method
> Of my IOHandler. During the communication the following happens “out of the blue”:
>
> t1 -> m1
> t2 -> m2
> t3 -> m3
> t4 -> m3 m4
> t5 -> m3 m4 m5
> …..
>
> I don’t know if it ever “resets” itself, because my business logic is getting panic at t4.
>
> The prerequisite for triggering this behaviour is that the MessageDecoder returns a NEED_DATA,
> but it isn’t always the case that a NEED_DATA triggers the behaviour.
>
> Now comes my observations:
>
>
> * The NEED_DATA converts the IoBuffer used into a session buffer
> * It copies un the unprocessed data into the session buffer
> * Waits for more data to received
> * No if new data arrives it is appended to the session buffer
> * The message encoder decodes the messages return OK
> * There aren’t any remaining bytes in the session buffer
> * Lets assume position in the session buffer is 256
> * Now the session buffer gets “freed”
> * If now new data arrives it is appended to the session buffer
> * Than flip gest called on the session buffer
>
> That sets the position of the buffer to 0, at that position is still
>
> The data from the previous successful decoded data.
>
>
>
> To “fix” it the position should either be set to 256 or the “freed”
>
> Operation should really discard the successful decoded data.
>
>
>
> HTH and is understandable. In doubt ask me.
>
>
>
> Kind regards
>
>
>
> Max
>
>
>
>
>
> Mit freundlichen Grüßen
> Best regards
>
> Dipl.-Inform. Max Larsson
> Geschäftsleitung
>
> ________________________________
> [https://facilityboss.biz/themes/gavias_tico/facilitybossCCS.png]<https://apps.apple.com/us/app/capture-codes-scanner/id6503239357>
>
> Need to easily scan multiple codes in one go?
> Use our app facilityboss Capture Code Scanner!
>
> Müssen Sie mehrere Codes in einem Durchgang scannen?
> Verwenden Sie unsere App facilityboss Capture Code Scanner.
>
> [Download on the App Store]<https://apps.apple.com/us/app/capture-codes-scanner/id6503239357?itsct=apps_box_badge&itscg=30200>
> ________________________________
> [LinkedIn - facilityboss]<https://www.linkedin.com/company/facilityboss-gmbh>
> ________________________________
>
> email: max.larsson@facilityboss.biz<ma...@facilityboss.biz>
> web: https://facilityboss.biz
>
> [facilityboss]<https://facilityboss.biz>
>
> Bad Nauheimer Str. 4
> 64289 Darmstadt
> Germany
>
> Sitz der Gesellschaft: Darmstadt
> Registergericht: Amtsgericht Darmstadt, HRB 86193
> Geschäftsführer: Dipl.-Inform Max Lars Robert Larsson
>
> ________________________________
>
> Diese E-Mail enthält unter Umständen vertrauliche und/oder rechtlich geschützte Informationen, die allein für den Adressaten bestimmt sind. Wenn Sie nicht der zutreffende Adressat sind oder diese E-Mail irrtümlich erhalten haben, ist jede Verwendung, Verbreitung, Kopie oder Bezugnahme auf den Inhalt dieser E-Mail verboten. Bitte informieren Sie uns über einen eventuellen Irrtum per Telefon, per Telefax oder E-Mail.
>
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reference on the contents of this e-mail is strictly prohibited. If you have received this e-mail in error please notify us by e-mail, facsimile or phone call.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@mina.apache.org
For additional commands, e-mail: users-help@mina.apache.org