[jira] [Updated] (AMQ-2502) activemq-camel is missing an optional Import-Package for org.apache.activemq.pool
[ https://issues.apache.org/jira/browse/AMQ-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-2502: Fix Version/s: 5.6.0 > activemq-camel is missing an optional Import-Package for > org.apache.activemq.pool > - > > Key: AMQ-2502 > URL: https://issues.apache.org/jira/browse/AMQ-2502 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.2.0, 5.3.0 >Reporter: Phil Messenger >Assignee: Gary Tully > Fix For: 5.3.1, 5.4.0, 5.6.0 > > > If pooling is used, org.apache.activemq.pool.PooledConnectionFactory is > instantiated using reflection. BND does not detect this, so compliant OSGI > containers will throw a class not found exception. To fix, the following line > should be added to the section of the pom: > org.apache.activemq.pool;resolution:=optional, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-796) Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive.
[ https://issues.apache.org/jira/browse/AMQ-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-796: --- Fix Version/s: (was: 5.0.0) 5.6.0 > Client may shtudown when failover connection is reconnecting. We need to > maintain at least 1 non-daemon thread alive. > -- > > Key: AMQ-796 > URL: https://issues.apache.org/jira/browse/AMQ-796 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.0, 5.3.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.6.0, 4.0.3 > > Attachments: AMQ-796.cmd > > > Dejan Reported on the User lists: > Hi, > after some experiments I found that this problem only exists if there are no > other threads in the application. It seems like connection thread dies > before it manages to reconnect. By starting another thread in the > application, it succeeds to recover from master failure and reconnect to the > slave broker. So I have a workaround for now, but it would be nice to make > this work even for simple (single-threaded) clients. > Regards, > Dejan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3768) ClassCastException when running some Durable Consumer test cases
[
https://issues.apache.org/jira/browse/AMQ-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated AMQ-3768:
Assignee: Gary Tully (was: Timothy Bish)
Summary: ClassCastException when running some Durable Consumer test cases
(was: ClassCastException whne running some Durable Consumer test cases)
> ClassCastException when running some Durable Consumer test cases
>
>
> Key: AMQ-3768
> URL: https://issues.apache.org/jira/browse/AMQ-3768
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
>Affects Versions: 5.6.0
>Reporter: Timothy Bish
>Assignee: Gary Tully
> Fix For: 5.6.0
>
>
> When running the DurableSubProcessWithRestartTest for long intervals you can
> sometimes see.
> {noformat}
> ERROR rableSubProcessWithRestartTest - Server.run failed
> java.lang.RuntimeException: Server.run failed
> at
> org.apache.activemq.usecases.DurableSubProcessWithRestartTest.exit(DurableSubProcessWithRestartTest.java:738)
> at
> org.apache.activemq.usecases.DurableSubProcessWithRestartTest$Server.run(DurableSubProcessWithRestartTest.java:185)
> Caused by: javax.jms.JMSException: STORE COMMIT FAILED: Transaction rolled
> back.
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1297)
> at
> org.apache.activemq.TransactionContext.syncSendPacketWithInterruptionHandling(TransactionContext.java:748)
> at
> org.apache.activemq.TransactionContext.commit(TransactionContext.java:322)
> at org.apache.activemq.ActiveMQSession.commit(ActiveMQSession.java:560)
> at
> org.apache.activemq.usecases.DurableSubProcessWithRestartTest$Server.send(DurableSubProcessWithRestartTest.java:232)
> at
> org.apache.activemq.usecases.DurableSubProcessWithRestartTest$Server.run(DurableSubProcessWithRestartTest.java:179)
> Caused by: javax.transaction.xa.XAException: STORE COMMIT FAILED: Transaction
> rolled back.
> at
> org.apache.activemq.transaction.LocalTransaction.commit(LocalTransaction.java:77)
> at
> org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:252)
> at
> org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:103)
> at
> org.apache.activemq.broker.TransportConnection.processCommitTransactionOnePhase(TransportConnection.java:414)
> at
> org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:100)
> at
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:291)
> at
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:149)
> at
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> at
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> at
> org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:218)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> Caused by: java.lang.ClassCastException: org.apache.kahadb.index.BTreeNode
> cannot be cast to org.apache.kahadb.index.ListNode
> at org.apache.kahadb.index.ListIndex.loadNode(ListIndex.java:289)
> at org.apache.kahadb.index.ListIndex.getHead(ListIndex.java:98)
> at org.apache.kahadb.index.ListIndex.iterator(ListIndex.java:266)
> at org.apache.kahadb.index.ListIndex.get(ListIndex.java:127)
> at
> org.apache.activemq.store.kahadb.MessageDatabase.addAckLocationForNewMessage(MessageDatabase.java:1826)
> at
> org.apache.activemq.store.kahadb.MessageDatabase.upadateIndex(MessageDatabase.java:1130)
> at
> org.apache.activemq.store.kahadb.MessageDatabase$AddOpperation.execute(MessageDatabase.java:2029)
> at
> org.apache.activemq.store.kahadb.MessageDatabase$18.execute(MessageDatabase.java:1055)
> at org.apache.kahadb.page.Transaction.execute(Transaction.java:765)
> at
> org.apache.activemq.store.kahadb.MessageDatabase.process(MessageDatabase.java:1052)
> at
> org.apache.activemq.store.kahadb.MessageDatabase$13.visit(MessageDatabase.java:921)
> at
> org.apache.activemq.store.kahadb.data.KahaCommitCommand.visit(KahaCommitCommand.java:130)
> at
> org.apache.activemq.store.kahadb.MessageDatabase.process(MessageDatab
[jira] [Updated] (AMQ-3779) Allow logging broker plugin to use a log per destination
[ https://issues.apache.org/jira/browse/AMQ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3779: Description: Re: http://activemq.2283324.n4.nabble.com/How-to-log-all-incoming-msgs-of-Queue-quot-hello-quot-into-a-separate-logfile-td4487917.html Would be nice to configure the http://activemq.apache.org/logging-interceptor.html to use a send message log per destination so that destination messages can be easily partitioned. A logPerDestination boolean attribute, that would cause the plugin to use a logger of the form: org.apache.activemq.broker.util.LoggingBrokerPlugin. for producer send events -- Query on composites? For the simplest implementation, composites, they would have their unique log rather than parsing the composite and repeating the log message per destination. was: Would be nice to configure the http://activemq.apache.org/logging-interceptor.html to use a send message log per destination so that destination messages can be easily partitioned. A logPerDestination boolean attribute, that would cause the plugin to use a logger of the form: org.apache.activemq.broker.util.LoggingBrokerPlugin. for producer send events -- Query on composites? For the simplest implementation, composites, they would have their unique log rather than parsing the composite and repeating the log message per destination. > Allow logging broker plugin to use a log per destination > > > Key: AMQ-3779 > URL: https://issues.apache.org/jira/browse/AMQ-3779 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.5.1 >Reporter: Gary Tully >Priority: Minor > Labels: logging, plugin > > Re: > http://activemq.2283324.n4.nabble.com/How-to-log-all-incoming-msgs-of-Queue-quot-hello-quot-into-a-separate-logfile-td4487917.html > Would be nice to configure the > http://activemq.apache.org/logging-interceptor.html to use a send message log > per destination so that destination messages can be easily partitioned. > A logPerDestination boolean attribute, that would cause the plugin to use a > logger of the form: > org.apache.activemq.broker.util.LoggingBrokerPlugin. for > producer send events > -- > Query on composites? > For the simplest implementation, composites, they would have their unique log > rather than parsing the composite and repeating the log message per > destination. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3749) Composite destinations break simple authorisation through role aggregation
[
https://issues.apache.org/jira/browse/AMQ-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated AMQ-3749:
Comment: was deleted
(was: The LDAP backed authorisation map does not have this problem.)
> Composite destinations break simple authorisation through role aggregation
> --
>
> Key: AMQ-3749
> URL: https://issues.apache.org/jira/browse/AMQ-3749
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.5.1
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Blocker
> Labels: authorization, composite, security
> Fix For: 5.6.0
>
>
> Given authorisation where there is overlap in roles, using a composite
> destination can gain access in error. eg:{code}
>
>
>admin="admins" />
>admin="users" />
> ...
> {code} The correct expectation is that a 'user' can only access queues that
> match 'USER.>' but a user can bypass this and access a private queue using a
> composite destination q(PRIVATE,USER.A) because the permissions are
> aggregated in error and we look for a single match.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3735) Java service wrapper ${activemq.conf} not found
[
https://issues.apache.org/jira/browse/AMQ-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated AMQ-3735:
Fix Version/s: 5.6.0
make sure we fix for 5.6
> Java service wrapper ${activemq.conf} not found
> ---
>
> Key: AMQ-3735
> URL: https://issues.apache.org/jira/browse/AMQ-3735
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Environment: Ubuntu 11.10 x64
>Reporter: Chris Robison
> Fix For: 5.6.0
>
> Attachments: wrapper.log
>
>
> I downloaded the latest snapshot of the source today and tried installing the
> broker as a service using the instructions here:
> http://www.forwardslashbin.com/?p=46. When running it, apparently the Jetty
> configuration could not find the path to the conf folder. When removing the
> jetty.xml file from activemq xml, everything seemed to execute fine. Looking
> at the revision history, it looks like ${activemq.conf} is new to help
> externalize conf files. I'll be attaching the wrapper.log to this bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3681) DatabaseLocker should first cancel locking SQL statement before closing the SQL connection
[
https://issues.apache.org/jira/browse/AMQ-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated AMQ-3681:
Fix Version/s: 5.6.0
> DatabaseLocker should first cancel locking SQL statement before closing the
> SQL connection
> --
>
> Key: AMQ-3681
> URL: https://issues.apache.org/jira/browse/AMQ-3681
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.4.2
> Environment: ServiceMix 4.3
>Reporter: metatech
> Fix For: 5.6.0
>
> Attachments: amq_stopping_slave.patch, amq_stopping_slave_2.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> ActiveMQ is configured in a Master/Slave configuration with an Oracle
> database :
> http://activemq.apache.org/jdbc-master-slave.html
> http://servicemix.apache.org/clustering.html
> When the slave node is stopping, "activemq-broker" stays forever in the
> "Stopping" state.
> This is because the locking SQL statement cannot be interrupted by just
> closing the JDBC connection. It is also needed to "cancel" the SQL statement.
> Here is a patch to DefaultDatabaseLocker which makes it compatible with
> Oracle.
> Thanks.
> {code}
> "Thread-92" prio=10 tid=0x08c4d800 nid=0x1036 waiting for monitor entry
> [0x8ab3a000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> oracle.jdbc.driver.PhysicalConnection.isClosed(PhysicalConnection.java:1223)
> - waiting to lock <0xad4367e0> (a oracle.jdbc.driver.T4CConnection)
> at
> org.apache.commons.dbcp.DelegatingConnection.isClosed(DelegatingConnection.java:386)
> at
> org.apache.commons.dbcp.DelegatingConnection.isClosed(DelegatingConnection.java:386)
> at
> org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.isClosed(PoolingDataSource.java:201)
> at
> org.apache.activemq.store.jdbc.DefaultDatabaseLocker.stop(DefaultDatabaseLocker.java:137)
> at com.mycompany.PoolCloser.close(PoolCloser.java:77)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:221)
> at
> org.apache.aries.blueprint.container.ServiceListener.invokeMethod(ServiceListener.java:98)
> at
> org.apache.aries.blueprint.container.ServiceListener.unregister(ServiceListener.java:65)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3729) Stomp wireformat and codec block on telnet CRLF CRLF header separator
[ https://issues.apache.org/jira/browse/AMQ-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3729: Affects Version/s: 5.6.0 > Stomp wireformat and codec block on telnet CRLF CRLF header separator > - > > Key: AMQ-3729 > URL: https://issues.apache.org/jira/browse/AMQ-3729 > Project: ActiveMQ > Issue Type: Bug > Components: stomp >Affects Versions: 5.6.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: stomp, telnet > Fix For: 5.6.0 > > > changes 1.1 support and nio have broken telnet support for stomp. The telnet > CRLF in place of LF is the root cause. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3729) Stomp wireformat and codec block on telnet CRLF CRLF header separator
[ https://issues.apache.org/jira/browse/AMQ-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3729: Affects Version/s: (was: 5.5.0) > Stomp wireformat and codec block on telnet CRLF CRLF header separator > - > > Key: AMQ-3729 > URL: https://issues.apache.org/jira/browse/AMQ-3729 > Project: ActiveMQ > Issue Type: Bug > Components: stomp >Affects Versions: 5.6.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: stomp, telnet > Fix For: 5.6.0 > > > changes 1.1 support and nio have broken telnet support for stomp. The telnet > CRLF in place of LF is the root cause. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3525) Messages seem to be getting stuck on queues
[ https://issues.apache.org/jira/browse/AMQ-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3525: Affects Version/s: (was: 5.x) 5.5.0 5.5.1 > Messages seem to be getting stuck on queues > --- > > Key: AMQ-3525 > URL: https://issues.apache.org/jira/browse/AMQ-3525 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.5.0, 5.5.1 > Environment: Red Hat Enterprise Linux 5, x86_64 > apache-activemq-5.5-fuse-20110915.022452-46 >Reporter: Peter Blackburn >Assignee: Gary Tully > Fix For: 5.6.0 > > > Running load test of our application using AMQ as the JMS provider, messages > seem to get stuck on the queues. After load test was stopped, but application > was still running and all consumers still connected to the AMQ server. > Several minutes later, the queue sizes were: > QUEUE_A 2 > QUEUE_B 3 > QUEUE_C 3 > QUEUE_D 1 > QUEUE_E 33 > Our application was then stopped and the AMQ server restarted. There were no > consumers for any of the queues at this point. After restart, the queue sizes > were as follows: > QUEUE_A 2 > QUEUE_C 3 > QUEUE_E 26 > Spot checks of the messages remaining after broker restart appear to show > that they were successfully consumed during the load test run, but are > somehow still on the queues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-2595) NFS problems can cause broker to hang on shutdown requiring a hard kill
[
https://issues.apache.org/jira/browse/AMQ-2595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated AMQ-2595:
Fix Version/s: (was: 5.x)
> NFS problems can cause broker to hang on shutdown requiring a hard kill
>
>
> Key: AMQ-2595
> URL: https://issues.apache.org/jira/browse/AMQ-2595
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Broker
>Affects Versions: 5.3.0
>Reporter: Bruce Snyder
> Fix For: 5.4.3
>
>
> When the ActiveMQ data directory exists on a NFS mounted volume and that
> volume experiences some type of failure, it can cause the broker to hang and
> only a manual kill will shut it down. Below is a sequence of errors
> demonstrating this:
> {code}
> ERROR | Failed to fill batch
> java.io.IOException: I/O error
> at java.io.RandomAccessFile.readBytes(Native Method)
> at java.io.RandomAccessFile.read(RandomAccessFile.java:322)
> at java.io.RandomAccessFile.readFully(RandomAccessFile.java:381)
> at java.io.RandomAccessFile.readFully(RandomAccessFile.java:361)
> at
> org.apache.kahadb.journal.DataFileAccessor.readRecord(DataFileAccessor.java:90)
> at org.apache.kahadb.journal.Journal.read(Journal.java:573)
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:656)
> at
> org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:534)
> at
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$4.execute(KahaDBStore.java:229)
> at org.apache.kahadb.page.Transaction.execute(Transaction.java:728)
> at
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recoverNextMessages(KahaDBStore.java:222)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:81)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:227)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:99)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at org.apache.activemq.broker.region.Queue.doPageIn(Queue.java:1363)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:1503)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1178)
> at
> org.apache.activemq.thread.DeterministicTaskRunner.runTask(DeterministicTaskRunner.java:84)
> at
> org.apache.activemq.thread.DeterministicTaskRunner$1.run(DeterministicTaskRunner.java:41)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> ERROR | Failed to fill batch
> java.lang.RuntimeException: java.io.IOException: I/O error
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:230)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:99)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at org.apache.activemq.broker.region.Queue.doPageIn(Queue.java:1363)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:1503)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1178)
> at
> org.apache.activemq.thread.DeterministicTaskRunner.runTask(DeterministicTaskRunner.java:84)
> at
> org.apache.activemq.thread.DeterministicTaskRunner$1.run(DeterministicTaskRunner.java:41)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.io.IOException: I/O error
> at java.io.RandomAccessFile.readBytes(Native Method)
> at java.io.RandomAccessFile.read(RandomAccessFile.java:322)
> at java.io.RandomAccessFile.readFully(RandomAccessFile.java:381)
> at java.io.RandomAccessFile.readFully(RandomAccessFile.java:361)
> at
> org.apache.kahadb.journal.DataFileAccessor.readRecord(DataFileAccessor.java:90)
> at org.apache.kahadb.journal.Journal.read(Journal.java:573)
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:656)
> at
> org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:534)
> at
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$4.execute(KahaDBStore.java:229)
> at org.apache.kahadb.page.Transact
[jira] [Updated] (AMQ-3436) Support Prioritization Of Messages Pending Dispatch
[ https://issues.apache.org/jira/browse/AMQ-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3436: Fix Version/s: 5.6.0 patch and test, should put in 5.6 > Support Prioritization Of Messages Pending Dispatch > --- > > Key: AMQ-3436 > URL: https://issues.apache.org/jira/browse/AMQ-3436 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.5.0 >Reporter: Kevin Urciolo >Priority: Minor > Fix For: 5.6.0 > > Attachments: AMQPriorityTest.java, OrderedPendingList.java-patch.txt, > PendingList.java-patch.txt, PrioritizedPendingList.java-patch.txt, > Queue.java-patch.txt > > > ActiveMQ does not deliver messages in priority order when the following > conditions are true: > 1. A consumer has prefetch set to one (or zero). > 2. The consumer is created (consumerSession.createConsumer) prior to message > delivery > 3. Large maxPageSize is configured > The fix is to modify org.apache.activemq.broker.region.Queue to use a > PrioritizationPendingList for the message in "pagedInPendingDispatch" so they > are dispatched in priority order. > A test case reproducing the issue is included. > The patched file deltas are included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3575) Failover transport race condition causes intermittent incomplete bridge connections
[ https://issues.apache.org/jira/browse/AMQ-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3575: Fix Version/s: (was: NEEDS_REVIEWED) 5.6.0 Assignee: Gary Tully > Failover transport race condition causes intermittent incomplete bridge > connections > --- > > Key: AMQ-3575 > URL: https://issues.apache.org/jira/browse/AMQ-3575 > Project: ActiveMQ > Issue Type: Bug > Components: Transport >Affects Versions: 5.5.0 > Environment: CentOS 5.5 and Mac OSX10 >Reporter: Aaron Phillips >Assignee: Gary Tully > Fix For: 5.6.0 > > Attachments: FailoverNetworkConnectionRaceConditionTest.java > > > There is a race condition in FailoverTransport.java that sometimes results in > preventing network bridge connections from starting. This is a serious issue > as it was preventing us from setting up failover connections between brokers. > I would have asked it be critical if it weren't for a workaround. The > workaround I have found is as follows: > Turn on activemq thread pooling option to avoid failover bridge connection > race condition. Change the following property to in your start script to > make it false like so. Somehow this got me around the problem of the wrong > thread sometimes winning: > -Dorg.apache.activemq.UseDedicatedTaskRunner=false > I've attached a unit test to be dropped in > activemq-core/src/test/java/org/apache/activemq/transport/failover. The unit > test shows that when a delay is introduced in setting of the > TransportListener, the BrokerInfo command required to complete the bridge > connection will never be processed. There are two unit tests in this class > and both are designed to pass. The test called > "testTcpThreadWinsPreventsCompletionOfBridge" passes by asserting that it > *did not* receive the BrokerInfo command. You can see through setting the > delay value that you can control whether the Main thread wins (in which case > all is well), or the TCP thread wins (in which case the network bridge is > hung and fails to start) > Note, this issue only affects network bridge connections which are setup with > failover transport, such as a broker that connects to a Master-Slave pair, > e.g. failover://(tcp://master:61616,tcp://slave:61616)?randomize=false -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3576) ProducerBrokerExchange last producer sequenceId initialization needs runtime updates to deal with possible duplicate resends
[ https://issues.apache.org/jira/browse/AMQ-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3576: Description: Under load, a buffered pending send can be replayed along with a failover replay (writeTimeFilter initiated) which can miss the audit b/c it won't have knowledge of the original send. The dispatch decision is based on the current stored state at the time of reconnect with the expectation that the next message will not be duplicated. It seems under some load and tcp buffering conditions this is possible to get duplicate sends of new messages. was:Under load, a buffered pending send can be replayed along with a failover replay (writeTimeFilter initiated) which can miss the audit b/c it won't have knowledge of the original send. Environment: failover:(tcp://host:port?soWriteTimeout=500)?jms.useAsyncSend=true&trackMessages=true > ProducerBrokerExchange last producer sequenceId initialization needs runtime > updates to deal with possible duplicate resends > > > Key: AMQ-3576 > URL: https://issues.apache.org/jira/browse/AMQ-3576 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.5.1 > Environment: > failover:(tcp://host:port?soWriteTimeout=500)?jms.useAsyncSend=true&trackMessages=true >Reporter: Gary Tully > Fix For: 5.6.0 > > > Under load, a buffered pending send can be replayed along with a failover > replay (writeTimeFilter initiated) which can miss the audit b/c it won't have > knowledge of the original send. > The dispatch decision is based on the current stored state at the time of > reconnect with the expectation that the next message will not be duplicated. > It seems under some load and tcp buffering conditions this is possible to get > duplicate sends of new messages. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-2455) Need a facility to retry jms connections to a foreign provider by the ActiveMQ JMS bridge.
[ https://issues.apache.org/jira/browse/AMQ-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-2455: Fix Version/s: (was: 5.4.0) 5.6.0 lets see if we can resolve this for 5.6 > Need a facility to retry jms connections to a foreign provider by the > ActiveMQ JMS bridge. > -- > > Key: AMQ-2455 > URL: https://issues.apache.org/jira/browse/AMQ-2455 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker > Environment: Debian Lenny. ActiveMQ 5.2. OpenJMS-0.7.7-beta-1 >Reporter: Billy Buzzard >Assignee: Rob Davies > Fix For: 5.6.0 > > Attachments: bridge-reconnect.patch, test.zip > > > I followed an example > (http://www.codeproject.com/KB/docview/jms_to_jms_bridge_activem.aspx?display=Print) > showing how to set up a bridge between OpenJMS and ActiveMQ. The bridge > seems to work perfectly until I stop then restart OpenJMS while leaving > ActiveMQ running. Once I restart OpenJMS I try sending a message from it to > ActiveMQ, but ActiveMQ doesn't receive it until I stop and restart ActiveMQ. > I can recreate the exact same problem by starting ActiveMQ first and then > OpenJMS. After a little more reading it looks like failover should fix this > problem, but I tried it and it didn't work. I submitted a question to > ActiveMQ and Gary Tully responded and told me there is currently no facility > to retry jms connections to a foreign provider by the ActiveMQ JMS bridge. > Assuming that remote end-points may not be using ActiveMQ then I would think > this would be a very important feature to have. > Here's a link to our conversation: > http://www.nabble.com/How-to-configure-failover-for-jmsBridgeConnector-td25909047.html#a25918800 > The conversation also contains an attachment showing me configuration file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3553) Web console only allow usage of the web-console broker
[ https://issues.apache.org/jira/browse/AMQ-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3553: Fix Version/s: (was: 5.6.0) > Web console only allow usage of the web-console broker > -- > > Key: AMQ-3553 > URL: https://issues.apache.org/jira/browse/AMQ-3553 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.5.0 >Reporter: Jean-Baptiste Onofré > Fix For: 5.x > > > Installing ActiveMQ WebConsole on Karaf (using features:install > activemq-web-console) works fine, but: > - we can only administrate/monitore the web-console broker (using the > WEB-INF/activemq.xml embedded file) > - creating a new broker using activemq:create looks to break the web console > I will submit a patch to enhance the web console behavior :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3554) activemq:create command should use name as argument in place of option
[ https://issues.apache.org/jira/browse/AMQ-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3554: Fix Version/s: (was: 5.6.0) > activemq:create command should use name as argument in place of option > -- > > Key: AMQ-3554 > URL: https://issues.apache.org/jira/browse/AMQ-3554 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.5.0 >Reporter: Jean-Baptiste Onofré > Fix For: 5.x > > > Karaf ActiveMQ command activemq:create use -n (or --name) to define the name. > The name is mandatory, so it makes sense to use it as argument in place of an > option. > It means that: > activemq:create -n test > will become > activemq:create test > More other, activemq:create-broker seems to be more consistent. > I will submit a patch to enhance/rename all Karaf commands to be consistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3553) Web console only allow usage of the web-console broker
[ https://issues.apache.org/jira/browse/AMQ-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3553: Fix Version/s: 5.x moved out to 5.x pending patch > Web console only allow usage of the web-console broker > -- > > Key: AMQ-3553 > URL: https://issues.apache.org/jira/browse/AMQ-3553 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.5.0 >Reporter: Jean-Baptiste Onofré > Fix For: 5.6.0, 5.x > > > Installing ActiveMQ WebConsole on Karaf (using features:install > activemq-web-console) works fine, but: > - we can only administrate/monitore the web-console broker (using the > WEB-INF/activemq.xml embedded file) > - creating a new broker using activemq:create looks to break the web console > I will submit a patch to enhance the web console behavior :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3554) activemq:create command should use name as argument in place of option
[ https://issues.apache.org/jira/browse/AMQ-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3554: Fix Version/s: 5.x if we get a patch we can slip it into 5.6 > activemq:create command should use name as argument in place of option > -- > > Key: AMQ-3554 > URL: https://issues.apache.org/jira/browse/AMQ-3554 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.5.0 >Reporter: Jean-Baptiste Onofré > Fix For: 5.6.0, 5.x > > > Karaf ActiveMQ command activemq:create use -n (or --name) to define the name. > The name is mandatory, so it makes sense to use it as argument in place of an > option. > It means that: > activemq:create -n test > will become > activemq:create test > More other, activemq:create-broker seems to be more consistent. > I will submit a patch to enhance/rename all Karaf commands to be consistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3560) Destinations do not implement javax.resource.Referenceable and will not be registerable in JNDI by some compliant JCA containers.
[ https://issues.apache.org/jira/browse/AMQ-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3560: Fix Version/s: 5.6.0 another good candidate for 5.6, should be an easy fix. > Destinations do not implement javax.resource.Referenceable and will not be > registerable in JNDI by some compliant JCA containers. > - > > Key: AMQ-3560 > URL: https://issues.apache.org/jira/browse/AMQ-3560 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.5.1 > Environment: JBoss 7.1.0.Alpha2 / ironjacamar 1.0.4 >Reporter: Mike G > Labels: destinations, jca, jndi > Fix For: 5.6.0 > > > According to the JCA spec, AdminObjects are only guaranteed to be bound in > JNDI by the JCA provider if javax.resource.Referenceable is implemented. See > 13.4.2.3 "Administered Objects". A JMS provider is free to provide > AdminObjects that implement only javax.naming.Referenceable in an otherwise > unmanaged environment, but a resource adapter must allow the application > server/jca container to use its own ObjectFactory and call setReference() on > the admin objects that need to be looked up. See 20.6 JNDI Configuration and > Lookup. > This is a problem for users using an application server such as the current > release of AS7 which will not bind AdminObjects otherwise. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3527) ./activemq script cannot be started on Solaris OS 10
[ https://issues.apache.org/jira/browse/AMQ-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-3527: Description: issue with finding whoami and use of bash $(..) evaluations in place of `` bourne shell syntax Labels: activemq script (was: ) > ./activemq script cannot be started on Solaris OS 10 > > > Key: AMQ-3527 > URL: https://issues.apache.org/jira/browse/AMQ-3527 > Project: ActiveMQ > Issue Type: Bug >Reporter: Gary Tully > Labels: activemq, script > > issue with finding whoami and use of bash $(..) evaluations in place of `` > bourne shell syntax -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
