On 25/10/2024 07:43, Nitin Phuria wrote:
Hi,
Thanks for your quick response with few points to check.
We are not getting any sessionClosed or exceptionCaught event on this session.
We have also checked at OS level with netstat and could see that session was
available with ESTABLISHED state
Also before sending any message we have below check and if this is true then
only we write the message to session
if (session() != null && session().isConnected())
That does not mean the actual connection is still up. It gives you a
status of the session, not a status of the connection.
Pls let me know whether this above check is sufficient to assume that session
is not bad and it is good to write to this session.
You should assume that if you haven't receive a messageSent event when
you do a write, then you have an issue.
Also we want to understand if we are writing say 10 messages one after another
to session then they will be queued up to be written to session as single
thread will be doing this job. For some reason if this writing to session is
failed then will it skip the current message and take up next message to write?
As I understand the Codec Encoder will be called for this operation. Any error
in ProtocolEncoder will have any impact if one of the message it fails to write
to session.
Keep in mind that MINA is managing asynchronous operations. If the
remote peer is not capable of reading data for any reason, then when the
socket buffer is full, you won't be able to write any more data into it.
That means those messages/data will remain in a queue.
It's absolutely critical to check that any message being written has
been actually written (ie a messageSent event has been received),
otherwise you'll blow your client. This is also a typicl situation where
a slow reader might crash your client.
Thanks And Regards,
Nitin Phuria
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
Sent: 24 October 2024 23:34
To: Nitin Phuria; users@mina.apache.org
Subject: Re: MINA: Messages writen to session are not getting written to TCP/IP
and writeQueue count is increasing
Hi,
it's quite simple: if the remote server does not receive anything, that
means your server does not send anything.
As it worked for a while, it's very likely something happened that
closed the connection.
* Have you received a sessionClosed() on your server?
* Have you checked on the network side if a FW is closing the connection
for any reason?
In any case, MINA is just behaving as expected, it's up to you to check
if the connection is not up and running wioth the remote serevr. that
means if you write a message and aren't receiving a messageSent for this
message after a while, thn you have to act accordingly.
On 24/10/2024 08:23, Nitin Phuria wrote:
Dear All,
We have developed one server using Apache MINA V2.1.6 where multiple
vendors connect and send the messages which needs to be processed and then
response have to be sent back to vendor. Currently we have put a strategy
that vendor has to send one message per connection and after getting
response or timeout vendor has to close the connection.
We also have persistance connection open from our MINA based server
with third party server whcih is tcp/ip channel and for each vendor request
we get we have to send the received message to this third party server. Past
3-4 days we have observed that application works fine for some time and then
suddenly all the messages written to session.write method does not go to
TCP/Ip and no Message sent event is generated for them. When I checked the
session's getWriteRequestQueue().size() it is observed that it is
continuously increasing only.
This operation is asynchronous; IoHandler.messageSent(IoSession, Object)
will be invoked when the message is actually sent to remote peer. In our
observation we found that the messageSent was not called once we observe the
WriteRequestQueue(). Size started building up.
When we checked with third party server they told they are not receiving any
messages on the port where we have opened persistence connection and they
are listening on it.
Any possible checks that we need to do at OS level or Network level which
can give us lead for the problem will help. If we restart our Server then
again for sometime it will work and then same problem of WriteQueue size
build up will start.
We have our own ProtocolCodecFactory implemented is used for
endocing/decoding messages from our server to third party server.
We have no executorFilter in the chain.
Below is my Protocol Encoder class
public class DefaultMyMsgEncoder extends ProtocolEncoderAdapter
{
public DefaultMyMsgEncoder()
{
}
public void encode(IoSession session, Object msg, ProtocolEncoderOutput
out) throws Exception
{
MyMsg myMsg = (MyMsg) msg;
IoBuffer buffer =
IoBuffer.allocate(myMsg.getLengthBytes().length+myMsg.getMsgBytes().length
);
buffer.put(myMsg.getLengthBytes());
buffer.put(myMsg.getMsgBytes());
buffer.flip();
out.write(buffer);
}
}
Thanks in advance.
Thanks And Regards,
Nitin Phuria
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org
