Is this server ready for deployment for a chat application supporting 1mm
users or is it more in the prototype phase?
We will be using group chat, roles, moderators and adding some unique chat
threading models for distributed groups.
Thanks.
>
Huh?
On Thu, Apr 9, 2020 at 1:09 PM Weact wrote:
>
>
>
> Is this server ready for deployment for a chat application supporting 1mm
> users or is it more in the prototype phase?
>
>
>
> We will be using group chat, roles, moderators and adding some unique chat
> threading models for distributed
Dear All,
We have Server developed using MINA 2.0.16 where it connects
to two other systems say System-A and System-B.
The connectivity with both these system is persistence which means our
server connects and create only single session with each of these systems
and on the
Mina is a queue and flush framework. All writes are queued up and scheduled
later using the poll/kqueue system.
The ExecutorFilter uses threading to process incoming messages using a pool
of threads instead of the reactor/processor thread. This frees the
processor thread to do IO.
Have you
Dear Jonathan,
Thanks for the reply, can you provide more details on the "All writes
are queued up and scheduled
later using the poll/kqueue system." How this poll & kqueue system works? Do we
have any control on this from MINA framework?
We are not facing any problem with the higher
The ExecutorFilter only works for the Server receiver side.
When you say the responses are slow, what do you consider slow?
All writes are put into a queue dedicated for each session. The Session is
then enabled for writing by adding the write interest to the poll
mechanism. Reads and Writes
Dear Jonathan,
Our Server and System-B are on WAN network with leased line.
One more clarification required As per documentation
NioSocketConnector
Dear Jonathan,
Anytime we write message to System-B session with session.write method the
messageSent event has to be generated with it actually gets written on TCP/IP
org.apache.mina.core.session.IoSession.write(Object)
We see that there is time difference of 10-14 seconds between
Every IoSession is bound to one Processor Thread. So only by creating more
IoSessions can you take advantage of multiple Processor Threads.
ExecutorFilter only works for received messages. So it generally does
nothing on the client side however it will cause the received messages to
be executed
How far are the servers? TCP Packet loss could explain this.
You can get the Queue size from the IoSession object.
On Thu, Apr 9, 2020 at 10:02 AM Nitin Phuria
wrote:
> Dear Jonathan,
>
>
>
> Anytime we write message to System-B session with session.write method the
> messageSent event has to
On 09/04/2020 15:00, Jonathan Valliere wrote:
The ExecutorFilter only works for the Server receiver side.
Actually, it could be used on the client side too, but it makes little
sense, as the client is not supposed to receive heavy load from the
server (of course, there might be use cases
Dear Jonathan,
Thanks for bringing more clarity on Processor Thread and it's
relation with IoSession. We are also suspecting the network connection and in a
crisis one should pull all the strings to check where you get the lead to
identify the problem and that's what we are
Make sure you enable BBR TCP on your host machines to help mitigate the
network problems.
On Thu, Apr 9, 2020 at 10:58 AM Nitin Phuria
wrote:
> Dear Jonathan,
>
>
>
> Thanks for bringing more clarity on Processor Thread and
> it's relation with IoSession. We are also suspecting
On 09/04/2020 16:01, Nitin Phuria wrote:
Dear Jonathan,
Anytime we write message to System-B session with session.write method the
messageSent event has to be generated with it actually gets written on TCP/IP
The messageSent event is only generated when the message has been fully
14 matches
Mail list logo
