Hello, Thanks for the response. I did more digging and now I just want to talk about my first issue as the second seems independent and a pain to reproduce. So, my problem is that I have the AbstractIoSession.scheduledWriteMessages increase 3 times but decreased only once. More detailed context: - I have a particular message send by the server called NotifyDeliver which is encode in 3 parts (see code of encodeOptimisedNotifyDeliver after) - In ProtocolCodecFilter.filterWrite the NotifyDeliver is encoded in 3 parts, and then in the while loop, each part are sent to the next filter. I noted that the 2 first parts are enclosed in the private class EncodedWriteRequest which only Override isEncoded so it returns true. - Each of the 3 message parts end up in HeadFilter.filterWrite where scheduledWriteMessages is increased each time. That is also where I noticed that prior to 2.1.1, scheduledWriteMessages was increased only - if (!writeRequest.isEncoded()) - Here the 3 parts are also added a queue, and as M. Lécharny explained, the IoProcessor fires MessageSent events - The 3 corresponding event are fired as I saw 3 calls of DefaultIoFilterChain.fireMessageSent but here there is this code : if (!request.isEncoded()) { callNextMessageSent(head, session, request); } - Because the two first writeRequest are actually 2 EncodedWriteRequest, callNextMessageSent is done only on the 3rd part. - So, TailFilter.messageSent is only called once, and decreases scheduledWriteMessages (through ((AbstractIoSession) session).increaseWrittenMessages(writeRequest, now); ) only once.
I was able to make it work so scheduledWriteMessages is decreased 3 times by removing the if (!request.isEncoded()) condition in DefaultIoFilterChain.fireMessageSent and also removing this code from ProtocolCodecFilter.messageSent which was also blocking the chain to TailFilter: if (writeRequest instanceof EncodedWriteRequest) { return; } I precise that my NotifyDeliver message is well received by my client (all data is checked and correct). The only problem is scheduledWriteMessages being incorrect and, as I said in my previous email, I was using it for another message checking the connection. I hope I gave enough info to determine if I'm doing something bad or if it is a bug in Mina. RM The code encoding NotifyDeliver message : private static void encodeOptimisedNotifyDeliver (ProtocolEncoderOutput out, NotifyDeliver notifyDeliver) { IoBuffer headerBuffer = IoBuffer.allocate (20); IoBuffer matchesBuffer = IoBuffer.allocate (256); IoBuffer attributesBuffer = notifyDeliver.original.rawAttributes.asReadOnlyBuffer (); matchesBuffer.setAutoExpand (true); putLongArray (matchesBuffer, notifyDeliver.secureMatches); putLongArray (matchesBuffer, notifyDeliver.insecureMatches); matchesBuffer.flip (); int frameSize = 4 + attributesBuffer.limit () + matchesBuffer.limit (); notifyDeliver.frameSize = frameSize; headerBuffer.putInt (frameSize); headerBuffer.putInt (NotifyDeliver.ID); headerBuffer.flip (); out.write (headerBuffer); out.write (attributesBuffer); out.write (matchesBuffer); } -----Message d'origine----- De : Emmanuel Lécharny <elecha...@gmail.com> Envoyé : jeudi 6 février 2025 17:04 À : users@mina.apache.org Objet : Re: Problem with AbstractIoSession.scheduledWriteMessages [mina 2.1.X] 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/DefaultIoFi > lterChain.java > b/mina-core/src/main/java/org/apache/mina/core/filterchain/DefaultIoFi > lterChain.java > --- > a/mina-core/src/main/java/org/apache/mina/core/filterchain/DefaultIoFi > lterChain.java > +++ b/mina-core/src/main/java/org/apache/mina/core/filterchain/Default > +++ IoFilterChain.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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org