[
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