[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-326) Create the concept of a "priority queue" to speed execution of certain remote method invocations

[Vladimir Blagojevic (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBCACHE-326?page=all ]

Vladimir Blagojevic updated JBCACHE-326:
----------------------------------------

    Fix Version/s: 2.1.0.GA
                       (was: 2.0.0.GA)

Brian said:

That should definitely be pushed out of 2.0.0. Maybe we should keep the JIRA open for a while, as it still may be a useful concept. Maybe not though; if you can't think of any situation where one message from a sender would block execution of another message from the *same* sender, then the JIRA probably serves no purpose.  The case that led to the JIRA was:

1) prepare from server A acquires locks on B.
2) prepare from server C blocks up_thread on B waiting for locks.
3) commit/rollback from server A stuck in queue behind prepare from server C.

ConcurrentStack solves that problem.

Bela and I had a brief discussion on the JG dev list shortly before Xmas about adding the ability to execute RpcDispatcher calls using a thread pool / Executor.  If we ever did implement JBCACHE-326, I'm sure it would be built on top of that feature.


> Create the concept of a "priority queue" to speed execution of certain remote method invocations
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-326
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-326
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.1.0.GA
>
>
> Change the handling of requests in JBossCache (another  interceptor on top of ReplicationInterceptor): 
> - Create 2 queues (of MethodCall objects), one thread for each queue 
> - The regular MethodCalls like put(), remove() etc go into the  default queue (A), where they are processed according to order (FIFO) 
> - The special calls like block(), _getState(), commit() or acks  for PREPARE/COMMIT calls go into the other (priority) queue (B),  these calls *CAN* be received out of sequence 
> - This way, an _getState() would always be processed and  would be able to (1) stop the processing of queue A and (2) force- release any locks held 
>   by on the tree.
> _ This way commit() calls can promptly release locks, without having to wait behind other prepare calls.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira