Hi,
you definitively should jump to 2.2.4 instead of transiting by 2.1.x. In
any case, would you decide to use 2.X branch, use 2.1.10.
That being said,
On 06/02/2025 14:57, MARQUERIE Rémi wrote:
Hello,
First, I want to say that I’m not sure it’s a problem in Mina or the way we use
it in our project.
Context and mina version:
I’m currently trying to upgrade the mina version used in my project from mina
2.0.7 to 2.1.X (first trying to 2.1.7 then maybe to 2.1.10).
The problem :
The class AbstractIoSession has a member scheduledWriteMessages. It is
increased when HeadFilter.filterWrite is called (file
DefaultIoFilterChain.java) ; then it is decreased when the message is sent.
Actually, it's decreased when the message *has* been sent. Just to
clarify, because the message goes through the chain back to the
IoProcessor, and is stored in a queue. When the IoProcssor can send the
message fully, it generates a MessageSent event, which is processed back
by the chain, where the counter can now be decremented.
In my problematic case, I use a ProtocolCodecFilter and for some message, when
the filterWrite method is called, it goes into this while loop :
// Code in ProtocolCodecFilter.java
// Write all the encoded messages now
while (!bufferQueue.isEmpty()) {
Object encodedMessage = bufferQueue.poll();
if (encodedMessage == null) {
break;
}
// Flush only when the buffer has remaining.
if (!(encodedMessage instanceof IoBuffer) || ((IoBuffer)
encodedMessage).hasRemaining()) {
if (bufferQueue.isEmpty()) {
writeRequest.setMessage(encodedMessage);
nextFilter.filterWrite(session, writeRequest);
} else {
SocketAddress destination =
writeRequest.getDestination();
WriteRequest encodedWriteRequest = new
EncodedWriteRequest(encodedMessage, null, destination);
nextFilter.filterWrite(session, encodedWriteRequest);
}
}
}
// Fin Code in ProtocolCodecFilter.java
Which is find, it will just generate as many message to be written as
there are enqueued message in the buffer.
Here we see 2 calls of nextFilter.filterWrite. In my case, the loop is done 3
times so nextFilter.filterWrite is called 2 times with a new
EncodedWriteRequest and once (the last) by passing the processed WriteRequest.
Those 3 calls end up to HeadFilter.filterWrite and so scheduledWriteMessages is
then equal to 3. When the message is sent, scheduledWriteMessages is decreased
only once so now scheduledWriteMessages is 2.
It can't be. The counter is incremented in the HeadFilter every time a
writeFilter call is made. Each message is contained in its own
WriteRequest, and this is what matters.
I’ve noticed the problem appeared in 2.1.1 with this commit : “2d08d53 - Pushed
my current changes related to the filterWrite refactoring”
diff --git
a/mina-core/src/main/java/org/apache/mina/core/filterchain/DefaultIoFilterChain.java
b/mina-core/src/main/java/org/apache/mina/core/filterchain/DefaultIoFilterChain.java
---
a/mina-core/src/main/java/org/apache/mina/core/filterchain/DefaultIoFilterChain.java
+++
b/mina-core/src/main/java/org/apache/mina/core/filterchain/DefaultIoFilterChain.java
@@ -907,4 +906,2 @@
- if (!writeRequest.isEncoded()) {
- s.increaseScheduledWriteMessages();
- }
+ s.increaseScheduledWriteMessages();
So before this commit, increaseScheduledWriteMessages was called only once as
the 2 first time the writeRequest isEncoded.
This scheduledWriteMessages is not used in mina (src or test), but in my
project, we used it to check connection problems. As a temporary fix, I just
removed the use of scheduledWriteMessages; and I thought a possible patch for
mina would be to recheck the isEncoded like in 2.1.0.
BUT ! Then I tried using mina 2.1.10 and a new problem arise with the same
message. So, a bit more of context:
* The client sends the problematic request message
* The server receives the request (triggering the 3 scheduledWriteMessages
increase)
* The it sends the associated response.
With mina 2.1.7, the client received one response and everything works after
that, but not with mina 2.1.10 where for the next good request I receive a
response for the previous problematic request and then the good response.
Seems like the problem is that 2 wrong messages never get send with MINA
2.1.7, AFAIU...
For clarity let’s call the problematic request and response PRqst and PResp ,
and let’s call anther Good Request/Response GRqst/GResp. From my client I see
that :
* Send PRqst
* Receive PResp
* Wait some time // The problem appears wether I add this wait or not
* Send GRqst
* Receive PResp
* Receive GResp
So, because of this problem, I don’t know if it is a problem in Mina or how I
use it. I searched the commits between 2.1.7 and 2.1.10 for clues, but could
not find anything.
If someone could give me some more info, that would be great 😊
I may miss some points, because there are some missing context, but
basically:
- for every message that goes to the write chain and get queued to be
sent back to the client, the writeMessage counter isincremented
- for every message unqueued from the pending message and physically
sent to the client (ie for which the IoProcessor *can* actually write
all the bytes in the socket, regardless of the client receiving them),
the messageSent even is propagated to the Handler through the chain
- When a messageSent is processed, then the scheduledWritesMessages
counter is decremented
At least, this is how it is supposed to work.
Now, back to your need: you want to avoid sending a problematic response
to the client when it send a proper request.
The thing is that the first problematic message has most certainly
generated many problematic response, and they haven't been read by the
client, so they are pending in the IoProcessor queue until the client is
ready to read something. They will stay there simply because it's up to
the client to read an discard them!
What I mean is that the server either determinate that the incoming
message is wrong, and don't send back a message the client wont read, or
you are pretty much stuck...
Thanks, and have a nice day.
RM
--
------------------------ Emmanuel Lécharny emm...@worteks.com
elecha...@apache.org ------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org
