This content has been marked as final.
Show 2 replies
-
1. Re: JBoss Messaging Core
adrian.brock Jan 19, 2005 6:16 PM (in response to ovidiu.feodorov)Congrats Ovidiu.
Some early comments:
I want to see some work done on the persistence layer, in particular
the equivalent of these tasks for JBossMQ:
http://jira.jboss.com/jira/browse/JBMQ-12
http://jira.jboss.com/jira/browse/JBMQ-11
These will be the most important aspects for performance and scalability
and they can't just be bolted on later without proper consideration of
how they should be plugged in.
I don't see any notion of MessageCache for scalability.
I also don't see any notion of ordering of messages (another important feature).
Finally, I don't like this style of code:public boolean deliver() { synchronized(channelLock) { // try to flush the message store for(Iterator i = unacked.iterator(); i.hasNext(); ) { Routable r = (Routable)i.next(); try { if (receiver.handle(r)) { i.remove(); } } catch(Throwable t) { // most likely the receiver is broken, don't insist break; } } return unacked.isEmpty(); } }
LOCKING
1) It is usually not a good idea to "call out" from inside a synchronized block.
You loose all hope of trying to control the locking strategy, in particular avoiding
deadlocks.
2) It is even worse in this case since Receiver is something you let
other people plugin.
3) If you look at my earlier prototype, this was deliberatley done in two stages
http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-jms/src/main/org/jboss/messaging/channel/plugins/handler/Attic/AbstractChannelHandler.java?annotate=1.1
lock();
try
{
decideWhatToDoForOneMessageWhileWeHaveGuaranteedState();
}
finally
{
unlock();
}
doWhatWasDecidedInsideTheLock();
ERRORS AND LOGGING
1) It is a good that you are catching Throwable but you should never just eat
error messages without some sort of logging.
2) I would expect to see some TRACE logging that will allow developers to
see what is going on when resolving problems.
e.g. Look at what JBossMQ does (where every major event is logged at tracel level):
http://cvs.sourceforge.net/viewcvs.py/jboss/jbossmq/src/main/org/jboss/mq/server/BasicQueue.java?annotate=1.42.2.1 -
2. Re: JBoss Messaging Core
ovidiu.feodorov Jan 20, 2005 2:33 PM (in response to ovidiu.feodorov)1) Persistence
I want to see some work done on the persistence layer, in particular
the equivalent of these tasks for JBossMQ:
http://jira.jboss.com/jira/browse/JBMQ-12
http://jira.jboss.com/jira/browse/JBMQ-11
These will be the most important aspects for performance and scalability
and they can't just be bolted on later without proper consideration of
how they should be plugged in.
The persistence support was only briefly addressed so far. Everything related to persistence is "hidden" behind the MessageStore and AcknowledgmentStore interfaces. I expect that their implementation will delegate the persistence work to a PersistenceManager, which will the subject of various optimizations.
I created a new JIRA task for that: http://jira.jboss.com/jira/browse/JBMESSAGING-18. It contains the initial specifications (JBMQ-11 and JBMQ-12).
The corresponding forum thread is http://www.jboss.com/index.html?module=bb&op=viewtopic&t=59084
2) MessageCache
The MessageStore functions as a MessageCache too. It first caches the messages in memory and/or reliably store if necessary. When I will detail the implemetation of the MessageStore, this will become more obvious. See "MessageStore/AcknowledgmentStore" section in the core design document: http://www.jboss.org/wiki/Wiki.jsp?page=JBossMessagingCore
3) Message Ordering
Good point. http://jira.jboss.com/jira/browse/JBMESSAGING-19
4) Errors and Logging
What I usually do is that I use DEBUG statements for logging life-cycle related operations and TRACE for logging individual requests. I will sprinkle them around more liberally.