[JBoss JIRA] Closed: (JBMESSAGING-92) Integrate and enable multiplex transport
by Ovidiu Feodorov (JIRA)
[ http://jira.jboss.com/jira/browse/JBMESSAGING-92?page=all ]
Ovidiu Feodorov closed JBMESSAGING-92.
--------------------------------------
Resolution: Out of Date
Will use "bisocket" instead.
> 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.Beta2
>
> 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
19 years, 7 months
[JBoss JIRA] Created: (JBAS-3958) org.jboss.test.txtimer.test.PersistenceTestCase failure with Sun 1.4.2_13
by Len DiMaggio (JIRA)
org.jboss.test.txtimer.test.PersistenceTestCase failure with Sun 1.4.2_13
-------------------------------------------------------------------------
Key: JBAS-3958
URL: http://jira.jboss.com/jira/browse/JBAS-3958
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-4.0.5.GA
Environment: OS: Red Hat Enterprise Linux 4/update4 (RHEL4/U4)
Arch: i386
JDK: java version "1.4.2_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06)
Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode)
Reporter: Len DiMaggio
Priority: Minor
These (4) tests are failing with the 1.4.2_13 JDK:
Suite: org.jboss.test.txtimer.test.PersistenceTestCase
Test: testSingleEventDuration
Type: failure
Exception: junit.framework.AssertionFailedError
Message: unexpected handle count expected:<0> but was:<6>
junit.framework.AssertionFailedError: unexpected handle count expected:<0> but was:<6>
at org.jboss.test.txtimer.test.PersistenceTestCase.testSingleEventDuration(PersistenceTestCase.java:84)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
---------------------------------
Suite: org.jboss.test.txtimer.test.PersistenceTestCase
Test: testRestoreToEntity
Type: failure
Exception: junit.framework.AssertionFailedError
Message: unexpected handle count expected:<0> but was:<6>
junit.framework.AssertionFailedError: unexpected handle count expected:<0> but was:<6>
at org.jboss.test.txtimer.test.PersistenceTestCase.testRestoreToEntity(PersistenceTestCase.java:115)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
---------------------------------
Suite: org.jboss.test.txtimer.test.PersistenceTestCase
Test: testRestoreToSession
Type: failure
Exception: junit.framework.AssertionFailedError
Message: unexpected handle count expected:<0> but was:<6>
junit.framework.AssertionFailedError: unexpected handle count expected:<0> but was:<6>
at org.jboss.test.txtimer.test.PersistenceTestCase.testRestoreToSession(PersistenceTestCase.java:165)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
---------------------------------
Suite: org.jboss.test.txtimer.test.PersistenceTestCase
Test: testPersistenceEquality
Type: failure
Exception: junit.framework.AssertionFailedError
Message: unexpected handle count expected:<0> but was:<6>
junit.framework.AssertionFailedError: unexpected handle count expected:<0> but was:<6>
at org.jboss.test.txtimer.test.PersistenceTestCase.testPersistenceEquality(PersistenceTestCase.java:216)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
--
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
19 years, 7 months
[JBoss JIRA] Assigned: (JBMESSAGING-355) Remove possibility of delivery race conditions
by Juha Lindfors (JIRA)
[ http://jira.jboss.com/jira/browse/JBMESSAGING-355?page=all ]
Juha Lindfors reassigned JBMESSAGING-355:
-----------------------------------------
Assignee: Tim Fox (was: Juha Lindfors)
> Remove possibility of delivery race conditions
> ----------------------------------------------
>
> Key: JBMESSAGING-355
> URL: http://jira.jboss.com/jira/browse/JBMESSAGING-355
> Project: JBoss Messaging
> Issue Type: Task
> Reporter: Tim Fox
> Assigned To: Tim Fox
> Fix For: 1.0.2.CR1
>
> Attachments: race-condition.log
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> Currently race conditions can occur on message delivery where the delivery is acknowledged or cancelled before the call to handle has returned.
> In ChannelState we defensively program against this by synchronizing on the returned delivery and by dealing with the situation where the delivery does not exist in the channel state and ignoring.
> See ChannelSupport::deliver() and ChannelState.cancelDelivery.
> This approach has the following problems:
> Complexity of code to maintain and understand.
> Where acks return quickly we are likely to get contention on the lock in ChannelSupport::deliver, thus reducing throughput.
> A much simpler solution enables us to remove the possibility of such race conditions and remove the corresponding lock contention.
> This can be done by adding a confirm() method on Delivery.
> When the receiver receives the message in it's handle() call, before dispatching the message it calls Delivery::confirm. This results in the channel adding the delivery to the channel state. Thus we can be assured that the delivery exists before any acknowledgment or cancellation comes in.
> This is a very simple change.
--
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
19 years, 7 months