You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2007/01/28 04:42:36 UTC
Re: Message rate and size throttle
Sorry for getting back to you so late.
On 11/30/06, seven <ho...@gmail.com> wrote:
>
> Hello,
>
> I am studying the possibility of migrating a custom blocking network java
> server to a mina based NIO one in order to be able to handle more clients
> and higher throughput.
> The server in question has the following features:
> - ObjectStream based
We don't use ObjectInput/OutputStream directly, but we use their modified
version which is optimized for non-blocking I/O. Anyway, you can exchange
serialized Java object.
- incoming message rate is controlled
MINA doesn't support it right now, but it can be implemented.
- outgoing message rate is controlled and if the client can't consume
> the outgoing massage rate the client is disconnected
You can calculate it by yourself, and disconnect.
- SSL support
SSL is supported out of the box.
- compression support based on the message size ( if the serialized
> message object size is higher than a certain threshold then the message is
> compressed )
Instead, we use JZlib (Java implementation of zlib) to compress the stream.
I never saw the case that compression ratio is poor.)
Can you advise if this is possible? Can mina provide the those features (
> except ObjectStreaming but with serializable objects ) using NIO?
Nothing is impossible, but we need to think a little bit differently because
we're no longer dealing with a stream but with an event.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Message rate and size throttle
Posted by Horia Muntean <ho...@gmail.com>.
Hi,
My first try on controlling the incomming message rate was something like
this (server IoHandler):
public void messageReceived(final IoSession session, Object message) {
//business message processing ...
session.suspendRead();
Executors.newSingleThreadScheduledExecutor().schedule(new Runnable()
{
public void run() {
session.resumeRead();
}
},1000, TimeUnit.MILLISECONDS);
}
This was supposed to limit the incoming message rate at 1/sec.
The first message was received and the first suspendRead() suspended the
messageReceived callbacks.
But after 1 second when resumeRead was issued, the messageReceived callback
rate was out of control meaning that the second suspendRead had no effect,
the messages kept pouring in.
Regards,
Horia
On 2/7/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi Horia,
>
> On 2/5/07, Horia Muntean <ho...@gmail.com> wrote:
> >
> > Hello,
> >
> > After further study I think I found a way to disconnect a slow client.
> > IoSession.getScheduledWritesRequests() should give me the number of
> > pending messages that were not yet written to the remote peer, so if this
> > number exceeds a certain threshold I could issue IoSession.close().
>
>
> True.
>
> As far as controlled incoming message rate is concerned I experimented a
> > little with IoSession.suspendRead() but I found out it will not do. I
> > mean the first suspendRead is doing what it says but after the first
> > resumeRead the incomming messages rate can't be controlled. So, do you think
> > I could file a RFE on Jira about this issue? Or is there a possible solution
> > with the current framework?
>
>
> You could suspend again as rate increases. suspending and resuming
> continuously will do the trick, no?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
>
Re: Message rate and size throttle
Posted by Trustin Lee <tr...@gmail.com>.
Hi Horia,
On 2/5/07, Horia Muntean <ho...@gmail.com> wrote:
>
> Hello,
>
> After further study I think I found a way to disconnect a slow client.
> IoSession.getScheduledWritesRequests() should give me the number of
> pending messages that were not yet written to the remote peer, so if this
> number exceeds a certain threshold I could issue IoSession.close().
True.
As far as controlled incoming message rate is concerned I experimented a
> little with IoSession.suspendRead() but I found out it will not do. I mean
> the first suspendRead is doing what it says but after the first resumeRead
> the incomming messages rate can't be controlled. So, do you think I could
> file a RFE on Jira about this issue? Or is there a possible solution with
> the current framework?
You could suspend again as rate increases. suspending and resuming
continuously will do the trick, no?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Message rate and size throttle
Posted by Martin Ritchie <ri...@apache.org>.
On 04/02/07, Horia Muntean <ho...@gmail.com> wrote:
> Hello,
>
> After further study I think I found a way to disconnect a slow client.
> IoSession.getScheduledWritesRequests() should give me the number of pending
> messages that were not yet written to the remote peer, so if this number
> exceeds a certain threshold I could issue IoSession.close().
>
> As far as controlled incoming message rate is concerned I experimented a
> little with IoSession.suspendRead() but I found out it will not do. I mean
> the first suspendRead is doing what it says but after the first resumeRead
> the incomming messages rate can't be controlled. So, do you think I could
> file a RFE on Jira about this issue? Or is there a possible solution with
> the current framework?
>
> Regards,
> Horia
>
>
> On 1/28/07, Trustin Lee <tr...@gmail.com> wrote:
> >
> > Sorry for getting back to you so late.
> >
> > On 11/30/06, seven <ho...@gmail.com> wrote:
> > >
> > > Hello,
> > >
> > > I am studying the possibility of migrating a custom blocking network
> > > java
> > > server to a mina based NIO one in order to be able to handle more
> > > clients
> > > and higher throughput.
> > > The server in question has the following features:
> > > - ObjectStream based
> >
> >
> > We don't use ObjectInput/OutputStream directly, but we use their modified
> > version which is optimized for non-blocking I/O. Anyway, you can exchange
> > serialized Java object.
> >
> > - incoming message rate is controlled
> >
> >
> > MINA doesn't support it right now, but it can be implemented.
> >
> > - outgoing message rate is controlled and if the client can't consume
> > > the outgoing massage rate the client is disconnected
> >
> >
> > You can calculate it by yourself, and disconnect.
> >
> > - SSL support
> >
> >
> > SSL is supported out of the box.
> >
> > - compression support based on the message size ( if the serialized
> > > message object size is higher than a certain threshold then the message
> > > is
> > > compressed )
> >
> >
> > Instead, we use JZlib (Java implementation of zlib) to compress the
> > stream. I never saw the case that compression ratio is poor.)
> >
> > Can you advise if this is possible? Can mina provide the those features (
> > > except ObjectStreaming but with serializable objects ) using NIO?
> >
> >
> > Nothing is impossible, but we need to think a little bit differently
> > because we're no longer dealing with a stream but with an event.
> >
> > HTH,
> > Trustin
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > --
> > PGP key fingerprints:
> > * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> > * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
You could also look at this write filter throttle:
https://issues.apache.org/jira/browse/DIRMINA-302
I've not had a chance to check out the developments since 1.0.1 so
this may not work with the current trunk.
--
Martin Ritchie
Re: Message rate and size throttle
Posted by Horia Muntean <ho...@gmail.com>.
Hello,
After further study I think I found a way to disconnect a slow client.
IoSession.getScheduledWritesRequests() should give me the number of pending
messages that were not yet written to the remote peer, so if this number
exceeds a certain threshold I could issue IoSession.close().
As far as controlled incoming message rate is concerned I experimented a
little with IoSession.suspendRead() but I found out it will not do. I mean
the first suspendRead is doing what it says but after the first resumeRead
the incomming messages rate can't be controlled. So, do you think I could
file a RFE on Jira about this issue? Or is there a possible solution with
the current framework?
Regards,
Horia
On 1/28/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Sorry for getting back to you so late.
>
> On 11/30/06, seven <ho...@gmail.com> wrote:
> >
> > Hello,
> >
> > I am studying the possibility of migrating a custom blocking network
> > java
> > server to a mina based NIO one in order to be able to handle more
> > clients
> > and higher throughput.
> > The server in question has the following features:
> > - ObjectStream based
>
>
> We don't use ObjectInput/OutputStream directly, but we use their modified
> version which is optimized for non-blocking I/O. Anyway, you can exchange
> serialized Java object.
>
> - incoming message rate is controlled
>
>
> MINA doesn't support it right now, but it can be implemented.
>
> - outgoing message rate is controlled and if the client can't consume
> > the outgoing massage rate the client is disconnected
>
>
> You can calculate it by yourself, and disconnect.
>
> - SSL support
>
>
> SSL is supported out of the box.
>
> - compression support based on the message size ( if the serialized
> > message object size is higher than a certain threshold then the message
> > is
> > compressed )
>
>
> Instead, we use JZlib (Java implementation of zlib) to compress the
> stream. I never saw the case that compression ratio is poor.)
>
> Can you advise if this is possible? Can mina provide the those features (
> > except ObjectStreaming but with serializable objects ) using NIO?
>
>
> Nothing is impossible, but we need to think a little bit differently
> because we're no longer dealing with a stream but with an event.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6