Hi, I have a couple of points:
1) Non-Functional Req. 5. Blocking send().
I think that you need to have an option to allow the send to either time out (which can be 0 for no-wait i.e Send message or throw timeout exception) or have an explict buffer full style exception. My use case is that somewhere the network or the broker goes unresponsive and so the send() will block for the TCP timeout. Which in Mina is two minutes in the new IO I guess it would be something similar. We should not penalise applications that chose to call send() on a critical thread such as the Java event dispatcher. If we do block then the users entire application could lock up until the connection is broken. This would be undesirable and we should not force the application developer to work with a blocking synchronous send() method. Of course happy to relinquish the point if other JMS providers do not provide such a facility on their async send() calls.
2) Overview of Design. Para4 Incomming data is processed one frame at a time![]()
:
Does this not present a potential performance slow down? Currently we have two threads one decoding the wire into a queue of incomming frames and one batch processing a number of frames from the incomming queue. My concern here (though it may be baseless) is that with a single frame to process on any one pass the broker may have reduced throughput as the broker may be waiting for incomming frames. Now if the approach is to have space for a single decoded frame between IO and broker and the broker removes that frame whilst it processes it, so allowing the IO layer to pull in the next frame, then things might be ok. I guess there are two scenarios I'm thinking of here:
a) the broker processes the frame faster than the next can be decoded.. in which case no buffer would be built up to process unless there was a period of inactivity.
b) the broker is slower in which case a single frame would not impact performance.
So, now I've written it down I'm not so sure it is an issue but I do recall we added the batch processing in the broker to improve performance. My concern here is that we are potentially over looking the performance implications of not having a buffer of frames for processing.
