[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Some comments on Clebert's last commit

clebert.suconic@jboss.com do-not-reply at jboss.com
Thu Jan 22 09:59:42 EST 2009


"Tim Fox" wrote : 1) Forcing depage. I don't get this. Looking at the code I can see you force a depage if the reference isn't found in the queue
  | 
  | a) I notice you only force one depage - How can you be sure the required message is in the next page? It might be in any page after that.
  | 
  | b) Let's say you force a depage and the message *is* in there, the message will get depaged and routed to the queue. I can't see anywhere where the reference is then removed from the queue. Could this lead to duplicate deliveries?
  | 

There's a loop there:
         for (;;) // I'm changing this for while(true)
  |          {
  |             // Can't have the same store being depaged in more than one thread
  |             synchronized (store)
  |             {
  |                // as soon as it gets the lock, it needs to verify if another thread couldn't find the reference
  |                ref = messageQueue.removeReferenceWithID(id);
  |                if (ref == null)
  |                {
  |                   // force a depage
  |                   if (!store.readPage())
  |                   {
  |                      break;
  |                   }
  |                }
  |                else
  |                {
  |                   break;
  |                }
  |             }
  |          }
  | 


And on the backup, that's the only time we depage until it is activated

"timfox" wrote : 
  | 2) Address is being passed on replicate delivery mesage. This worries me for performance reasons. Can't we do this another way?
  | 

I have removed it here locally. I'll use the messageQueue.getName() :-)

"timfox" wrote : 
  | 3) Precalculation of flow control
  | 
  | a) if ((creditsUsed -= chunk.getRequiredBufferSize()) < 0)
  | 
  | Looks suspicious - this will actually decrement the creditsUsed variable
  | 
  | 

I'm renaming this variable to precalculateAvailableCredits.
We take the credits in advance from the preCalculateFlowControl, and I keep sending while I have precalculateAvailableCredits

"timfox" wrote : 
  | 
  | b) Can you be sure that the first large message chunk gets sent iirespective or available credits? - we need to ensure this to avoid blocking
  | 

I will take a look, but how this would avoid blocking?



"Tim Fox" wrote : 
  | c) pre-calculation of credits seems very complex... looks like it could do with some optimisation


I don't know...

All the equations I tried had an indefinition where I would need a loop series to solve it.

I will try to think a little bit more.


"Tim Fox" wrote : 
  | 
  | MultiThreadRandomFailoverTest is running a lot slower 
  | 
  | 


I just did a comparisson before and after my commit, and it ran the same.

However the test runs much slower on Hudson. Maybe there is a VM on the non-vm queue by accident?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204039#4204039

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204039



More information about the jboss-dev-forums mailing list