[
http://issues.apache.org/jira/browse/DIRMINA-263?page=comments#action_12435275
]
Hooman Valibeigi commented on DIRMINA-263:
------------------------------------------
Thank you very much Niklas
- I managed to solve the problem with CumulativeProtocolDecoder.
however I think this class should be an essential part of IoHandler otherwise
the program will not work correctly.
using this class as a filter, means that it is optional an can be ignored.
whereas it is seriously important.
- as I understood each session should have a new instance of
CumulativeProtocolDecoder to have a separate comulative buffer, so how much
memory does a server with about 100 online clients need in this situation ?
- Another question I have is about broadcating a Message/ByteBuffer to all
clients
currently my logic is as follows
void broadcastMessage(Message message) {
ByteBuffer buf = MessageEncoder.ObjectToByteBuffer(message);
Iterator<IoSession> iterator = clients.iterator();
while (iterator.hasNext()) {
IoSession session = iterator.next();
if (session.isConnected()) {
buf.acquire();
buf.position(0);
session.write(buf).join();
}
}
buf.release();
}
the question is about the join() for each write(). otherwise I think we will be
in trouble since we shared the same buffer among all sessions. am I right ?
could the above code be written more efficiently ?
- also in the field of broadcasting. what is the recommended and intellectual
way in MINA ?
should it be done in the same thread as messageRecieved ? ( for example for a
chat server we broadcast messages just as we recieve them in messageRecieved )
- is it possible to write to a session concurrently ?
- it will be perfect if the above questions that any beginner like me might ask
you, be explained inside the documentation
Thank you in advance.
> Partially read messages
> -----------------------
>
> Key: DIRMINA-263
> URL: http://issues.apache.org/jira/browse/DIRMINA-263
> Project: Directory MINA
> Issue Type: Wish
> Affects Versions: 0.9.5
> Environment: win xp
> Reporter: Hooman Valibeigi
>
> assume we have a client that sends its requests consecutively ()
> I tested it using MINA and I found that MINA only notifies the server side
> IoHandler one time for a sequence of requests
> I mean when the client sends 3 consecutive requests the server's
> messageReceived method will be invoked only once
> (a Request in my opinion is a package containing a request ID and data
> related to the request)
> so my question is how should we handle the ByteBuffer that contains more than
> one requests ?
> the other IoSessions should not wait while the server is processing the
> interminable requests of a client
> in other word the server becomes busy while processing all sent and incoming
> requests of one client and may never finish
> even If it responds to the first buffered request in ByteBuffer and leave the
> remaining requests in hope that they will remain intact for the next
> messageReceived invocation from the same IoSession, it is wrong, since any
> remaining byte in ByteBuffer will be released after the messageReceived
> method is finished, whether we read them or not
> so we should read all the incoming bytes or we will lose them
> I ask you what is the correct solution to handle these kind of requests ?
> in short, I want to process one request per messageReceived invocation and I
> expect that IoHandler will notify me again if I have unread data from
> previous messageReceived calls
> this question may be translated in other way as below
> when is messageReceived invoked ?
> - when the selecetor selects a socket which is readable ?
> - so what happens if I dont process all the available data (all requests)
> within the ByteBuffer in one shot ?
> - also another question arise. is there any chance that the ByteBuffer
> parameter from messageReceived, does not have the full request data ? I mean
> is it possible that a request arives in several messageReceived calls ? I ask
> this because a ByteBuffer has a limit so It brings in mind that we may
> encounter several problems
> such that
> - a ByteBuffer containing one partial request
> - a ByteBuffer containing more than one request (all complete)
> - a ByteBuffer containing more than one request (but the last one is partial)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira