[jira] [Resolved] (AMQ-2354) Default the ServerUrl to vm://brokerName?create=false when an embedded broker is specified with brokerXmlConfig
[ https://issues.apache.org/jira/browse/AMQ-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved AMQ-2354. -- Resolution: Fixed Thanks for the patch. Well we made it before 5 years :) Default the ServerUrl to vm://brokerName?create=false when an embedded broker is specified with brokerXmlConfig --- Key: AMQ-2354 URL: https://issues.apache.org/jira/browse/AMQ-2354 Project: ActiveMQ Issue Type: Improvement Components: JCA Container Affects Versions: 5.2.0 Reporter: Michael McKibben Assignee: Claus Ibsen Priority: Minor Fix For: 5.10.0 Attachments: Default_ServerUrl_to_embedded_broker.patch Original Estimate: 0.5h Remaining Estimate: 0.5h By default, a hardcoded ServerUrl resource configuration property must be specified in the ra.xml to connect to a broker. However, when using an embedded broker initialized from the BrokerXmlConfig configuration property, the ServerUrl should be defaulted to vm://brokerName (where brokerName is obtained via Broker.getBrokerName()). This would enable more flexibility in configuring the embedded broker name (e.g. using spring property substitution to name) as opposed to hardcoding as vm://localhost or some other uri in the ra.xml. I've created a patch against trunk to ActiveMQResourceAdapter.java that adds this feature. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: git commit: Update spring.schemas for the 5.9.1 release
It seems odd to me that a point release would require a new schema. What change demands this? Is it backwards compatible with an existing xsd? On 31 Mar 2014 23:56, hadr...@apache.org wrote: Repository: activemq Updated Branches: refs/heads/trunk ed11b067c - 997bbb7a0 Update spring.schemas for the 5.9.1 release Project: http://git-wip-us.apache.org/repos/asf/activemq/repo Commit: http://git-wip-us.apache.org/repos/asf/activemq/commit/997bbb7a Tree: http://git-wip-us.apache.org/repos/asf/activemq/tree/997bbb7a Diff: http://git-wip-us.apache.org/repos/asf/activemq/diff/997bbb7a Branch: refs/heads/trunk Commit: 997bbb7a01ae256e72469786e4cc3d44ff0589cd Parents: ed11b06 Author: Hadrian Zbarcea hadr...@apache.org Authored: Mon Mar 31 18:56:35 2014 -0400 Committer: Hadrian Zbarcea hadr...@apache.org Committed: Mon Mar 31 18:56:35 2014 -0400 -- activemq-spring/src/main/resources/META-INF/spring.schemas | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/activemq/blob/997bbb7a/activemq-spring/src/main/resources/META-INF/spring.schemas -- diff --git a/activemq-spring/src/main/resources/META-INF/spring.schemas b/activemq-spring/src/main/resources/META-INF/spring.schemas index b150716..2b76fec 100644 --- a/activemq-spring/src/main/resources/META-INF/spring.schemas +++ b/activemq-spring/src/main/resources/META-INF/spring.schemas @@ -33,6 +33,7 @@ http\:// activemq.apache.org/schema/core/activemq-core-5.6.0.xsd=activemq.xsd http\:// activemq.apache.org/schema/core/activemq-core-5.7.0.xsd=activemq.xsd http\:// activemq.apache.org/schema/core/activemq-core-5.8.0.xsd=activemq.xsd http\:// activemq.apache.org/schema/core/activemq-core-5.9.0.xsd=activemq.xsd +http\:// activemq.apache.org/schema/core/activemq-core-5.9.1.xsd=activemq.xsd http\:// activemq.apache.org/schema/core/activemq-core-5.10.0.xsd=activemq.xsd http\://camel.apache.org/schema/osgi/camel-osgi.xsd=camel-osgi.xsd
Re: [jira] [Commented] (AMQ-4955) TCP Connections and related thread leak.
I think it should cause the connection to die. The subs currently don't deal with a dispatch failure wrt stats and redelivery so the only safe thing to do is termination. On 1 Apr 2014 06:28, Arthur Naseef (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/AMQ-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956124#comment-13956124] Arthur Naseef commented on AMQ-4955: Reading back through the comments, I see the issue being raised now -- the eaten IOException for all commands except MessageDispatch. I think the right thing to do here is to always re-throw the exception. Can anyone think of a case in which an IOException on Broker.preProcessDispatch() or TransportConnection.dispatch() could have a non-fatal meaning? TCP Connections and related thread leak. Key: AMQ-4955 URL: https://issues.apache.org/jira/browse/AMQ-4955 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2, Jdk 1.7.40 Reporter: Murali Mogalayapalli Assignee: Arthur Naseef Attachments: AMQ4955Test.java, TCP-Connection.jpg, ThreadStack.jpg, activemq.xml TCP Connections and related thread leak. Scenario Active MQ version 5.8 NMS Client version 1.6 OS - Windows 2008 R2 JDK - 1.7.x activemq.xml is attached If a client connectivity gets lost between the time the initial socket is created and the exchange of the wire format, the active MQ server's Client's server thread gets blocked in socket read hanging out the TCP connection and the related thread Here are the steps to recreate 1. Configure the Active MQ server with the activemq.xml attached. 2. Start the client in a debugger and have a break point at a place in such a way that the client can be disconnected after the socket is established. 3. Once the breakpoint is hit, disconnect the client machine from the network 4. Kill the client- This basically simulates a situation where the socket tear down packets are not reached the active mq server. 5. Open the JConsole. Look for the hanging TCP connection and the related thread. Is there an configurable option in Active MQ to sweep and close the connections, on regular interval, that still didn't finish the wire protocol negotiation? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQCPP-536) verify the admin login functionality
ram created AMQCPP-536: -- Summary: verify the admin login functionality Key: AMQCPP-536 URL: https://issues.apache.org/jira/browse/AMQCPP-536 Project: ActiveMQ C++ Client Issue Type: Bug Components: Other C++ Clients Affects Versions: 3.8.1 Reporter: ram Assignee: Timothy Bish Fix For: 3.8.2 verify that adminstrator login functionality successfully -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQCPP-536) verify the admin login functionality using login credentials
[ https://issues.apache.org/jira/browse/AMQCPP-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ram updated AMQCPP-536: --- Summary: verify the admin login functionality using login credentials (was: verify the admin login functionality) verify the admin login functionality using login credentials Key: AMQCPP-536 URL: https://issues.apache.org/jira/browse/AMQCPP-536 Project: ActiveMQ C++ Client Issue Type: Bug Components: Other C++ Clients Affects Versions: 3.8.1 Reporter: ram Assignee: Timothy Bish Labels: easytest, features Fix For: 3.8.2 verify that adminstrator login functionality successfully -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQCPP-536) verify the admin login functionality using login credentials
[ https://issues.apache.org/jira/browse/AMQCPP-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ram updated AMQCPP-536: --- Regression: Regression verify the admin login functionality using login credentials Key: AMQCPP-536 URL: https://issues.apache.org/jira/browse/AMQCPP-536 Project: ActiveMQ C++ Client Issue Type: Bug Components: Other C++ Clients Affects Versions: 3.8.1 Reporter: ram Assignee: Timothy Bish Labels: easytest, features Fix For: 3.8.2 verify that adminstrator login functionality successfully -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Contributing a configuration on the connectivity page
Anyone ? 2014-03-25 15:28 GMT+01:00 William Drai william.d...@graniteds.org: Hi, What is the process to contribute a configuration example on this pagehttp://activemq.apache.org/connectivity.html . GraniteDS is a project similar to BlazeDS referenced herehttp://activemq.apache.org/blazeds.html which provides client messaging libraries for Apache Flex, JavaFX and Android. Thanks. William
[jira] [Commented] (AMQ-5109) Soft deadlock in TransportConnection causes degraded performance in certain situations
[ https://issues.apache.org/jira/browse/AMQ-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956435#comment-13956435 ] Gary Tully commented on AMQ-5109: - this may provide a test case - seems to be the same issue Soft deadlock in TransportConnection causes degraded performance in certain situations Key: AMQ-5109 URL: https://issues.apache.org/jira/browse/AMQ-5109 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Environment: HP-UX 11.31, RHEL 5/6. HP JDK 6/7, Oracle JDK 6/7 Reporter: Nikolay Martynov Priority: Minor Labels: patch Attachments: TransportConnection.java.patch Soft deadlock occurres due to async stopping in case of starting/stopping lots of client connections (using jms template with standard connection factory, for example). ActiveMQ BrokerService gets frozen for 1 second trying to acquire the lock. As a result, already poor performance in case of unpooled connection factory further degrades by around 50%. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5077) Improve performance of ConcurrentStoreAndDispatch
[ https://issues.apache.org/jira/browse/AMQ-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956461#comment-13956461 ] Gary Tully commented on AMQ-5077: - ahh sorry, you are correct, the CompositeDestinationFilter is taking on the fanout send and it ignores the producerWindow altogether. So I think there are two ways to improve this in a derivative CompositeDestinationFilter (a new once can be provided in xml config) that will still have the sends pending and will avoid the need for a routing topic. 1) introduce an executor that can forward in parallel - so we can make better use of concurrent store and dispatch and batching to disk for the composite fanout. 2) respect the producerWindow for the executor queue, such that lots of pending sends can accumulate, allowing producer bursts up to a limit. Improve performance of ConcurrentStoreAndDispatch - Key: AMQ-5077 URL: https://issues.apache.org/jira/browse/AMQ-5077 Project: ActiveMQ Issue Type: Wish Components: Message Store Affects Versions: 5.9.0 Environment: 5.9.0.redhat-610343 Reporter: Jason Shepherd Assignee: Gary Tully Attachments: Test combinations.xlsx, compDesPerf.tar.gz, topicRouting.zip We have publishers publishing to a topic which has 5 topic - queue routings, and gets a max message rate attainable of ~833 messages/sec, with each message around 5k in size. To test this i set up a JMS config with topic queues: Topic TopicRouted.1 ... TopicRouted.11 Each topic has an increasing number of routings to queues, and a client is set up to subscribe to all the queues. Rough message rates: routings messages/sec 0 2500 1 1428 2 2000 3 1428 4 5 833 This occurs whether the broker config has producerFlowControl=false set to true or false , and KahaDB disk synching is turned off. We also tried experimenting with concurrentStoreAndDispatch, but that didn't seem to help. LevelDB didn't give any notable performance improvement either. We also have asyncSend enabled on the producer, and have a requirement to use persistent messages. We have also experimented with sending messages in a transaction, but that hasn't really helped. It seems like producer throughput rate across all queue destinations, all connections and all publisher machines is limited by something on the broker, through a mechanism which is not producer flow control. I think the prime suspect is still contention on the index. We did some test with Yourkit profiler. Profiler was attached to broker at startup, allowed to run and then a topic publisher was started, routing to 5 queues. Profiler statistics were reset, the publisher allowed to run for 60 seconds, and then profiling snapshot was taken. During that time, ~9600 messages were logged as being sent for a rate of ~160/sec. This ties in roughly with the invocation counts recorded in the snapshot (i think) - ~43k calls. From what i can work out, in the snapshot (filtering everything but org.apache.activemq.store.kahadb), For the 60 second sample period, 24.8 seconds elapsed in org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.removeAsyncMessage(ConnectionContext, MessageAck). 18.3 seconds elapsed in org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.asyncAddQueueMessage(ConnectionContext, Message, boolean). From these, a further large portion of the time is spent inside MessageDatabase: org.apache.activemq.store.kahadb.MessageDatabase.process(KahaRemoveMessageCommand, Location) - 10 secs elapsed org.apache.activemq.store.kahadb.MessageDatabase.process(KahaAddMessageCommand, Location) - 8.5 secs elapsed. As both of these lock on indexLock.writeLock(), and both take place on the NIO transport threads, i think this accounts for at least some of the message throughput limits. As messages are added and removed from the index one by one, regardless of sync type settings, this adds a fair amount of overhead. While we're not synchronising on writes to disk, we are performing work on the NIO worker thread which can block on locks, and could account for the behaviour we've seen client side. To Reproduce: 1. Install a broker and use the attached configuration. 2. Use the 5.8.0 example ant script to consume from the queues, TopicQueueRouted.1 - 5. eg: ant consumer -Durl=tcp://localhost:61616 -Dsubject=TopicQueueRouted.1 -Duser=admin -Dpassword=admin -Dmax=-1 3. Use the modified version of 5.8.0 example ant script (attached) to send messages to topics, TopicRouted.1 - 5, eg: ant producer -Durl='tcp://localhost:61616?jms.useAsyncSend=truewireFormat.tightEncodingEnabled=falsekeepAlive=truewireFormat.maxInactivityDuration=6socketBufferSize=32768'
[VOTE] Apache ActiveMQ 5.9.1 release
Hi all, I've cut a release candidate for the 5.9.1 patch release. I have to update JIRA today to determine the exact number of issues resolved and follow up with another email. This patch release is focused on fixes related to leveldb, a security update for the camel dependency and moving back to using the original activemq console Please review the artifacts for this release candidate and cast your vote The list of resolved issues is: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210amp;version=12326455 You can get binary distributions here: https://repository.apache.org/content/repositories/orgapacheactivemq-1002/org/apache/activemq/apache- activemq/5.9.1/ Source archives are here: https://repository.apache.org/content/repositories/orgapacheactivemq-1002/org/apache/activemq/activemq- parent/5.9.1 Maven2 repository is at: https://repository.apache.org/content/repositories/orgapacheactivemq-1002/ Source tag: https://git-wip- us.apache.org/repos/asf?p=activemq.git;a=tag;h=refs/tags/activemq-5.9.1 Please vote to approve this release [ ] +1 Release the binary as Apache ActiveMQ 5.9.1 [ ] -1 Veto the release (provide specific comments) Here's my +1
[jira] [Commented] (AMQ-5077) Improve performance of ConcurrentStoreAndDispatch
[ https://issues.apache.org/jira/browse/AMQ-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956570#comment-13956570 ] Richard Wagg commented on AMQ-5077: --- Hi, I'm happy that those 2 changes would help the producer in not getting blocked by the JMS. It is also likely to improve throughput to the consumers, but i think we could make further improvements there. A new executor using Concurrent store and dispatch is likely to result in more messages in flight to the consumers - but i'm still concerned that the performance of this (this being the ultimate queue writes/sec the broker can achieve) will be hard to determine, as it will be a function of how quick the underlying disk store is as well as the average roundtrip time for the consumer to receive, process and ACK each message. If we have a large queue of messages being written to the diskstore, and relatively quick consumers, then we can optimise away the disk writes - but i'm not sure that this is visible at the moment. I would still be interested in i guess some form of delay queue for the diskstore writes - a configurable property for a minimum delay to wait before writing messages through to the index/diskstore, which you could benchmark against your expected consumer ACK roundtrip time to determine if you expect to be able to optimise away the disk writes completely under most situations. If this delay is small enough, and the producer window doesn't get decremented till either the diskstore write completes or the consumer ACK arrives, we could still have some resilience against message loss with this in place. Do you think that would be a useful option, or cause more problems than it could solve? Thanks, Richard Improve performance of ConcurrentStoreAndDispatch - Key: AMQ-5077 URL: https://issues.apache.org/jira/browse/AMQ-5077 Project: ActiveMQ Issue Type: Wish Components: Message Store Affects Versions: 5.9.0 Environment: 5.9.0.redhat-610343 Reporter: Jason Shepherd Assignee: Gary Tully Attachments: Test combinations.xlsx, compDesPerf.tar.gz, topicRouting.zip We have publishers publishing to a topic which has 5 topic - queue routings, and gets a max message rate attainable of ~833 messages/sec, with each message around 5k in size. To test this i set up a JMS config with topic queues: Topic TopicRouted.1 ... TopicRouted.11 Each topic has an increasing number of routings to queues, and a client is set up to subscribe to all the queues. Rough message rates: routings messages/sec 0 2500 1 1428 2 2000 3 1428 4 5 833 This occurs whether the broker config has producerFlowControl=false set to true or false , and KahaDB disk synching is turned off. We also tried experimenting with concurrentStoreAndDispatch, but that didn't seem to help. LevelDB didn't give any notable performance improvement either. We also have asyncSend enabled on the producer, and have a requirement to use persistent messages. We have also experimented with sending messages in a transaction, but that hasn't really helped. It seems like producer throughput rate across all queue destinations, all connections and all publisher machines is limited by something on the broker, through a mechanism which is not producer flow control. I think the prime suspect is still contention on the index. We did some test with Yourkit profiler. Profiler was attached to broker at startup, allowed to run and then a topic publisher was started, routing to 5 queues. Profiler statistics were reset, the publisher allowed to run for 60 seconds, and then profiling snapshot was taken. During that time, ~9600 messages were logged as being sent for a rate of ~160/sec. This ties in roughly with the invocation counts recorded in the snapshot (i think) - ~43k calls. From what i can work out, in the snapshot (filtering everything but org.apache.activemq.store.kahadb), For the 60 second sample period, 24.8 seconds elapsed in org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.removeAsyncMessage(ConnectionContext, MessageAck). 18.3 seconds elapsed in org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.asyncAddQueueMessage(ConnectionContext, Message, boolean). From these, a further large portion of the time is spent inside MessageDatabase: org.apache.activemq.store.kahadb.MessageDatabase.process(KahaRemoveMessageCommand, Location) - 10 secs elapsed org.apache.activemq.store.kahadb.MessageDatabase.process(KahaAddMessageCommand, Location) - 8.5 secs elapsed. As both of these lock on indexLock.writeLock(), and both take place on the NIO transport threads, i think this accounts for at least some of the message throughput limits. As messages are
[jira] [Updated] (AMQ-3725) Kahadb error during SAN failover delayed write - Allow kahaDB to recover in a similar manner as the JDBC store using the IOExceptionHandler
[
https://issues.apache.org/jira/browse/AMQ-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated AMQ-3725:
-
Assignee: Dejan Bosanac
Kahadb error during SAN failover delayed write - Allow kahaDB to recover in a
similar manner as the JDBC store using the IOExceptionHandler
---
Key: AMQ-3725
URL: https://issues.apache.org/jira/browse/AMQ-3725
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.5.1
Reporter: Jason Sherman
Assignee: Dejan Bosanac
Fix For: 5.9.1, 5.10.0
Attachments: AMQ-3725-10112013.txt
An issue can arise that causes the broker to terminate when using kahaDB with
a SAN, when the SAN fails over. In this case the failover process is
seamless however, on fail back there is a 2-3 sec delay where writes are
blocked and the broker terminates. With the JDBC datastore a similar
situation can be handled by using the IOExceptionHandler. However with
kahaDB, when this same IOExceptionHandler is added it prevents the broker
from terminating but kahaDB retains an invalid index.
{code}
INFO | ActiveMQ JMS Message Broker (Broker1,
ID:macbookpro-251a.home-56915-1328715089252-0:1) started
INFO | jetty-7.1.6.v20100715
INFO | ActiveMQ WebConsole initialized.
INFO | Initializing Spring FrameworkServlet 'dispatcher'
INFO | ActiveMQ Console at http://0.0.0.0:8161/admin
INFO | ActiveMQ Web Demos at http://0.0.0.0:8161/demo
INFO | RESTful file access application at http://0.0.0.0:8161/fileserver
INFO | FUSE Web Console at http://0.0.0.0:8161/console
INFO | Started SelectChannelConnector@0.0.0.0:8161
ERROR | KahaDB failed to store to Journal
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO exception, java.io.SyncFailedException: sync failed
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
ERROR | Checkpoint failed
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO exception, java.io.SyncFailedException: sync failed
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
ERROR | KahaDB failed to store to Journal
java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
at
org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO exception, java.io.FileNotFoundException:
/Volumes/NAS-01/data/kahadb/db-1.log (No such file or directory)
java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
at
org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
ERROR | KahaDB failed to store to Journal
java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
at
org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO exception,
[jira] [Commented] (AMQ-3725) Kahadb error during SAN failover delayed write - Allow kahaDB to recover in a similar manner as the JDBC store using the IOExceptionHandler
[
https://issues.apache.org/jira/browse/AMQ-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956662#comment-13956662
]
Claus Ibsen commented on AMQ-3725:
--
Did anyone test the SNAPSHOT with a fix
Kahadb error during SAN failover delayed write - Allow kahaDB to recover in a
similar manner as the JDBC store using the IOExceptionHandler
---
Key: AMQ-3725
URL: https://issues.apache.org/jira/browse/AMQ-3725
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.5.1
Reporter: Jason Sherman
Fix For: 5.9.1, 5.10.0
Attachments: AMQ-3725-10112013.txt
An issue can arise that causes the broker to terminate when using kahaDB with
a SAN, when the SAN fails over. In this case the failover process is
seamless however, on fail back there is a 2-3 sec delay where writes are
blocked and the broker terminates. With the JDBC datastore a similar
situation can be handled by using the IOExceptionHandler. However with
kahaDB, when this same IOExceptionHandler is added it prevents the broker
from terminating but kahaDB retains an invalid index.
{code}
INFO | ActiveMQ JMS Message Broker (Broker1,
ID:macbookpro-251a.home-56915-1328715089252-0:1) started
INFO | jetty-7.1.6.v20100715
INFO | ActiveMQ WebConsole initialized.
INFO | Initializing Spring FrameworkServlet 'dispatcher'
INFO | ActiveMQ Console at http://0.0.0.0:8161/admin
INFO | ActiveMQ Web Demos at http://0.0.0.0:8161/demo
INFO | RESTful file access application at http://0.0.0.0:8161/fileserver
INFO | FUSE Web Console at http://0.0.0.0:8161/console
INFO | Started SelectChannelConnector@0.0.0.0:8161
ERROR | KahaDB failed to store to Journal
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO exception, java.io.SyncFailedException: sync failed
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
ERROR | Checkpoint failed
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO exception, java.io.SyncFailedException: sync failed
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
ERROR | KahaDB failed to store to Journal
java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
at
org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO exception, java.io.FileNotFoundException:
/Volumes/NAS-01/data/kahadb/db-1.log (No such file or directory)
java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
at
org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
ERROR | KahaDB failed to store to Journal
java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
at
org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO
[jira] [Commented] (AMQ-3725) Kahadb error during SAN failover delayed write - Allow kahaDB to recover in a similar manner as the JDBC store using the IOExceptionHandler
[
https://issues.apache.org/jira/browse/AMQ-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956663#comment-13956663
]
Claus Ibsen commented on AMQ-3725:
--
[~dejanb] should we assume this is fixed and close the ticket?
Kahadb error during SAN failover delayed write - Allow kahaDB to recover in a
similar manner as the JDBC store using the IOExceptionHandler
---
Key: AMQ-3725
URL: https://issues.apache.org/jira/browse/AMQ-3725
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.5.1
Reporter: Jason Sherman
Assignee: Dejan Bosanac
Fix For: 5.9.1, 5.10.0
Attachments: AMQ-3725-10112013.txt
An issue can arise that causes the broker to terminate when using kahaDB with
a SAN, when the SAN fails over. In this case the failover process is
seamless however, on fail back there is a 2-3 sec delay where writes are
blocked and the broker terminates. With the JDBC datastore a similar
situation can be handled by using the IOExceptionHandler. However with
kahaDB, when this same IOExceptionHandler is added it prevents the broker
from terminating but kahaDB retains an invalid index.
{code}
INFO | ActiveMQ JMS Message Broker (Broker1,
ID:macbookpro-251a.home-56915-1328715089252-0:1) started
INFO | jetty-7.1.6.v20100715
INFO | ActiveMQ WebConsole initialized.
INFO | Initializing Spring FrameworkServlet 'dispatcher'
INFO | ActiveMQ Console at http://0.0.0.0:8161/admin
INFO | ActiveMQ Web Demos at http://0.0.0.0:8161/demo
INFO | RESTful file access application at http://0.0.0.0:8161/fileserver
INFO | FUSE Web Console at http://0.0.0.0:8161/console
INFO | Started SelectChannelConnector@0.0.0.0:8161
ERROR | KahaDB failed to store to Journal
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO exception, java.io.SyncFailedException: sync failed
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
ERROR | Checkpoint failed
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO exception, java.io.SyncFailedException: sync failed
java.io.SyncFailedException: sync failed
at java.io.FileDescriptor.sync(Native Method)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:382)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
ERROR | KahaDB failed to store to Journal
java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
at
org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
INFO | Ignoring IO exception, java.io.FileNotFoundException:
/Volumes/NAS-01/data/kahadb/db-1.log (No such file or directory)
java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
at
org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
at
org.apache.kahadb.journal.DataFileAppender$2.run(DataFileAppender.java:203)
ERROR | KahaDB failed to store to Journal
java.io.FileNotFoundException: /Volumes/NAS-01/data/kahadb/db-1.log (No such
file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
at
org.apache.kahadb.journal.DataFile.openRandomAccessFile(DataFile.java:70)
at
org.apache.kahadb.journal.DataFileAppender.processQueue(DataFileAppender.java:324)
at
[jira] [Updated] (AMQ-4767) Extend ActiveMQ Camel component to support INDIVIDUAL_MESSAGE ack mode
[ https://issues.apache.org/jira/browse/AMQ-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated AMQ-4767: - Fix Version/s: (was: 5.10.0) 5.11.0 Extend ActiveMQ Camel component to support INDIVIDUAL_MESSAGE ack mode -- Key: AMQ-4767 URL: https://issues.apache.org/jira/browse/AMQ-4767 Project: ActiveMQ Issue Type: New Feature Components: activemq-camel Affects Versions: 5.8.0 Environment: All Reporter: Matt Pavlovich Assignee: Claus Ibsen Fix For: 5.11.0 It would be really helpful to have a per-message acknowledgement that did not acknowledge all previous messages.. this would be an ActiveMQ-only acknowledgement mode. Really handy for Camel to do things like from: activemq:queue:My.Queue?concurrentConsumers=5amp; acknowledgementModeName=INDIVIDUAL_MESSAGE to: jetty:http://somewebendpoint/ and have quasi-transacted behavior -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Apache ActiveMQ 5.9.1 release
Tested binary and console basic functionality. +1 - Non binding. On Apr 1, 2014, at 10:14 AM, Hadrian Zbarcea hzbar...@gmail.com wrote: Hi all, I've cut a release candidate for the 5.9.1 patch release. I have to update JIRA today to determine the exact number of issues resolved and follow up with another email. This patch release is focused on fixes related to leveldb, a security update for the camel dependency and moving back to using the original activemq console Please review the artifacts for this release candidate and cast your vote The list of resolved issues is: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210amp;version=12326455 You can get binary distributions here: https://repository.apache.org/content/repositories/orgapacheactivemq-1002/org/apache/activemq/apache- activemq/5.9.1/ Source archives are here: https://repository.apache.org/content/repositories/orgapacheactivemq-1002/org/apache/activemq/activemq- parent/5.9.1 Maven2 repository is at: https://repository.apache.org/content/repositories/orgapacheactivemq-1002/ Source tag: https://git-wip- us.apache.org/repos/asf?p=activemq.git;a=tag;h=refs/tags/activemq-5.9.1 Please vote to approve this release [ ] +1 Release the binary as Apache ActiveMQ 5.9.1 [ ] -1 Veto the release (provide specific comments) Here's my +1
Re: [VOTE] Apache ActiveMQ 5.9.1 release
I really appreciate this minor release. Last minor releases were caused by legal issues two years ago. +1 (non binding) Checked console and admin script. Cheers, Łukasz Dywicki -- l...@code-house.org Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org Wiadomość napisana przez Johan Edstrom seij...@gmail.com w dniu 1 kwi 2014, o godz. 18:10: Tested binary and console basic functionality. +1 - Non binding. On Apr 1, 2014, at 10:14 AM, Hadrian Zbarcea hzbar...@gmail.com wrote: Hi all, I've cut a release candidate for the 5.9.1 patch release. I have to update JIRA today to determine the exact number of issues resolved and follow up with another email. This patch release is focused on fixes related to leveldb, a security update for the camel dependency and moving back to using the original activemq console Please review the artifacts for this release candidate and cast your vote The list of resolved issues is: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210amp;version=12326455 You can get binary distributions here: https://repository.apache.org/content/repositories/orgapacheactivemq-1002/org/apache/activemq/apache- activemq/5.9.1/ Source archives are here: https://repository.apache.org/content/repositories/orgapacheactivemq-1002/org/apache/activemq/activemq- parent/5.9.1 Maven2 repository is at: https://repository.apache.org/content/repositories/orgapacheactivemq-1002/ Source tag: https://git-wip- us.apache.org/repos/asf?p=activemq.git;a=tag;h=refs/tags/activemq-5.9.1 Please vote to approve this release [ ] +1 Release the binary as Apache ActiveMQ 5.9.1 [ ] -1 Veto the release (provide specific comments) Here's my +1
[jira] [Commented] (AMQ-4920) AmqpErrorException occurs with multiple concurrent amqp topic consumers
[
https://issues.apache.org/jira/browse/AMQ-4920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956818#comment-13956818
]
Gurinder commented on AMQ-4920:
---
So essentially multiple topic consumers even running from different instances
do not work. This pretty much makes publish-subscribe system unworkable since
in any production environment you would have more than 1 subscriber to the same
topic. Or is there any other way.?
Btw any idea when 5.10 is coming out
AmqpErrorException occurs with multiple concurrent amqp topic consumers
---
Key: AMQ-4920
URL: https://issues.apache.org/jira/browse/AMQ-4920
Project: ActiveMQ
Issue Type: Bug
Reporter: Kevin Earls
Assignee: Kevin Earls
Attachments: rp.out
I'll add a test to reproduce this. There are currently 2 problems. The more
frequent one looks like: org.apache.qpid.amqp_1_0.type.AmqpErrorException
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.readConstructor(ValueHandler.java:99)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.parse(ValueHandler.java:90)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.readConstructor(ValueHandler.java:105)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.parse(ValueHandler.java:90)
… repeated many times
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.readConstructor(ValueHandler.java:105)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.parse(ValueHandler.java:90)
at
org.apache.qpid.amqp_1_0.messaging.SectionDecoderImpl.parseAll(SectionDecoderImpl.java:49)
at org.apache.qpid.amqp_1_0.client.Receiver.receive(Receiver.java:280)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive0(MessageConsumerImpl.java:286)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receiveImpl(MessageConsumerImpl.java:255)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive(MessageConsumerImpl.java:238)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive(MessageConsumerImpl.java:56)
at
org.apache.activemq.transport.amqp.ENTMQ466ConsumerThread.run(ENTMQ466Test.java:123)
This occurs at the line final EncodedMessage amqp =
outboundTransformer.transform(jms); in the ConsumerContext.pumpOutbound()
method of AmqpProtocolConverter(). This call sometimes returns with its
content (amqp.getArray()) set to all zeros.
On those messages this line
LOG.info(In pumpOutbound, setting currentBuffer to offset {} length {}
content [{}], amqp.getArrayOffset(), amqp.getLength(), amqp.getArray());
returns:
2013-11-26 17:19:16,680 [calhost] Task-3] - INFO AmqpProtocolConverter - In
pumpOutbound, setting currentBuffer to offset 0 length 162 content [[0, 0, 0,
0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0\
, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]]
At the root of this, outboundTransformer is a (proton)
AutoOutboundTransformer. It calls AMQPNativeOutboundTransformer.transform(),
which calls msg.readBytes(data), which sometimes writes all 0s to data. Here
msg is an ActiveMQBytesMessage.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (AMQ-4920) AmqpErrorException occurs with multiple concurrent amqp topic consumers
[
https://issues.apache.org/jira/browse/AMQ-4920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956818#comment-13956818
]
Gurinder edited comment on AMQ-4920 at 4/1/14 6:02 PM:
---
So essentially multiple topic consumers even running from different instances
do not work. This pretty much makes publish-subscribe system unworkable since
in any production environment you would have more than 1 subscriber to the same
topic. Or is there any other way.?
Btw any idea when 5.10 is coming out.
Also is it the broker or client problem?
was (Author: gurilubana):
So essentially multiple topic consumers even running from different instances
do not work. This pretty much makes publish-subscribe system unworkable since
in any production environment you would have more than 1 subscriber to the same
topic. Or is there any other way.?
Btw any idea when 5.10 is coming out
AmqpErrorException occurs with multiple concurrent amqp topic consumers
---
Key: AMQ-4920
URL: https://issues.apache.org/jira/browse/AMQ-4920
Project: ActiveMQ
Issue Type: Bug
Reporter: Kevin Earls
Assignee: Kevin Earls
Attachments: rp.out
I'll add a test to reproduce this. There are currently 2 problems. The more
frequent one looks like: org.apache.qpid.amqp_1_0.type.AmqpErrorException
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.readConstructor(ValueHandler.java:99)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.parse(ValueHandler.java:90)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.readConstructor(ValueHandler.java:105)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.parse(ValueHandler.java:90)
… repeated many times
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.readConstructor(ValueHandler.java:105)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.parse(ValueHandler.java:90)
at
org.apache.qpid.amqp_1_0.messaging.SectionDecoderImpl.parseAll(SectionDecoderImpl.java:49)
at org.apache.qpid.amqp_1_0.client.Receiver.receive(Receiver.java:280)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive0(MessageConsumerImpl.java:286)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receiveImpl(MessageConsumerImpl.java:255)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive(MessageConsumerImpl.java:238)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive(MessageConsumerImpl.java:56)
at
org.apache.activemq.transport.amqp.ENTMQ466ConsumerThread.run(ENTMQ466Test.java:123)
This occurs at the line final EncodedMessage amqp =
outboundTransformer.transform(jms); in the ConsumerContext.pumpOutbound()
method of AmqpProtocolConverter(). This call sometimes returns with its
content (amqp.getArray()) set to all zeros.
On those messages this line
LOG.info(In pumpOutbound, setting currentBuffer to offset {} length {}
content [{}], amqp.getArrayOffset(), amqp.getLength(), amqp.getArray());
returns:
2013-11-26 17:19:16,680 [calhost] Task-3] - INFO AmqpProtocolConverter - In
pumpOutbound, setting currentBuffer to offset 0 length 162 content [[0, 0, 0,
0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0\
, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]]
At the root of this, outboundTransformer is a (proton)
AutoOutboundTransformer. It calls AMQPNativeOutboundTransformer.transform(),
which calls msg.readBytes(data), which sometimes writes all 0s to data. Here
msg is an ActiveMQBytesMessage.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQNET-454) Add Apache Qpid provider to NMS
[ https://issues.apache.org/jira/browse/AMQNET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated AMQNET-454: --- Attachment: Apache.NMS.AMQP-23e-addFilesToTestProject.patch Apache.NMS.AMQP-23d-addTraceStatements.patch Apache.NMS.AMQP-23c-NmsConsoleTracer.cs.patch Apache.NMS.AMQP-23b-MSConnectionFactoryTest.cs.patch Apache.NMS.AMQP-23a-MessageDeliveryTest.cs.patch Please disregard the -22 patch. It is replaced by this set. Also, this set does not gratuitously move source files into new directories so the patch set is much smaller. -23a, -23b, and -23c each add a single new file -23d adds a few trace statements -23e adds the new files to the test project. I have the most trouble with TortoiseSVN when adding new files. Hopefully by breaking the whole set into smaller pieces it's easier to merge. Add Apache Qpid provider to NMS --- Key: AMQNET-454 URL: https://issues.apache.org/jira/browse/AMQNET-454 Project: ActiveMQ .Net Issue Type: New Feature Components: NMS Affects Versions: 1.6.0 Reporter: Chuck Rolke Assignee: Jim Gomes Attachments: Apache.NMS.AMQP-21-Add-Map-Text-Message-tests.patch, Apache.NMS.AMQP-22-add-more-tests.patch, Apache.NMS.AMQP-23a-MessageDeliveryTest.cs.patch, Apache.NMS.AMQP-23b-MSConnectionFactoryTest.cs.patch, Apache.NMS.AMQP-23c-NmsConsoleTracer.cs.patch, Apache.NMS.AMQP-23d-addTraceStatements.patch, Apache.NMS.AMQP-23e-addFilesToTestProject.patch, Apache.NMS.AMQP-Add-message-cloning-19.patch, Apache.NMS.AMQP-add-connection-property-table-17.patch, Apache.NMS.AMQP-add-hello-world-example-11.patch, Apache.NMS.AMQP-add-hello-world-example-retry-12.patch, Apache.NMS.AMQP-add-hello-world-to-vs2008-18.patch, Apache.NMS.AMQP-add-message-conversions-06.patch, Apache.NMS.AMQP-add-message-test-20.patch, Apache.NMS.AMQP-add-topic-05.patch, Apache.NMS.AMQP-connectionProperties-07.patch, Apache.NMS.AMQP-copyrights-conn-str-fix-09.patch, Apache.NMS.AMQP-fix-destination-to-use-qpid-address-10.patch, Apache.NMS.AMQP-fix-helloworld-13.patch, Apache.NMS.AMQP-fix-list-message-body-15.patch, Apache.NMS.AMQP-fix-map-message-body-14.patch, Apache.NMS.AMQP-fix-replyTo-and-receive-timeouts-16.patch, Apache.NMS.AMQP-object-lifecycle-04.patch, Apache.NMS.AMQP-provider-configs-03.patch, Apache.NMS.AMQP-qpid-object-lifecycle-02.patch, Apache.NMS.AMQP-set-connection-credentials-08.patch, RELEASE.txt, vendor-QPid-nant-01.patch NMS includes various providers ActiveMQ, STOMP, MSMQ, EMS, and WCF. This issue proposes to add [Apache Qpid|http://qpid.apache.org/index.html] as another provider. Qpid has a [Messaging .NET Binding|http://qpid.apache.org/releases/qpid-0.24/programming/book/ch05.html] that is layered on top of the native C++ Qpid Messaging client. The Qpid .NET binding is attractive as the hook for tying in Qpid as an NMS provider. The proposed NMS provider supports [AMQP 1.0|http://qpid.apache.org/amqp.html] by including [Qpid Proton|http://qpid.apache.org/proton/index.html] libraries. From a high level this addition to Active.NMS would consist of two parts * Add Qpid as a vendor kit. This includes both the Qpid .NET Binding and Qpid Proton in a single kit. * Add the new provider with code linking NMS to Qpid -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQNET-454) Add Apache Qpid provider to NMS
[ https://issues.apache.org/jira/browse/AMQNET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956929#comment-13956929 ] Timothy Bish commented on AMQNET-454: - All new patch applied without issue. Add Apache Qpid provider to NMS --- Key: AMQNET-454 URL: https://issues.apache.org/jira/browse/AMQNET-454 Project: ActiveMQ .Net Issue Type: New Feature Components: NMS Affects Versions: 1.6.0 Reporter: Chuck Rolke Assignee: Jim Gomes Attachments: Apache.NMS.AMQP-21-Add-Map-Text-Message-tests.patch, Apache.NMS.AMQP-22-add-more-tests.patch, Apache.NMS.AMQP-23a-MessageDeliveryTest.cs.patch, Apache.NMS.AMQP-23b-MSConnectionFactoryTest.cs.patch, Apache.NMS.AMQP-23c-NmsConsoleTracer.cs.patch, Apache.NMS.AMQP-23d-addTraceStatements.patch, Apache.NMS.AMQP-23e-addFilesToTestProject.patch, Apache.NMS.AMQP-Add-message-cloning-19.patch, Apache.NMS.AMQP-add-connection-property-table-17.patch, Apache.NMS.AMQP-add-hello-world-example-11.patch, Apache.NMS.AMQP-add-hello-world-example-retry-12.patch, Apache.NMS.AMQP-add-hello-world-to-vs2008-18.patch, Apache.NMS.AMQP-add-message-conversions-06.patch, Apache.NMS.AMQP-add-message-test-20.patch, Apache.NMS.AMQP-add-topic-05.patch, Apache.NMS.AMQP-connectionProperties-07.patch, Apache.NMS.AMQP-copyrights-conn-str-fix-09.patch, Apache.NMS.AMQP-fix-destination-to-use-qpid-address-10.patch, Apache.NMS.AMQP-fix-helloworld-13.patch, Apache.NMS.AMQP-fix-list-message-body-15.patch, Apache.NMS.AMQP-fix-map-message-body-14.patch, Apache.NMS.AMQP-fix-replyTo-and-receive-timeouts-16.patch, Apache.NMS.AMQP-object-lifecycle-04.patch, Apache.NMS.AMQP-provider-configs-03.patch, Apache.NMS.AMQP-qpid-object-lifecycle-02.patch, Apache.NMS.AMQP-set-connection-credentials-08.patch, RELEASE.txt, vendor-QPid-nant-01.patch NMS includes various providers ActiveMQ, STOMP, MSMQ, EMS, and WCF. This issue proposes to add [Apache Qpid|http://qpid.apache.org/index.html] as another provider. Qpid has a [Messaging .NET Binding|http://qpid.apache.org/releases/qpid-0.24/programming/book/ch05.html] that is layered on top of the native C++ Qpid Messaging client. The Qpid .NET binding is attractive as the hook for tying in Qpid as an NMS provider. The proposed NMS provider supports [AMQP 1.0|http://qpid.apache.org/amqp.html] by including [Qpid Proton|http://qpid.apache.org/proton/index.html] libraries. From a high level this addition to Active.NMS would consist of two parts * Add Qpid as a vendor kit. This includes both the Qpid .NET Binding and Qpid Proton in a single kit. * Add the new provider with code linking NMS to Qpid -- This message was sent by Atlassian JIRA (v6.2#6252)
Kahadb - Getting Worried Message
Hi everybody,
Recently We implemented in production a ActiveMQServer. (It has 5 days
working),everything was perfect but today I saw in the hawtio-JMX Web
Console the following message(property health/current status):
Getting Worried {org.apache.activemq.FreeDiskSpaceLeft: WARNING Store limit
is 19329 mb, whilst the data directory:
/.../apache-activemq-5.9.0/data/kahadb only has 19283 mb of usable space
from KahaDBPersistenceAdapter[/.../apache-activemq-5.9.0/data/kahadb] , }
It means I have to delete the log files? or increase some property in
persistent?
thank you.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Kahadb-Getting-Worried-Message-tp4679825.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
ActiveMq Encypted Passwords
Hello,
I'm having a problem getting the property replacement to work when setting
up the encrypted passwords to access my data source.
I've been following the instructions here;
http://activemq.apache.org/encrypted-passwords.html
Maybe my understanding of this is not correct, but I was expecting to see
the ${jdbc.password} property replaced in my activemq config after activemq
is started. This is not happening.
Should i expect this? Or should the config file always show
${jdbc.password}?
My activemq config is below. As well as my credentials-enc.properties file.
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:amq=http://activemq.apache.org/schema/core;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd;
bean id=environmentVariablesConfiguration
class=org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig
property name=algorithm value=PBEWithMD5AndDES /
property name=password value=password /
/bean
bean id=configurationEncryptor
class=org.jasypt.encryption.pbe.StandardPBEStringEncryptor
property name=config ref=environmentVariablesConfiguration /
/bean
bean id=propertyConfigurer
class=org.jasypt.spring.properties.EncryptablePropertyPlaceholderConfigurer
constructor-arg ref=configurationEncryptor /
property name=location
value=file:${activemq.base}/conf/credentials-enc.properties /
/bean
bean id=oscarDataSource class=org.apache.commons.dbcp.BasicDataSource
destroy-method=close
property name=driverClassName value=com.mysql.jdbc.Driver /
property name=url value=url /
property name=username value=user /
property name=password value=${jdbc.password}/
property name=maxActive value=200 /
property name=poolPreparedStatements value=true /
/bean
amq:broker useJmx=true persistent=true schedulerSupport=false
advisorySupport=true dataDirectory=/var/data brokerName=activemq
amq:destinationPolicy
amq:policyMap
amq:policyEntries
amq:policyEntry queue=
amq:deadLetterStrategy
amq:individualDeadLetterStrategy
queueSuffix=DeadLetterQueue useQueueForQueueMessages=true /
/amq:deadLetterStrategy
/amq:policyEntry
amq:policyEntry queue=myQueue producerFlowControl=true
enableAudit=false /
/amq:policyEntries
/amq:policyMap
/amq:destinationPolicy
amq:persistenceAdapter
amq:jdbcPersistenceAdapter dataDirectory=activemq-data
dataSource=#oscarDataSource /
/amq:persistenceAdapter
/amq:broker
/beans
credentials-enc.properties
jdbc.password=ENC(jkosfdjkpA==)
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMq-Encypted-Passwords-tp4679811.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: ActiveMQ 5.10 release date?
Ryan, I built the 5.9.1 candidate yesterday, it's currently under vote. Community involvement is always highly appreciated. Please feel free to test the release candidate in your environment (see the vote thread for location of the staged distro). Thanks, Hadrian On Tuesday 01 April 2014 01:16:40 ryan segura wrote: Hadrian, Please release 5.9.1 asap. I think activemq should get on a release cycle and whatever is done makes the cut. Whatever is not done doesnt. We prioritize bug fixes, determine what must make the next release and then the rest is just a bonus. I think reliability at this stage is more important than new features. The new features will always make their way in there, but the bug fixes are what make this product a deal breaker. what version are you running in production? do you take 5.9 and add the fixes that you need personally, do you run a stable build? I just dont see the team really running the releases because of the issues. I may need to become more active in this community to keep our environment reliable. -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-5-10-release-date-tp4678366 p4679781.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Contributing a configuration on the connectivity page
There is no process per se. If you create an account on the activemq wiki and submit an icla to the ASF you would become officially a contributor and could edit it yourself. The alternative would be to provide the content (on the list or in a patch) and then one of the community member will update the wiki. It looks like our contributing page [1] doesn't provide enough details. I updated the wiki [2] and it will pushed to the public site [1] soon. I hope this helps, Hadrian [1] http://activemq.apache.org/contributing.html [2] https://cwiki.apache.org/confluence/display/ACTIVEMQ/Contributing On Tuesday 01 April 2014 05:58:20 William Drai wrote: Anyone ? 2014-03-25 15:28 GMT+01:00 William Drai william.d...@graniteds.org: Hi, What is the process to contribute a configuration example on this pagehttp://activemq.apache.org/connectivity.html . GraniteDS is a project similar to BlazeDS referenced herehttp://activemq.apache.org/blazeds.html which provides client messaging libraries for Apache Flex, JavaFX and Android. Thanks. William
Re: [VOTE] Apache ActiveMQ 5.9.1 release
Just to confirm -- the only bug fixes are those in the release notes? It does not appear to be many -- View this message in context: http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-5-9-1-release-tp4679806p4679833.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [VOTE] Apache ActiveMQ 5.9.1 release
No, there's much more, I have to finish updating that. As I said in the vote mail, I'll follow up with another email once that's done. Hadrian On Tuesday 01 April 2014 20:18:54 ryan segura wrote: Just to confirm -- the only bug fixes are those in the release notes? It does not appear to be many -- View this message in context: http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-5-9-1-release-t p4679806p4679833.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Kahadb - Getting Worried Message
Congrats on getting ActiveMQ into production!
That warning, although it's not clear from the message, indicates that the
store limit is too high for the amount of space available on the disk and
won't prevent running out of disk space -- at least, if I'm reading the code
correctly.
if ((storeLimit - storeSize) dirFreeSpace) {
So, either free up disk space from other sources (not ActiveMQ data files)
or decrease the store limit in order for it to be effective.
Never remove kahadb files unless you want to wipe all of the messages, in
which case, wipe the entire directory - while the broker is down.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Kahadb-Getting-Worried-Message-tp4679825p4679839.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
