[JBoss JIRA] Updated: (JBMESSAGING-275) Move Selector processing IN the Channel
by Ovidiu Feodorov (JIRA)
[ http://jira.jboss.com/jira/browse/JBMESSAGING-275?page=all ]
Ovidiu Feodorov updated JBMESSAGING-275:
----------------------------------------
Priority: Major (was: Critical)
> Move Selector processing IN the Channel
> ---------------------------------------
>
> Key: JBMESSAGING-275
> URL: http://jira.jboss.com/jira/browse/JBMESSAGING-275
> Project: JBoss Messaging
> Issue Type: Task
> Components: Messaging Core
> Reporter: Ovidiu Feodorov
> Assigned To: Tim Fox
> Fix For: 1.2.0.Beta1
>
> Original Estimate: 2 weeks
> Remaining Estimate: 2 weeks
>
> Currently, a consumer "arrests" a message that is being handled to it and doesn't match the Selector. That means it returns an active Delivery for it, but it doesn't forward the message to the client. This is because the consumer needs to be able to receiver further messages coming after the non-matching message, and that may potentially match the selector.
> This is a poor solution that doesn't scale. We may end up with lots of non-matching messages being "arrested" by a consumer, while they could just be simply returned to the channel and forwarded to other potential consumers.
> A possible (right) approach is to move selector processing in the Channel, so the message is not even handled to the non-accepting cosumer. Review this and refactor.
--
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
18 years, 3 months
[JBoss JIRA] Updated: (JBMESSAGING-92) Integrate and enable multiplex transport
by Ovidiu Feodorov (JIRA)
[ http://jira.jboss.com/jira/browse/JBMESSAGING-92?page=all ]
Ovidiu Feodorov updated JBMESSAGING-92:
---------------------------------------
Priority: Major (was: Critical)
> Integrate and enable multiplex transport
> ----------------------------------------
>
> Key: JBMESSAGING-92
> URL: http://jira.jboss.com/jira/browse/JBMESSAGING-92
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: JMS Remoting
> Reporter: Ovidiu Feodorov
> Assigned To: Ron Sigal
> Fix For: 1.2.0.Beta1
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Replace "Connector per Consumer" solution with a Remoting UIL2-like transport
> The ConsumerInterceptor creates a new Connector instance per each Consumer, and associates maintains a reference to it as transitory metadata, so it can shut it down when the Consumer closes.
> The Connector is necessary as a callback server for asynchronous notifications. The MessageCallbackHandler instance is registered to it. Maintaining an instance per Consumer is necessary to avoid port conflicts.
> This is a temporary solution until JBoss Remoting gets an UIL2-like transport.
> As long as we maintain a server socket per consumer, it won't be possbile to receive asynchronous notifications over firewalls.
> until multiplex performance is better it should not be the default tranport but should be available nevertheless
--
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
18 years, 3 months
[JBoss JIRA] Created: (JGRP-335) Hangs with FLUSH
by Bela Ban (JIRA)
Hangs with FLUSH
----------------
Key: JGRP-335
URL: http://jira.jboss.com/jira/browse/JGRP-335
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3 SP1
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4
2 use cases where we can run into the problem (members A and B).
#1 View change
* A is running, B joins
* B is *not* blocking in FLUSH, A is blocking after START_FLUSH
* A starts the flush
* A returns the new view to B in a JOIN_RSP. This causes B's Channel.connect() to return
* B sends a unicast message to A, to which A sends a response *in the same thread* (service STATE_REQ)
* A competes the flush, multicasting a STOP_FLUSH message
* The STATE_REQ at A hangs on FLUSH.down()
* The STOP_FLUSH at A can never unblock FLUSH.down() because it was received *after* the STATE_REQ from B !
SOLUTION:
1. Make B block in FLUSH.down() as soon as the client sends the JOIN_REQ to A
2. Make STOP_FLUSH *synchronous*. This means we only return from Channel.connect() (for example) once every member has ack'ed the STOP_FLUSH. See next issue (state transfer) for a description of what happens if we don't do this.
#2 State transfer
* A and B are members of the group
* B calls Channel.getState()
* A and B receive a START_FLUSH, start the block in FLUSH
* State is transferred from A to B
* B multicasts a STOP_FLUSH and *immediately afterwards* sends a *unicast* message (which can 'pass' multicast messages, as they're unrelated)
* A happens to receive the unicast message *before* the STOP_FLUSH. The unicast blocks and the STOP_FLUSH, which would unblock it, cannot be delivered
SOLUTION:
1. Same as solution 2 above. If we make the STOP_FLUSH phase synchronous, connect() or getState() only return once everyone has been unblocked
LONG TERM SOLUTION:
* The much better solution of course is to make the STOP_FLUSH message *out-of-band*, so it can be delivered in parallel to other messages, and is not blocked (e.g.) by the unicast in the queue. So even if the unicast message was blocked waiting for STOP_FLUSH, once STOP_FLUSH has been received, it will be delivered, causing the unicast to unblock
* Once we have this solution in place (2.5, threadless stack and out-of-band messages), we can revert the STOP_FLUSH to only use 1 phase rather than 2
--
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
18 years, 3 months