[jira] [Updated] (QPID-7720) Java client hangs when publishing to C++ broker queue with flow control activated
[ https://issues.apache.org/jira/browse/QPID-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Baronti updated QPID-7720: - Attachment: QPID-7720.patch Patch > Java client hangs when publishing to C++ broker queue with flow control > activated > - > > Key: QPID-7720 > URL: https://issues.apache.org/jira/browse/QPID-7720 > Project: Qpid > Issue Type: Bug > Components: Java Common >Affects Versions: qpid-java-6.1.1 >Reporter: Flavio Baronti > Attachments: QPID-7720.patch > > > This is probably the same as QPID-4073. > When a C++ flow controlled queue is overfull, the broker stops sending > acknowledgements to client commands. This causes the internal command queue > of the client to become full. > In this situation, the client sends a flush request, then waits for the > internal queue to free some space. Unfortunately, the broker will answer to > the flush request with an empty response, and will not send anything else > when the queue becomes underfull again. Thus the client dies with a timeout. > I suggest a patch which sends again the flush command every 500ms, up to the > configured timeout. If the queue becomes underfull within the timeout, the > broker will answer with a non-empty response, and the client will restart > processing. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7720) Java client hangs when publishing to C++ broker queue with flow control activated
Flavio Baronti created QPID-7720: Summary: Java client hangs when publishing to C++ broker queue with flow control activated Key: QPID-7720 URL: https://issues.apache.org/jira/browse/QPID-7720 Project: Qpid Issue Type: Bug Components: Java Common Affects Versions: qpid-java-6.1.1 Reporter: Flavio Baronti This is probably the same as QPID-4073. When a C++ flow controlled queue is overfull, the broker stops sending acknowledgements to client commands. This causes the internal command queue of the client to become full. In this situation, the client sends a flush request, then waits for the internal queue to free some space. Unfortunately, the broker will answer to the flush request with an empty response, and will not send anything else when the queue becomes underfull again. Thus the client dies with a timeout. I suggest a patch which sends again the flush command every 500ms, up to the configured timeout. If the queue becomes underfull within the timeout, the broker will answer with a non-empty response, and the client will restart processing. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7237) Excessive threads creation when suspending/resuming flow
[ https://issues.apache.org/jira/browse/QPID-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276214#comment-15276214 ] Flavio Baronti commented on QPID-7237: -- Keith, unfortunately I had this behavior only in the production environment, where I can't take the risk to test the new implementation. I reviewed your proposal, and I agree it would avoid the error I got after the client spawned over 8k threads. However, in the situation I observed, it would create tasks in the executor service queue, which might get out of control anyway - and filling the heap rather than exhausting the available threads, so the likelihood of this happening is quite lower. > Excessive threads creation when suspending/resuming flow > > > Key: QPID-7237 > URL: https://issues.apache.org/jira/browse/QPID-7237 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24, qpid-java-6.0.2 >Reporter: Flavio Baronti >Assignee: Keith Wall > Fix For: qpid-java-6.0.3, qpid-java-6.1 > > Attachments: QPID-7237.patch > > > In high load situations, with a NO_ACKNOWLEDGE session, it is possible for > the client to create an excessive amount of threads to suspend/resume the > channel. > I'm providing a patch to avoid creating a new thread if the previous thread > has not completed its operation. This patch appears to avoid the problem in > our environment. Notice we are using version 0.24, but the code is the same > in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7237) Excessive threads creation when suspending/resuming flow
[ https://issues.apache.org/jira/browse/QPID-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263713#comment-15263713 ] Flavio Baronti commented on QPID-7237: -- This is somewhat connected to QPID-1084. > Excessive threads creation when suspending/resuming flow > > > Key: QPID-7237 > URL: https://issues.apache.org/jira/browse/QPID-7237 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24, qpid-java-6.0.2 >Reporter: Flavio Baronti > Attachments: QPID-7237.patch > > > In high load situations, with a NO_ACKNOWLEDGE session, it is possible for > the client to create an excessive amount of threads to suspend/resume the > channel. > I'm providing a patch to avoid creating a new thread if the previous thread > has not completed its operation. This patch appears to avoid the problem in > our environment. Notice we are using version 0.24, but the code is the same > in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7237) Excessive threads creation when suspending/resuming flow
[ https://issues.apache.org/jira/browse/QPID-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Baronti updated QPID-7237: - Attachment: QPID-7237.patch > Excessive threads creation when suspending/resuming flow > > > Key: QPID-7237 > URL: https://issues.apache.org/jira/browse/QPID-7237 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24, qpid-java-6.0.2 >Reporter: Flavio Baronti > Attachments: QPID-7237.patch > > > In high load situations, with a NO_ACKNOWLEDGE session, it is possible for > the client to create an excessive amount of threads to suspend/resume the > channel. > I'm providing a patch to avoid creating a new thread if the previous thread > has not completed its operation. This patch appears to avoid the problem in > our environment. Notice we are using version 0.24, but the code is the same > in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7237) Excessive threads creation when suspending/resuming flow
Flavio Baronti created QPID-7237: Summary: Excessive threads creation when suspending/resuming flow Key: QPID-7237 URL: https://issues.apache.org/jira/browse/QPID-7237 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: qpid-java-6.0.2, 0.24 Reporter: Flavio Baronti In high load situations, with a NO_ACKNOWLEDGE session, it is possible for the client to create an excessive amount of threads to suspend/resume the channel. I'm providing a patch to avoid creating a new thread if the previous thread has not completed its operation. This patch appears to avoid the problem in our environment. Notice we are using version 0.24, but the code is the same in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5334) Low throughput with thousands of queues
[ https://issues.apache.org/jira/browse/QPID-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823788#comment-13823788 ] Flavio Baronti commented on QPID-5334: -- With this code, how can I know for which binding the message was sent to the receiver? In the example the bindings are simple, but in the actual application I will have bindings with * and #, so a simple string compare with qpid.subject is not sufficient. Low throughput with thousands of queues --- Key: QPID-5334 URL: https://issues.apache.org/jira/browse/QPID-5334 Project: Qpid Issue Type: Improvement Components: C++ Broker, Java Client Affects Versions: 0.24 Environment: Broker: Linux 2.6.32 64bit Client: Windows 7, Java 1.7.0_21 64bit Reporter: Flavio Baronti Labels: performance Attachments: JMSGenerator.java, JMSReceiver.java, use_shared_session_queue.patch I have an use case where I need to create hundreds of thousands of queues, each one subscribed to a different topic (therefore I have as many topics as queues). I set up a test with a single producer generating data on a randomly chosen topic, and a receiver retrieving data from the queues (and throwing it away). I'm using the JMS api, and doing the obvious thing makes the throughput drop dramatically from 10k msg/sec with a single topic/queue (around the top my network adapter can sustain) to 20 msg/sec with 100k topics/queues. I found out that I can recover performance by using more JMS sessions and connections - e.g. create 4 connections with 100 sessions each, and randomly distributing the receiving queues on them. This however is less than ideal, since with the JMS client a thread is created for each session, I can manage the workload with 1 thread only when it's over a single queue. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5334) Low throughput with thousands of queues
Flavio Baronti created QPID-5334: Summary: Low throughput with thousands of queues Key: QPID-5334 URL: https://issues.apache.org/jira/browse/QPID-5334 Project: Qpid Issue Type: Improvement Components: C++ Broker, Java Client Affects Versions: 0.24 Environment: Broker: Linux 2.6.32 64bit Client: Windows 7, Java 1.7.0_21 64bit Reporter: Flavio Baronti I have an use case where I need to create hundreds of thousands of queues, each one subscribed to a different topic (therefore I have as many topics as queues). I set up a test with a single producer generating data on a randomly chosen topic, and a receiver retrieving data from the queues (and throwing it away). I'm using the JMS api, and doing the obvious thing makes the throughput drop dramatically from 10k msg/sec with a single topic/queue (around the top my network adapter can sustain) to 20 msg/sec with 100k topics/queues. I found out that I can recover performance by using more JMS sessions and connections - e.g. create 4 connections with 100 sessions each, and randomly distributing the receiving queues on them. This however is less than ideal, since with the JMS client a thread is created for each session, I can manage the workload with 1 thread only when it's over a single queue. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5334) Low throughput with thousands of queues
[ https://issues.apache.org/jira/browse/QPID-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Baronti updated QPID-5334: - Attachment: JMSReceiver.java JMSGenerator.java Two test clients in Java, one to generate data, one to receive. Playing with the parameters (number of topics, number of sessions/connections) shows that while the generator can maintain its output throughput, the receiver cannot sustain a high throughput with many topics and few sessions. Low throughput with thousands of queues --- Key: QPID-5334 URL: https://issues.apache.org/jira/browse/QPID-5334 Project: Qpid Issue Type: Improvement Components: C++ Broker, Java Client Affects Versions: 0.24 Environment: Broker: Linux 2.6.32 64bit Client: Windows 7, Java 1.7.0_21 64bit Reporter: Flavio Baronti Labels: performance Attachments: JMSGenerator.java, JMSReceiver.java I have an use case where I need to create hundreds of thousands of queues, each one subscribed to a different topic (therefore I have as many topics as queues). I set up a test with a single producer generating data on a randomly chosen topic, and a receiver retrieving data from the queues (and throwing it away). I'm using the JMS api, and doing the obvious thing makes the throughput drop dramatically from 10k msg/sec with a single topic/queue (around the top my network adapter can sustain) to 20 msg/sec with 100k topics/queues. I found out that I can recover performance by using more JMS sessions and connections - e.g. create 4 connections with 100 sessions each, and randomly distributing the receiving queues on them. This however is less than ideal, since with the JMS client a thread is created for each session, I can manage the workload with 1 thread only when it's over a single queue. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5334) Low throughput with thousands of queues
[ https://issues.apache.org/jira/browse/QPID-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820253#comment-13820253 ] Flavio Baronti commented on QPID-5334: -- CPU usage with few sessions is higher on the broker, and lower on the client. Increasing the number of session increases the load on the client, and lowers it on the broker. In both cases I'm quite far from 100% usage. Low throughput with thousands of queues --- Key: QPID-5334 URL: https://issues.apache.org/jira/browse/QPID-5334 Project: Qpid Issue Type: Improvement Components: C++ Broker, Java Client Affects Versions: 0.24 Environment: Broker: Linux 2.6.32 64bit Client: Windows 7, Java 1.7.0_21 64bit Reporter: Flavio Baronti Labels: performance Attachments: JMSGenerator.java, JMSReceiver.java I have an use case where I need to create hundreds of thousands of queues, each one subscribed to a different topic (therefore I have as many topics as queues). I set up a test with a single producer generating data on a randomly chosen topic, and a receiver retrieving data from the queues (and throwing it away). I'm using the JMS api, and doing the obvious thing makes the throughput drop dramatically from 10k msg/sec with a single topic/queue (around the top my network adapter can sustain) to 20 msg/sec with 100k topics/queues. I found out that I can recover performance by using more JMS sessions and connections - e.g. create 4 connections with 100 sessions each, and randomly distributing the receiving queues on them. This however is less than ideal, since with the JMS client a thread is created for each session, I can manage the workload with 1 thread only when it's over a single queue. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-5334) Low throughput with thousands of queues
[ https://issues.apache.org/jira/browse/QPID-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820253#comment-13820253 ] Flavio Baronti edited comment on QPID-5334 at 11/12/13 5:05 PM: CPU usage with few sessions is higher on the broker, and lower on the client. Increasing the number of session appears to increase the load on the client, and lower it on the broker. In both cases I'm quite far from 100% usage (more around 10%). was (Author: flavio): CPU usage with few sessions is higher on the broker, and lower on the client. Increasing the number of session increases the load on the client, and lowers it on the broker. In both cases I'm quite far from 100% usage. Low throughput with thousands of queues --- Key: QPID-5334 URL: https://issues.apache.org/jira/browse/QPID-5334 Project: Qpid Issue Type: Improvement Components: C++ Broker, Java Client Affects Versions: 0.24 Environment: Broker: Linux 2.6.32 64bit Client: Windows 7, Java 1.7.0_21 64bit Reporter: Flavio Baronti Labels: performance Attachments: JMSGenerator.java, JMSReceiver.java I have an use case where I need to create hundreds of thousands of queues, each one subscribed to a different topic (therefore I have as many topics as queues). I set up a test with a single producer generating data on a randomly chosen topic, and a receiver retrieving data from the queues (and throwing it away). I'm using the JMS api, and doing the obvious thing makes the throughput drop dramatically from 10k msg/sec with a single topic/queue (around the top my network adapter can sustain) to 20 msg/sec with 100k topics/queues. I found out that I can recover performance by using more JMS sessions and connections - e.g. create 4 connections with 100 sessions each, and randomly distributing the receiving queues on them. This however is less than ideal, since with the JMS client a thread is created for each session, I can manage the workload with 1 thread only when it's over a single queue. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
