[jira] [Updated] (AMQ-4987) io wait on replicated levelDB slaves
[ https://issues.apache.org/jira/browse/AMQ-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] anselme dewavrin updated AMQ-4987: -- Description: Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster as explained on the activemq site. I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 600 messages/s). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much to disk ? Many thanks in advance Yours, Anselme was: Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster as explained on the activemq site. I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 600 messages/s). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Many thanks in advance Yours, Anselme io wait on replicated levelDB slaves Key: AMQ-4987 URL: https://issues.apache.org/jira/browse/AMQ-4987 Project: ActiveMQ Issue Type: Test Components: activemq-leveldb-store Affects Versions: 5.9.0 Environment: debian VM 2.6.32-5-amd64, jdk7 Reporter: anselme dewavrin Priority: Minor Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster as explained on the activemq site. I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 600 messages/s). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much to disk ? Many thanks in advance Yours, Anselme -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-4987) io wait on replicated levelDB slaves
[ https://issues.apache.org/jira/browse/AMQ-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879805#comment-13879805 ] anselme dewavrin commented on AMQ-4987: --- Dear All, The iowait and huge disk activity is due to frequent fsyncs on the slaves. I demonstrated this by preloading a library that disables fsyncs (with a LD_PRELOAD=libeatmydata.so). With this trick the iowait disappear. I think the leveldb replicated stores is in itself secure enough without fsync-ing each update, because of the synchronous replication (sync=quorum_mem) on different machines that should fail within the same seconds. This is why the many fsyncs on the slaves are not useful, in my opinion. For my purpose I will live with the LD_PRELOAD, but it could be profitable for the community to make the levelDB replicated store evolve. Anselme io wait on replicated levelDB slaves Key: AMQ-4987 URL: https://issues.apache.org/jira/browse/AMQ-4987 Project: ActiveMQ Issue Type: Test Components: activemq-leveldb-store Affects Versions: 5.9.0 Environment: debian VM 2.6.32-5-amd64, jdk7 Reporter: anselme dewavrin Priority: Minor Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster as explained on the activemq site. I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 600 messages/s). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much to disk ? Many thanks in advance Yours, Anselme -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQ-4987) io wait on replicated levelDB slaves
[ https://issues.apache.org/jira/browse/AMQ-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] anselme dewavrin updated AMQ-4987: -- Description: Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster as explained on the activemq site. I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 100 messages/s, each message is 10k). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much to disk ? Many thanks in advance Yours, Anselme was: Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster as explained on the activemq site. I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 600 messages/s). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much to disk ? Many thanks in advance Yours, Anselme io wait on replicated levelDB slaves Key: AMQ-4987 URL: https://issues.apache.org/jira/browse/AMQ-4987 Project: ActiveMQ Issue Type: Test Components: activemq-leveldb-store Affects Versions: 5.9.0 Environment: debian VM 2.6.32-5-amd64, jdk7 Reporter: anselme dewavrin Priority: Minor Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster as explained on the activemq site. I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 100 messages/s, each message is 10k). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much to disk ? Many thanks in advance Yours, Anselme -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQ-4987) io wait on replicated levelDB slaves
[ https://issues.apache.org/jira/browse/AMQ-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] anselme dewavrin updated AMQ-4987: -- Description: Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster on 3 different machines, as explained on the activemq site (with zookeeper etc.). I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 100 messages/s, each message is 10k). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much to disk ? Many thanks in advance Yours, Anselme was: Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster as explained on the activemq site. I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 100 messages/s, each message is 10k). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much to disk ? Many thanks in advance Yours, Anselme io wait on replicated levelDB slaves Key: AMQ-4987 URL: https://issues.apache.org/jira/browse/AMQ-4987 Project: ActiveMQ Issue Type: Test Components: activemq-leveldb-store Affects Versions: 5.9.0 Environment: debian VM 2.6.32-5-amd64, jdk7 Reporter: anselme dewavrin Priority: Minor Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster on 3 different machines, as explained on the activemq site (with zookeeper etc.). I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 100 messages/s, each message is 10k). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much to disk ? Many thanks in advance Yours, Anselme -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-4990) Add support for the changes in MQTT 3.1.1
Hiram Chirino created AMQ-4990: -- Summary: Add support for the changes in MQTT 3.1.1 Key: AMQ-4990 URL: https://issues.apache.org/jira/browse/AMQ-4990 Project: ActiveMQ Issue Type: New Feature Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-4486) ActiveMQResourceAdapter.getXARessources() broken
[ https://issues.apache.org/jira/browse/AMQ-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-4486. - Resolution: Fixed Fix Version/s: (was: 5.9.0) 5.10.0 fix reworked to open/close around each op - http://git-wip-us.apache.org/repos/asf/activemq/commit/3826a23e ActiveMQResourceAdapter.getXARessources() broken Key: AMQ-4486 URL: https://issues.apache.org/jira/browse/AMQ-4486 Project: ActiveMQ Issue Type: Bug Components: JCA Container Affects Versions: 5.8.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 5.10.0 The Implementation of ActiveMQResourceAdapter.getXAResources() is broken. Its internal call to makeConnection() creates a non-XA ActiveMQConnectionFactory which is then discarded as this ConnectionFactory is not XA-aware. As a result an empty XAResources array is returned. This causes transaction recovery in the application server to fail. Where the resource adapter can be manually configured (with beans for example) it is possible to work around by injecting the connection factory as an XA aware variant. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
