Norval, Trustin,
I have to leave for some vacations (bus in 45 minutes, and I still have
to take a shower, dress and have breakfast). I will be back in 5 days.
Seems that Norval came with a solution, I let you guys experiment and
have fun with MINA while I will get some rest on a boat :)
Have fun !
Norval Hope wrote:
Hi Guys,
Can I say from my point of view that I'll be happy with any solution
matching roughly the same ApacheDS behaviour that my patch submitted
to http://issues.apache.org/jira/browse/DIRSERVER-1161 achieves, which
used a blocking queue as a simple way of throttling the server when
talking to a slow client. I can see that checking scheduledWriteBytes
could provide another alternative and don't have a problem with this
approach as long as people more expert in MINA / ApacheDS do the
coding :-)
Emmanuel - in raising starting this thread on MINA-DEV I justed wanted
to check if you think this is the whole answer to DIRSERVER-1161 or
just one part of it? From what I've seen in my debugging sessions the
rest of my patch is needed as otherwise the server keeps writing and
flushing messages but they are never sent to the client, hence the
need for the server to drain the search results in a separate thread.
Thanks,
Norval
On Mon, Apr 14, 2008 at 11:38 AM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
Emmanuel Lecharny wrote:
> "이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote:
>> Hi Emmanuel,
>>
> Hi again,
>> You might be interested in the following question from Gaston Dombiak:
>>
>> http://markmail.org/message/uylaf2zauta6ppe7
>>
>> And there's an answer there in my response made at 9 Apr 2008.
>>
> I don't think that your answer fits well in the scope of the question I
> pushed. We don't want to throttle write on the server side, we just want
> to send bytes as fast as possible, but be sure that those bytes are sent
> and read by the client before sending some new (which will have to be
> accumulated somewhere on the server until you get an OOM).
>
> This is really a critical issue for every server using MINA as a
> malicious client could perfectly be use to kill the server just by
> sending a request and never reading more than a few bytes of data, if I
> interpret correctly what I have seen.
The client might be malicious or not because it can be simply slow
without its will. Whatever kind of client is connected, the server
should be responsible for slow connection. Again, there are two mechanisms:
1) Check scheduledWriteBytes before you write. If you are going to
stream many messages, you might not want to write all of them
immediately but want to write them chunk by chunk. Then you can check
the scheduledWriteBytes in your WriteFuture listener or messageSent
event handler.
2) There's writeTimeout property if a client is not reading even one
message.
> Peter Royal suggested to use a Callback to handle with such a problem,
> and it sounds like a good idea (we have listeners we can use for that in
> WriteFuture), but this has to be done in the ProtocolCodecFilter code,
> which is a part of the MINA API.
It's a good idea to privde a solution for preventing OOM due to fast
write. Also, I think it's a must-have feature for all clients and
servers. Therefore, what about adding the following two properties:
* IoSessionConfig.scheduledWriteBytesThreshold
* IoSessionConfig.scheduledWriteMessagesThreshold
and making MINA to raise an exception when
scheduledWrite(Bytes|Messages) becomes too large. Then your IoHandler
will be notified with an exceptionCaught event.
WDYT?
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
