[
http://jira.jboss.com/jira/browse/JBCACHE-326?page=comments#action_12343627 ]
Brian Stansberry commented on JBCACHE-326:
------------------------------------------
I'm not 100% sure, but this likely won't improve much for state transfer once
FLUSH is done. I guess the benefit would be if block call were stuck in the jg up queue
because a preceding repl msg is held up by a lock conflict. Probably we should wait and
see what comes out of implementing block() .
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.0.0
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