You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Jim Gomes (JIRA)" <ji...@apache.org> on 2011/06/14 22:52:50 UTC
[jira] [Created] (AMQNET-330) MutexTransport creates bottleneck for
multi-threaded applications
MutexTransport creates bottleneck for multi-threaded applications
-----------------------------------------------------------------
Key: AMQNET-330
URL: https://issues.apache.org/jira/browse/AMQNET-330
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ, Stomp
Affects Versions: 1.5.1
Environment: Windows 7 64-bit, .NET 3.5 & 4.0.
Reporter: Jim Gomes
Assignee: Jim Gomes
Fix For: 1.5.2, 1.6.0
The MutexTransport creates a massive bottleneck in a multi-threaded application that uses timeouts for sending messages. This scenario makes the assumption that the failover protocol is being used to automatically reconnect to a broker that goes offline. If multiple threads are sending messages that have a send timeout and the broker is currently offline, then those calls get queued up in serial instead of executing in parallel. For example, if the send timeout is set to 10 seconds and 50 threads are simultaneously sending a message, it will take 500 seconds for all fifty threads to finally error out. The programmer of the code would expect the timeout to be 10 seconds maximum in order to have acceptable application performance.
The MutexTransport needs to honor and use the timeout value of the transport that it is protecting and allow parallel waits.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work stopped] (AMQNET-330) MutexTransport creates
bottleneck for multi-threaded applications
Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQNET-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on AMQNET-330 stopped by Jim Gomes.
> MutexTransport creates bottleneck for multi-threaded applications
> -----------------------------------------------------------------
>
> Key: AMQNET-330
> URL: https://issues.apache.org/jira/browse/AMQNET-330
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, Stomp
> Affects Versions: 1.5.1
> Environment: Windows 7 64-bit, .NET 3.5 & 4.0.
> Reporter: Jim Gomes
> Assignee: Jim Gomes
> Labels: mutex, timeout, transport
> Fix For: 1.5.2, 1.6.0
>
> Original Estimate: 2h
> Time Spent: 2h
> Remaining Estimate: 0h
>
> The MutexTransport creates a massive bottleneck in a multi-threaded application that uses timeouts for sending messages. This scenario makes the assumption that the failover protocol is being used to automatically reconnect to a broker that goes offline. If multiple threads are sending messages that have a send timeout and the broker is currently offline, then those calls get queued up in serial instead of executing in parallel. For example, if the send timeout is set to 10 seconds and 50 threads are simultaneously sending a message, it will take 500 seconds for all fifty threads to finally error out. The programmer of the code would expect the timeout to be 10 seconds maximum in order to have acceptable application performance.
> The MutexTransport needs to honor and use the timeout value of the transport that it is protecting and allow parallel waits.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (AMQNET-330) MutexTransport creates
bottleneck for multi-threaded applications
Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQNET-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on AMQNET-330 started by Jim Gomes.
> MutexTransport creates bottleneck for multi-threaded applications
> -----------------------------------------------------------------
>
> Key: AMQNET-330
> URL: https://issues.apache.org/jira/browse/AMQNET-330
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, Stomp
> Affects Versions: 1.5.1
> Environment: Windows 7 64-bit, .NET 3.5 & 4.0.
> Reporter: Jim Gomes
> Assignee: Jim Gomes
> Labels: mutex, timeout, transport
> Fix For: 1.5.2, 1.6.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> The MutexTransport creates a massive bottleneck in a multi-threaded application that uses timeouts for sending messages. This scenario makes the assumption that the failover protocol is being used to automatically reconnect to a broker that goes offline. If multiple threads are sending messages that have a send timeout and the broker is currently offline, then those calls get queued up in serial instead of executing in parallel. For example, if the send timeout is set to 10 seconds and 50 threads are simultaneously sending a message, it will take 500 seconds for all fifty threads to finally error out. The programmer of the code would expect the timeout to be 10 seconds maximum in order to have acceptable application performance.
> The MutexTransport needs to honor and use the timeout value of the transport that it is protecting and allow parallel waits.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work logged] (AMQNET-330) MutexTransport creates bottleneck
for multi-threaded applications
Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQNET-330?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel\#worklog-{worklog.getId()} ]
Jim Gomes logged work on AMQNET-330:
------------------------------------
Author: Jim Gomes
Created on: 14/Jun/11 23:07
Start Date: 14/Jun/11 23:07
Worklog Time Spent: 2h
Work Description: Refactor MutexTransport to check for configured timeout while waiting to acquire mutex lock.
Issue Time Tracking
-------------------
Worklog Id: (was: 11334)
Time Spent: 2h
Remaining Estimate: 0h (was: 2h)
> MutexTransport creates bottleneck for multi-threaded applications
> -----------------------------------------------------------------
>
> Key: AMQNET-330
> URL: https://issues.apache.org/jira/browse/AMQNET-330
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, Stomp
> Affects Versions: 1.5.1
> Environment: Windows 7 64-bit, .NET 3.5 & 4.0.
> Reporter: Jim Gomes
> Assignee: Jim Gomes
> Labels: mutex, timeout, transport
> Fix For: 1.5.2, 1.6.0
>
> Original Estimate: 2h
> Time Spent: 2h
> Remaining Estimate: 0h
>
> The MutexTransport creates a massive bottleneck in a multi-threaded application that uses timeouts for sending messages. This scenario makes the assumption that the failover protocol is being used to automatically reconnect to a broker that goes offline. If multiple threads are sending messages that have a send timeout and the broker is currently offline, then those calls get queued up in serial instead of executing in parallel. For example, if the send timeout is set to 10 seconds and 50 threads are simultaneously sending a message, it will take 500 seconds for all fifty threads to finally error out. The programmer of the code would expect the timeout to be 10 seconds maximum in order to have acceptable application performance.
> The MutexTransport needs to honor and use the timeout value of the transport that it is protecting and allow parallel waits.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQNET-330) MutexTransport creates bottleneck
for multi-threaded applications
Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQNET-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Gomes resolved AMQNET-330.
------------------------------
Resolution: Fixed
> MutexTransport creates bottleneck for multi-threaded applications
> -----------------------------------------------------------------
>
> Key: AMQNET-330
> URL: https://issues.apache.org/jira/browse/AMQNET-330
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, Stomp
> Affects Versions: 1.5.1
> Environment: Windows 7 64-bit, .NET 3.5 & 4.0.
> Reporter: Jim Gomes
> Assignee: Jim Gomes
> Labels: mutex, timeout, transport
> Fix For: 1.5.2, 1.6.0
>
> Original Estimate: 2h
> Time Spent: 2h
> Remaining Estimate: 0h
>
> The MutexTransport creates a massive bottleneck in a multi-threaded application that uses timeouts for sending messages. This scenario makes the assumption that the failover protocol is being used to automatically reconnect to a broker that goes offline. If multiple threads are sending messages that have a send timeout and the broker is currently offline, then those calls get queued up in serial instead of executing in parallel. For example, if the send timeout is set to 10 seconds and 50 threads are simultaneously sending a message, it will take 500 seconds for all fifty threads to finally error out. The programmer of the code would expect the timeout to be 10 seconds maximum in order to have acceptable application performance.
> The MutexTransport needs to honor and use the timeout value of the transport that it is protecting and allow parallel waits.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira