[jira] [Commented] (AMQ-4487) java.lang.OutOfMemoryError: Java heap space
[ https://issues.apache.org/jira/browse/AMQ-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658212#comment-13658212 ] Subathra Jayaraman commented on AMQ-4487: - Can you please provide us an update on this issue. java.lang.OutOfMemoryError: Java heap space --- Key: AMQ-4487 URL: https://issues.apache.org/jira/browse/AMQ-4487 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: OS - Linux 2.6.18-238.el5 #1 SMP Sun Dec 19 14:22:44 EST 2010 x86_64 x86_64 x86_64 GNU/Linux Activemq - 5.8 Reporter: Subathra Jayaraman Hi, When we browse a queue in webconsole we are getting java.lang.OutOfMemoryError: Java heap space. Memory allocation - -Xms512m -Xmx3G When we try to click the queue to view the messages below error is occurring. We recently moved from 5.7 to 5.8 version. We dint face this issue in 5.7 version. Kindly help in fixing the issue. java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.io.CharArrayWriter.write(CharArrayWriter.java:88) at java.io.PrintWriter.write(PrintWriter.java:382) at com.opensymphony.module.sitemesh.filter.RoutablePrintWriter.write(RoutablePrintWriter.java:144) at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:181) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:449) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:462) at org.apache.jsp.browse_jsp$browse_jspHelper.invoke0(org.apache.jsp.browse_jsp:382) at org.apache.jsp.browse_jsp$browse_jspHelper.invoke(org.apache.jsp.browse_jsp:450) at org.apache.jsp.tag.web.jms.forEachMessage_tag.doTag(org.apache.jsp.tag.web.jms.forEachMessage_tag:89) at org.apache.jsp.browse_jsp._jspx_meth_jms_forEachMessage_0(org.apache.jsp.browse_jsp:170) at org.apache.jsp.browse_jsp._jspService(org.apache.jsp.browse_jsp:100) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:389) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1329) at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300) at org.apache.activemq.web.SessionFilter.doFilter(SessionFilter.java:45) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300) at org.apache.activemq.web.filter.ApplicationContextFilter.doFilter(ApplicationContextFilter.java:102) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300) at com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129) at com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) Thank you. Regards, Subathra. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4490) JDBCMessageStore fails to retrieve message after 200 messages when cache is disabled
[
https://issues.apache.org/jira/browse/AMQ-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658214#comment-13658214
]
metatech commented on AMQ-4490:
---
Problem cannot be reproduced on 5.6, closing this ticket.
JDBCMessageStore fails to retrieve message after 200 messages when cache is
disabled
Key: AMQ-4490
URL: https://issues.apache.org/jira/browse/AMQ-4490
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.5.1
Environment: ServiceMix 4.4.2
Reporter: metatech
When trying to reproduce bug AMQ-4489, we found that the JDBCMessageStore
fails to retrieve all messages from the store when useCache=false.
The existing unit test JDBCMessagePriorityTest reproduces it (see below).
A similar problem occurs when MemoryLimit on the queue is used (which forces
the messages to be written to and later read from the JDBC message store).
Can you please have a look ?
---
Test set: org.apache.activemq.store.jdbc.JDBCMessagePriorityTest
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 12.94 sec
FAILURE!
testQueues
{useCache=false}(org.apache.activemq.store.jdbc.JDBCMessagePriorityTest)
Time elapsed: 6.656 sec FAILURE!
junit.framework.AssertionFailedError: Message 200 was null
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (AMQ-4490) JDBCMessageStore fails to retrieve message after 200 messages when cache is disabled
[
https://issues.apache.org/jira/browse/AMQ-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
metatech closed AMQ-4490.
-
Resolution: Fixed
Fix Version/s: 5.6.0
JDBCMessageStore fails to retrieve message after 200 messages when cache is
disabled
Key: AMQ-4490
URL: https://issues.apache.org/jira/browse/AMQ-4490
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.5.1
Environment: ServiceMix 4.4.2
Reporter: metatech
Fix For: 5.6.0
When trying to reproduce bug AMQ-4489, we found that the JDBCMessageStore
fails to retrieve all messages from the store when useCache=false.
The existing unit test JDBCMessagePriorityTest reproduces it (see below).
A similar problem occurs when MemoryLimit on the queue is used (which forces
the messages to be written to and later read from the JDBC message store).
Can you please have a look ?
---
Test set: org.apache.activemq.store.jdbc.JDBCMessagePriorityTest
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 12.94 sec
FAILURE!
testQueues
{useCache=false}(org.apache.activemq.store.jdbc.JDBCMessagePriorityTest)
Time elapsed: 6.656 sec FAILURE!
junit.framework.AssertionFailedError: Message 200 was null
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4000) Durable subscription not getting unregistered on networked broker
[ https://issues.apache.org/jira/browse/AMQ-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658304#comment-13658304 ] Dejan Bosanac commented on AMQ-4000: As a first step we need a proper way to send advisories when durable sub unsubscribes. I started with Christian's solution but noted a couple of cases that were not covered, like sending advisory when unsubscribing using JMX and after restarting a broker. I committed a new fix in svn revision 1482790. I'll now proceed to trying to implement the rest of this feature. Durable subscription not getting unregistered on networked broker - Key: AMQ-4000 URL: https://issues.apache.org/jira/browse/AMQ-4000 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.6.0 Environment: network of brokers, durable topic subscriptions. Reporter: Torsten Mielke Assignee: Christian Posta Labels: durable_subscription, networks Attachments: JUnitTest.patch In a network of two brokers, a durable subscription is correctly propagated across to the remote broker. However when the consumer unsubscribes from the durable subscription again, it is only removed on the local broker but not on the remote broker. The remote broker keeps its durable subscription alive. As a consequence messages sent to the topic destination on the remote broker for which the durable subscriptions existed, are passed on to the local broker, although there is no active subscription on the local broker. The local broker will discard these msgs but unnecessary traffic has already occurred on the network bridge. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4538) activemq-perftest broken in 5.8.0
Nick Spacek created AMQ-4538:
Summary: activemq-perftest broken in 5.8.0
Key: AMQ-4538
URL: https://issues.apache.org/jira/browse/AMQ-4538
Project: ActiveMQ
Issue Type: Bug
Components: Performance Test
Affects Versions: 5.8.0
Environment: Ubuntu 12.10
Maven 3.0.4
Reporter: Nick Spacek
I tried setting up my own Maven project to do some ActiveMQ load tests and also
used the code at
http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both give
me the same error below when I execute: mvn activemq-perf:broker
-Durl=broker:tcp://localhost:61616
The double-var-encoded string looks strange. I also end up with a folder in the
project directory: ${${project.build.directory}}.
I am able to run other Maven plugins in the project and other local projects
just fine.
java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.checkChars(URI.java:3002)
at java.net.URI$Parser.parseHierarchical(URI.java:3086)
at java.net.URI$Parser.parse(URI.java:3044)
at java.net.URI.init(URI.java:595)
at
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
at org.apache.activemq.console.Main.main(Main.java:115)
at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4537) activemq-perftest broken in 5.8.0
Nick Spacek created AMQ-4537:
Summary: activemq-perftest broken in 5.8.0
Key: AMQ-4537
URL: https://issues.apache.org/jira/browse/AMQ-4537
Project: ActiveMQ
Issue Type: Bug
Components: Performance Test
Affects Versions: 5.8.0
Environment: Ubuntu 12.10
Maven 3.0.4
Reporter: Nick Spacek
I tried setting up my own Maven project to do some ActiveMQ load tests and also
used the code at
http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both give
me the same error below when I execute: mvn activemq-perf:broker
-Durl=broker:tcp://localhost:61616
The double-var-encoded string looks strange. I also end up with a folder in the
project directory: ${${project.build.directory}}.
I am able to run other Maven plugins in the project and other local projects
just fine.
java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.checkChars(URI.java:3002)
at java.net.URI$Parser.parseHierarchical(URI.java:3086)
at java.net.URI$Parser.parse(URI.java:3044)
at java.net.URI.init(URI.java:595)
at
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
at org.apache.activemq.console.Main.main(Main.java:115)
at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (AMQ-4538) activemq-perftest broken in 5.8.0
[
https://issues.apache.org/jira/browse/AMQ-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Spacek closed AMQ-4538.
Resolution: Duplicate
activemq-perftest broken in 5.8.0
-
Key: AMQ-4538
URL: https://issues.apache.org/jira/browse/AMQ-4538
Project: ActiveMQ
Issue Type: Bug
Components: Performance Test
Affects Versions: 5.8.0
Environment: Ubuntu 12.10
Maven 3.0.4
Reporter: Nick Spacek
I tried setting up my own Maven project to do some ActiveMQ load tests and
also used the code at
http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both
give me the same error below when I execute: mvn activemq-perf:broker
-Durl=broker:tcp://localhost:61616
The double-var-encoded string looks strange. I also end up with a folder in
the project directory: ${${project.build.directory}}.
I am able to run other Maven plugins in the project and other local projects
just fine.
java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.checkChars(URI.java:3002)
at java.net.URI$Parser.parseHierarchical(URI.java:3086)
at java.net.URI$Parser.parse(URI.java:3044)
at java.net.URI.init(URI.java:595)
at
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
at org.apache.activemq.console.Main.main(Main.java:115)
at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4535) activemq configured with leveldb commit fail when accessed by PutGet f-tion from IBM Perf Harness
[ https://issues.apache.org/jira/browse/AMQ-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4535. Resolution: Fixed Fix Version/s: 5.9.0 Assignee: Hiram Chirino Fixed in trunk. Thanks for the bug report! activemq configured with leveldb commit fail when accessed by PutGet f-tion from IBM Perf Harness - Key: AMQ-4535 URL: https://issues.apache.org/jira/browse/AMQ-4535 Project: ActiveMQ Issue Type: Bug Components: activemq-leveldb-store, Broker Affects Versions: 5.8.0 Environment: RHEL 6.4 Reporter: Valentina Assignee: Hiram Chirino Fix For: 5.9.0 Attachments: activemq.xml, amq_test_reproducer.sh Poor performance and exceptions thrown when leveldb is configured with activemq while performance is measured with IBM Performance Harness. We use default configuration of activemq except that leveldb is used instead of kahadb. Test scenario uses jms.r11.PutGet which sends a message then receives one from the same queue. Normal usage is with correlation identifier to ensure the same message is received. Exception thrown by the broker : WARN | Store COMMIT FAILED: scala.MatchError: null at org.apache.activemq.leveldb.DelayableUOW.dequeue(DBManager.scala:282) at org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.doRemove(LevelDBStore.scala:578) at org.apache.activemq.leveldb.LevelDBStore$Transaction$$anon$3.commit(LevelDBStore.scala:328) at org.apache.activemq.leveldb.LevelDBStore$$anonfun$commit$1$$anonfun$apply$10.apply(LevelDBStore.scala:381) at org.apache.activemq.leveldb.LevelDBStore$$anonfun$commit$1$$anonfun$apply$10.apply(LevelDBStore.scala:380) at scala.collection.immutable.List.foreach(List.scala:309) at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:32) at scala.collection.mutable.ListBuffer.foreach(ListBuffer.scala:45) at org.apache.activemq.leveldb.LevelDBStore$$anonfun$commit$1.apply(LevelDBStore.scala:380) at org.apache.activemq.leveldb.LevelDBStore$$anonfun$commit$1.apply(LevelDBStore.scala:379) at org.apache.activemq.leveldb.LevelDBStore.withUow(LevelDBStore.scala:536) at org.apache.activemq.leveldb.LevelDBStore.commit(LevelDBStore.scala:379) at org.apache.activemq.transaction.LocalTransaction.commit(LocalTransaction.java:72) at org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:263) at org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:103) at org.apache.activemq.broker.TransportConnection.processCommitTransactionOnePhase(TransportConnection.java:456) at org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:100) at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:329) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:184) at org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113) at org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:288) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83) at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196) at java.lang.Thread.run(Thread.java:722) The transaction does not exist Exception thrown by the client: PutGet1: Uncaught exception. 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:1391) 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:561) at com.ibm.uk.hursley.perfharness.jms.r11.PutGet.oneIteration(PutGet.java:97) at com.ibm.uk.hursley.perfharness.WorkerThread.pace(WorkerThread.java:247) at com.ibm.uk.hursley.perfharness.WorkerThread.pace(WorkerThread.java:434) at com.ibm.uk.hursley.perfharness.jms.r11.JMS11WorkerThread.run(JMS11WorkerThread.java:286) at com.ibm.uk.hursley.perfharness.jms.r11.PutGet.run(PutGet.java:86) Caused by: javax.transaction.xa.XAException: STORE COMMIT FAILED: Transaction rolled back. at
[jira] [Commented] (AMQ-4537) activemq-perftest broken in 5.8.0
[
https://issues.apache.org/jira/browse/AMQ-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658454#comment-13658454
]
Christian Posta commented on AMQ-4537:
--
Can you try a 5.9-SNAPSHOT? There were some fixes around the perftest maven
plugin especially around running the broker from the perf plugin...
https://issues.apache.org/jira/browse/AMQ-4466
activemq-perftest broken in 5.8.0
-
Key: AMQ-4537
URL: https://issues.apache.org/jira/browse/AMQ-4537
Project: ActiveMQ
Issue Type: Bug
Components: Performance Test
Affects Versions: 5.8.0
Environment: Ubuntu 12.10
Maven 3.0.4
Reporter: Nick Spacek
I tried setting up my own Maven project to do some ActiveMQ load tests and
also used the code at
http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both
give me the same error below when I execute: mvn activemq-perf:broker
-Durl=broker:tcp://localhost:61616
The double-var-encoded string looks strange. I also end up with a folder in
the project directory: ${${project.build.directory}}.
I am able to run other Maven plugins in the project and other local projects
just fine.
java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.checkChars(URI.java:3002)
at java.net.URI$Parser.parseHierarchical(URI.java:3086)
at java.net.URI$Parser.parse(URI.java:3044)
at java.net.URI.init(URI.java:595)
at
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
at org.apache.activemq.console.Main.main(Main.java:115)
at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
After running mvn --debug, I can also see this being generated:
[DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?
configuration
configDirectory
default-value=${basedir}/src/main/resources/broker-conf${${configDirectory}}/configDirectory
configFile${${configFile}}/configFile
configType default-value=activemq${${configType}}/configType
[jira] [Assigned] (AMQ-4537) activemq-perftest broken in 5.8.0
[
https://issues.apache.org/jira/browse/AMQ-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Posta reassigned AMQ-4537:
Assignee: Christian Posta
activemq-perftest broken in 5.8.0
-
Key: AMQ-4537
URL: https://issues.apache.org/jira/browse/AMQ-4537
Project: ActiveMQ
Issue Type: Bug
Components: Performance Test
Affects Versions: 5.8.0
Environment: Ubuntu 12.10
Maven 3.0.4
Reporter: Nick Spacek
Assignee: Christian Posta
I tried setting up my own Maven project to do some ActiveMQ load tests and
also used the code at
http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both
give me the same error below when I execute: mvn activemq-perf:broker
-Durl=broker:tcp://localhost:61616
The double-var-encoded string looks strange. I also end up with a folder in
the project directory: ${${project.build.directory}}.
I am able to run other Maven plugins in the project and other local projects
just fine.
java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.checkChars(URI.java:3002)
at java.net.URI$Parser.parseHierarchical(URI.java:3086)
at java.net.URI$Parser.parse(URI.java:3044)
at java.net.URI.init(URI.java:595)
at
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
at org.apache.activemq.console.Main.main(Main.java:115)
at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
After running mvn --debug, I can also see this being generated:
[DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?
configuration
configDirectory
default-value=${basedir}/src/main/resources/broker-conf${${configDirectory}}/configDirectory
configFile${${configFile}}/configFile
configType default-value=activemq${${configType}}/configType
outputDirectory${${project.build.directory}}/outputDirectory
url${${url}}/url
/configuration
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
[jira] [Commented] (AMQ-4537) activemq-perftest broken in 5.8.0
[
https://issues.apache.org/jira/browse/AMQ-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658511#comment-13658511
]
Nick Spacek commented on AMQ-4537:
--
Of course! That's what I'll end up doing too. Thanks for your help.
activemq-perftest broken in 5.8.0
-
Key: AMQ-4537
URL: https://issues.apache.org/jira/browse/AMQ-4537
Project: ActiveMQ
Issue Type: Bug
Components: Performance Test
Affects Versions: 5.8.0
Environment: Ubuntu 12.10
Maven 3.0.4
Reporter: Nick Spacek
Assignee: Christian Posta
I tried setting up my own Maven project to do some ActiveMQ load tests and
also used the code at
http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both
give me the same error below when I execute: mvn activemq-perf:broker
-Durl=broker:tcp://localhost:61616
The double-var-encoded string looks strange. I also end up with a folder in
the project directory: ${${project.build.directory}}.
I am able to run other Maven plugins in the project and other local projects
just fine.
java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.checkChars(URI.java:3002)
at java.net.URI$Parser.parseHierarchical(URI.java:3086)
at java.net.URI$Parser.parse(URI.java:3044)
at java.net.URI.init(URI.java:595)
at
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
at org.apache.activemq.console.Main.main(Main.java:115)
at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
After running mvn --debug, I can also see this being generated:
[DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?
configuration
configDirectory
default-value=${basedir}/src/main/resources/broker-conf${${configDirectory}}/configDirectory
configFile${${configFile}}/configFile
configType default-value=activemq${${configType}}/configType
outputDirectory${${project.build.directory}}/outputDirectory
url${${url}}/url
/configuration
--
This message is
[jira] [Resolved] (AMQ-4537) activemq-perftest broken in 5.8.0
[
https://issues.apache.org/jira/browse/AMQ-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Posta resolved AMQ-4537.
--
Resolution: Fixed
Fix Version/s: 5.9.0
Cool. No problem!
activemq-perftest broken in 5.8.0
-
Key: AMQ-4537
URL: https://issues.apache.org/jira/browse/AMQ-4537
Project: ActiveMQ
Issue Type: Bug
Components: Performance Test
Affects Versions: 5.8.0
Environment: Ubuntu 12.10
Maven 3.0.4
Reporter: Nick Spacek
Assignee: Christian Posta
Fix For: 5.9.0
I tried setting up my own Maven project to do some ActiveMQ load tests and
also used the code at
http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both
give me the same error below when I execute: mvn activemq-perf:broker
-Durl=broker:tcp://localhost:61616
The double-var-encoded string looks strange. I also end up with a folder in
the project directory: ${${project.build.directory}}.
I am able to run other Maven plugins in the project and other local projects
just fine.
java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.checkChars(URI.java:3002)
at java.net.URI$Parser.parseHierarchical(URI.java:3086)
at java.net.URI$Parser.parse(URI.java:3044)
at java.net.URI.init(URI.java:595)
at
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
at
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
at
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
at org.apache.activemq.console.Main.main(Main.java:115)
at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
After running mvn --debug, I can also see this being generated:
[DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?
configuration
configDirectory
default-value=${basedir}/src/main/resources/broker-conf${${configDirectory}}/configDirectory
configFile${${configFile}}/configFile
configType default-value=activemq${${configType}}/configType
outputDirectory${${project.build.directory}}/outputDirectory
url${${url}}/url
/configuration
--
This message is automatically
[jira] [Resolved] (AMQNET-416) DTC Ressource ManagerID must be confugurable
[ https://issues.apache.org/jira/browse/AMQNET-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQNET-416. - Resolution: Fixed Fix Version/s: 1.6.0 Assignee: Timothy Bish (was: Jim Gomes) Fixed on trunk but adding optional property on the connection factory and in the connection. Value is set as a String to allow configuration via connection Uri. DTC Ressource ManagerID must be confugurable Key: AMQNET-416 URL: https://issues.apache.org/jira/browse/AMQNET-416 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Reporter: Remo Gloor Assignee: Timothy Bish Priority: Critical Fix For: 1.6.0 Attachments: allDTCImprovments.patch, MakeResourceManagerIDConfigurable.patch Currently the ressource manager ID for DTC transactions is set to a value generated from the Broker ID. With this implementation it is not possible to have more than one process connected to the same broker because in that case an exception is thrown when the second process tries to enlist to the transaction. I suggest to make this ID configurable by the application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
spring jms listener container with concurrency=1
Hi, When i configured like this jms:listener-container concurrency=1 destination-type=queue jms:listener id=QListener destination=dataQ ref=qListener method=onMessage/ /jms:listener-container I am expecting to create only one listener to consume queue message in the order. But it 2 listeners are creating and consuming the queue messages leads to message disorder. -- View this message in context: http://activemq.2283324.n4.nabble.com/spring-jms-listener-container-with-concurrency-1-tp4667062.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] [Resolved] (AMQNET-421) Replace Mutex by lock
[ https://issues.apache.org/jira/browse/AMQNET-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQNET-421. - Resolution: Fixed Fix Version/s: 1.6.0 Assignee: Timothy Bish (was: Jim Gomes) Fixes applied on trunk. Replace Mutex by lock - Key: AMQNET-421 URL: https://issues.apache.org/jira/browse/AMQNET-421 Project: ActiveMQ .Net Issue Type: Improvement Components: ActiveMQ Reporter: Remo Gloor Assignee: Timothy Bish Fix For: 1.6.0 Attachments: allDTCImprovments.patch, UseLockToMakeSureSyncObjectIsReleasedOnExceptions.patch The Transaction implementation currently uses a Mutex that is not guarded by try-finally. In case of an exception the Mutex is kept in an aquired state and will never recover. By replacing this by lock they the sync object is properly released on an exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQNET-411) NMS.Stomp: System.FormatException in the Inactivity Monitor on Windows 8 with a non US (European) Current Culture
[ https://issues.apache.org/jira/browse/AMQNET-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQNET-411. - Resolution: Fixed Fix Version/s: 1.6.0 Assignee: Timothy Bish (was: Jim Gomes) Applied the suggested fix on trunk. NMS.Stomp: System.FormatException in the Inactivity Monitor on Windows 8 with a non US (European) Current Culture - Key: AMQNET-411 URL: https://issues.apache.org/jira/browse/AMQNET-411 Project: ActiveMQ .Net Issue Type: Bug Components: NMS, Stomp Affects Versions: 1.5.3 Environment: Windows 8, .NET Framework 2.0, ActiveMQ 5.6 with STOMP Reporter: Frederiek Lefebvre Assignee: Timothy Bish Fix For: 1.6.0 I have a Windows 8 PC where the Current Culture is set to nl-BE. I'm communicating with an ActiveMQ 5.6 Server using STOMP. When I issue a connection.Start(), I get a ConnectionClosedException The connection is already closed!. When I enable tracing, I get another exception before that: Debug: Exception received in the Inactivity Monitor: System.FormatException: Inp ut string was not in a correct format. at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffe r number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseSingle(String value, NumberStyles options, NumberFormat Info numfmt) at System.Single.Parse(String s, NumberStyles style, NumberFormatInfo info) at System.Single.Parse(String s) at Apache.NMS.Stomp.Protocol.StompWireFormat.ReadConnected(StompFrame frame) in c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.N MS.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 200 at Apache.NMS.Stomp.Protocol.StompWireFormat.CreateCommand(StompFrame frame) in c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.N MS.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 154 at Apache.NMS.Stomp.Protocol.StompWireFormat.Unmarshal(BinaryReader dataIn) i n c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.NM S.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 124 at Apache.NMS.Stomp.Transport.Tcp.TcpTransport.ReadLoop() in c:\Users\fretje\ Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.NMS.Stomp-1.5.3-src\ src\main\csharp\Transport\Tcp\TcpTransport.cs:line 285 Debug: Async exception with no exception listener: System.FormatException: Input string was not in a correct format. at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffe r number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseSingle(String value, NumberStyles options, NumberFormat Info numfmt) at System.Single.Parse(String s, NumberStyles style, NumberFormatInfo info) at System.Single.Parse(String s) at Apache.NMS.Stomp.Protocol.StompWireFormat.ReadConnected(StompFrame frame) in c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.N MS.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 200 at Apache.NMS.Stomp.Protocol.StompWireFormat.CreateCommand(StompFrame frame) in c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.N MS.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 154 at Apache.NMS.Stomp.Protocol.StompWireFormat.Unmarshal(BinaryReader dataIn) i n c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.NM S.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 124 at Apache.NMS.Stomp.Transport.Tcp.TcpTransport.ReadLoop() in c:\Users\fretje\ Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.NMS.Stomp-1.5.3-src\ src\main\csharp\Transport\Tcp\TcpTransport.cs:line 285 Apache.NMS.Stomp.ConnectionClosedException: The connection is already closed! at Apache.NMS.Stomp.Connection.CheckConnected() in c:\Users\fretje\Documents\ Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.NMS.Stomp-1.5.3-src\src\main\c sharp\Connection.cs:line 609 at Apache.NMS.Stomp.Connection.Start() in c:\Users\fretje\Documents\Visual St udio 2012\Projects\win.Tapi2Stomp\Apache.NMS.Stomp-1.5.3-src\src\main\csharp\Con nection.cs:line 319 at Tapi2StompClient.ActiveMQClient..ctor(String uri, String destinationQueue) in c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Tapi2St ompClient\ActiveMQClient.cs:line 33 Apparently the problem is with the parsing of the version of the incoming CONNECTED frame, there the following code is executed: remoteWireFormatInfo.Version =
[jira] [Commented] (AMQNET-411) NMS.Stomp: System.FormatException in the Inactivity Monitor on Windows 8 with a non US (European) Current Culture
[ https://issues.apache.org/jira/browse/AMQNET-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658751#comment-13658751 ] Timothy Bish commented on AMQNET-411: - Also applied on 1.5.x fixes branch if you want to build from there. NMS.Stomp: System.FormatException in the Inactivity Monitor on Windows 8 with a non US (European) Current Culture - Key: AMQNET-411 URL: https://issues.apache.org/jira/browse/AMQNET-411 Project: ActiveMQ .Net Issue Type: Bug Components: NMS, Stomp Affects Versions: 1.5.3 Environment: Windows 8, .NET Framework 2.0, ActiveMQ 5.6 with STOMP Reporter: Frederiek Lefebvre Assignee: Timothy Bish Fix For: 1.6.0 I have a Windows 8 PC where the Current Culture is set to nl-BE. I'm communicating with an ActiveMQ 5.6 Server using STOMP. When I issue a connection.Start(), I get a ConnectionClosedException The connection is already closed!. When I enable tracing, I get another exception before that: Debug: Exception received in the Inactivity Monitor: System.FormatException: Inp ut string was not in a correct format. at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffe r number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseSingle(String value, NumberStyles options, NumberFormat Info numfmt) at System.Single.Parse(String s, NumberStyles style, NumberFormatInfo info) at System.Single.Parse(String s) at Apache.NMS.Stomp.Protocol.StompWireFormat.ReadConnected(StompFrame frame) in c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.N MS.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 200 at Apache.NMS.Stomp.Protocol.StompWireFormat.CreateCommand(StompFrame frame) in c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.N MS.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 154 at Apache.NMS.Stomp.Protocol.StompWireFormat.Unmarshal(BinaryReader dataIn) i n c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.NM S.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 124 at Apache.NMS.Stomp.Transport.Tcp.TcpTransport.ReadLoop() in c:\Users\fretje\ Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.NMS.Stomp-1.5.3-src\ src\main\csharp\Transport\Tcp\TcpTransport.cs:line 285 Debug: Async exception with no exception listener: System.FormatException: Input string was not in a correct format. at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffe r number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseSingle(String value, NumberStyles options, NumberFormat Info numfmt) at System.Single.Parse(String s, NumberStyles style, NumberFormatInfo info) at System.Single.Parse(String s) at Apache.NMS.Stomp.Protocol.StompWireFormat.ReadConnected(StompFrame frame) in c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.N MS.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 200 at Apache.NMS.Stomp.Protocol.StompWireFormat.CreateCommand(StompFrame frame) in c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.N MS.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 154 at Apache.NMS.Stomp.Protocol.StompWireFormat.Unmarshal(BinaryReader dataIn) i n c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.NM S.Stomp-1.5.3-src\src\main\csharp\Protocol\StompWireFormat.cs:line 124 at Apache.NMS.Stomp.Transport.Tcp.TcpTransport.ReadLoop() in c:\Users\fretje\ Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.NMS.Stomp-1.5.3-src\ src\main\csharp\Transport\Tcp\TcpTransport.cs:line 285 Apache.NMS.Stomp.ConnectionClosedException: The connection is already closed! at Apache.NMS.Stomp.Connection.CheckConnected() in c:\Users\fretje\Documents\ Visual Studio 2012\Projects\win.Tapi2Stomp\Apache.NMS.Stomp-1.5.3-src\src\main\c sharp\Connection.cs:line 609 at Apache.NMS.Stomp.Connection.Start() in c:\Users\fretje\Documents\Visual St udio 2012\Projects\win.Tapi2Stomp\Apache.NMS.Stomp-1.5.3-src\src\main\csharp\Con nection.cs:line 319 at Tapi2StompClient.ActiveMQClient..ctor(String uri, String destinationQueue) in c:\Users\fretje\Documents\Visual Studio 2012\Projects\win.Tapi2Stomp\Tapi2St ompClient\ActiveMQClient.cs:line 33 Apparently the problem is with the parsing of the version of the incoming CONNECTED frame, there the following code is executed: remoteWireFormatInfo.Version =
[jira] [Updated] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated AMQNET-413:
Priority: Major (was: Critical)
Message producers do not respect DTC Transactions correctly
---
Key: AMQNET-413
URL: https://issues.apache.org/jira/browse/AMQNET-413
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Remo Gloor
Assignee: Jim Gomes
Attachments: allDTCImprovments.patch,
AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
AMQNET-413.patch
When consuming messages in a transaction and sending new ones during
processing of that message and the transaction is rolled back and commited on
retry the number of published messages should be equal to the received one.
But the number of sent message is bigger than the number of received ones.
This means some of the message sends are not rolled back others are.
EDIT: Further analysis have shown that the TransactionContext.TransactionId
is null when sending eventhough a transaction is in progress and not yet
completed. It must incorrectly be assigned to null somewhere.
The following application demonstrates the problem when enqueuing 100+
messages to foo.bar
class Program
{
private static INetTxSession activeMqSession;
private static IMessageConsumer consumer;
private static INetTxConnection connection;
static void Main(string[] args)
{
using (connection = CreateActiveMqConnection())
using (activeMqSession = connection.CreateNetTxSession())
using (consumer =
activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
queue://foo.bar)))
{
connection.Start();
while (true)
{
try
{
using (TransactionScope scoped = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
IMessage msg = null;
while (msg == null)
{
msg = consumer.ReceiveNoWait();
}
OnMessage(msg);
scoped.Complete();
}
}
catch(Exception exception) {}
}
}
}
private static INetTxConnection CreateActiveMqConnection()
{
var connectionFactory = new
Apache.NMS.ActiveMQ.NetTxConnectionFactory(activemq:tcp://localhost:61616)
{
AcknowledgementMode = AcknowledgementMode.Transactional
};
return connectionFactory.CreateNetTxConnection();
}
private static void OnMessage(IMessage message)
{
var x = new TestSinglePhaseCommit();
Console.WriteLine(Processing message {0} in transaction {1} -
{2}, message.NMSMessageId,
Transaction.Current.TransactionInformation.LocalIdentifier,
Transaction.Current.TransactionInformation.DistributedIdentifier);
var session2 = activeMqSession;
{
Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
EnlistmentOptions.None);
using (var producer =
session2.CreateProducer(SessionUtil.GetQueue(session2, queue://foo.baz)))
{
producer.Send(new ActiveMQTextMessage(foo));
}
if (!message.NMSRedelivered) throw new Exception();
}
}
}
internal class TestSinglePhaseCommit : ISinglePhaseNotification
{
public void Prepare(PreparingEnlistment preparingEnlistment)
{
preparingEnlistment.Prepared();
}
public void Commit(Enlistment enlistment)
{
enlistment.Done();
}
public void Rollback(Enlistment enlistment)
{
enlistment.Done();
}
public void InDoubt(Enlistment enlistment)
{
enlistment.Done();
}
public void SinglePhaseCommit(SinglePhaseEnlistment
singlePhaseEnlistment)
{
singlePhaseEnlistment.Committed();
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4413) Persistent message loss when JMS durable subscriber reconnects regardless of message store impl.
[ https://issues.apache.org/jira/browse/AMQ-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658768#comment-13658768 ] Jaewoong Choi commented on AMQ-4413: Have you ever reproduced this with persistence enabled using this test case? Yes. I observed the bug with persistence enabled first, then tried reproduced with persistence disabled (which uses memory-based persistent adapter) which means the trouble is unrelated to any specific message store implementation. Persistent message loss when JMS durable subscriber reconnects regardless of message store impl. Key: AMQ-4413 URL: https://issues.apache.org/jira/browse/AMQ-4413 Project: ActiveMQ Issue Type: Bug Components: Broker, JMS client, Message Store Affects Versions: 5.7.0, 5.8.0 Reporter: Jaewoong Choi Priority: Critical Attachments: AMQ4413-testcase.patch, AMQ4413Test.java, AMQ4413Test.java, Test.java Persistent message is lost intermittently when JMS durable topic subscriber reconnects to the broker service. From the log observation, it seems that the internal states of the store cursor (i.e. AbstractStoreCursor) is not well guarded by race condition between message sending/directly-dispatching-pending thread (from publisher) and subscription deactivating thread (from subscriber's closing), especially when subscriber's closing (javax.jms.MessageConsumer#close) and message publishing happen simultaneously. Observations and the test scenario are described at below in detail: http://activemq.2283324.n4.nabble.com/persistent-message-missing-to-a-durable-subscriber-when-it-reconnects-restarts-td4665130.html Attached please find Test.java that I used to verify this issue. I found the issue initially with activemq-core-5.7.0.jar then confirmed that it's reproducible with other upper versions (i.e. apache-activemq-5.8-SNAPSHOT, apache-activemq-5.9-SNAPSHOT). This message loss issue is pretty critical as it can happen whenever durable subscriber reconnects either purposely or unexpectedly, and it could be violating the one of primitive features that messaging platform guarantees: no message loss, if happens, whereas it's so easy to reproduce the trouble. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4413) Persistent message loss when JMS durable subscriber reconnects regardless of message store impl.
[ https://issues.apache.org/jira/browse/AMQ-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658777#comment-13658777 ] Timothy Bish commented on AMQ-4413: --- If you can provide a test that reproduces with a store it would be more useful. Persistent message loss when JMS durable subscriber reconnects regardless of message store impl. Key: AMQ-4413 URL: https://issues.apache.org/jira/browse/AMQ-4413 Project: ActiveMQ Issue Type: Bug Components: Broker, JMS client, Message Store Affects Versions: 5.7.0, 5.8.0 Reporter: Jaewoong Choi Priority: Critical Attachments: AMQ4413-testcase.patch, AMQ4413Test.java, AMQ4413Test.java, Test.java Persistent message is lost intermittently when JMS durable topic subscriber reconnects to the broker service. From the log observation, it seems that the internal states of the store cursor (i.e. AbstractStoreCursor) is not well guarded by race condition between message sending/directly-dispatching-pending thread (from publisher) and subscription deactivating thread (from subscriber's closing), especially when subscriber's closing (javax.jms.MessageConsumer#close) and message publishing happen simultaneously. Observations and the test scenario are described at below in detail: http://activemq.2283324.n4.nabble.com/persistent-message-missing-to-a-durable-subscriber-when-it-reconnects-restarts-td4665130.html Attached please find Test.java that I used to verify this issue. I found the issue initially with activemq-core-5.7.0.jar then confirmed that it's reproducible with other upper versions (i.e. apache-activemq-5.8-SNAPSHOT, apache-activemq-5.9-SNAPSHOT). This message loss issue is pretty critical as it can happen whenever durable subscriber reconnects either purposely or unexpectedly, and it could be violating the one of primitive features that messaging platform guarantees: no message loss, if happens, whereas it's so easy to reproduce the trouble. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4413) Persistent message loss when JMS durable subscriber reconnects regardless of message store impl.
[ https://issues.apache.org/jira/browse/AMQ-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658802#comment-13658802 ] Jaewoong Choi commented on AMQ-4413: Unfortunately it's not possible because the persistence adapter/store I tested with is a custom one outside the AMQ code base. FYI, it's Apache BookKeeper-based and can't be shared outside my company, yet. The reason I tested with persistence option disabled is because of this reason: I needed to verify it's persistence-store independent problem. Persistent message loss when JMS durable subscriber reconnects regardless of message store impl. Key: AMQ-4413 URL: https://issues.apache.org/jira/browse/AMQ-4413 Project: ActiveMQ Issue Type: Bug Components: Broker, JMS client, Message Store Affects Versions: 5.7.0, 5.8.0 Reporter: Jaewoong Choi Priority: Critical Attachments: AMQ4413-testcase.patch, AMQ4413Test.java, AMQ4413Test.java, Test.java Persistent message is lost intermittently when JMS durable topic subscriber reconnects to the broker service. From the log observation, it seems that the internal states of the store cursor (i.e. AbstractStoreCursor) is not well guarded by race condition between message sending/directly-dispatching-pending thread (from publisher) and subscription deactivating thread (from subscriber's closing), especially when subscriber's closing (javax.jms.MessageConsumer#close) and message publishing happen simultaneously. Observations and the test scenario are described at below in detail: http://activemq.2283324.n4.nabble.com/persistent-message-missing-to-a-durable-subscriber-when-it-reconnects-restarts-td4665130.html Attached please find Test.java that I used to verify this issue. I found the issue initially with activemq-core-5.7.0.jar then confirmed that it's reproducible with other upper versions (i.e. apache-activemq-5.8-SNAPSHOT, apache-activemq-5.9-SNAPSHOT). This message loss issue is pretty critical as it can happen whenever durable subscriber reconnects either purposely or unexpectedly, and it could be violating the one of primitive features that messaging platform guarantees: no message loss, if happens, whereas it's so easy to reproduce the trouble. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4413) Persistent message loss when JMS durable subscriber reconnects regardless of message store impl.
[ https://issues.apache.org/jira/browse/AMQ-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658834#comment-13658834 ] Timothy Bish commented on AMQ-4413: --- Ok. I know why its happening and we are trying out a fix. Have to ensure we don't break any other use cases though. Persistent message loss when JMS durable subscriber reconnects regardless of message store impl. Key: AMQ-4413 URL: https://issues.apache.org/jira/browse/AMQ-4413 Project: ActiveMQ Issue Type: Bug Components: Broker, JMS client, Message Store Affects Versions: 5.7.0, 5.8.0 Reporter: Jaewoong Choi Priority: Critical Attachments: AMQ4413-testcase.patch, AMQ4413Test.java, AMQ4413Test.java, Test.java Persistent message is lost intermittently when JMS durable topic subscriber reconnects to the broker service. From the log observation, it seems that the internal states of the store cursor (i.e. AbstractStoreCursor) is not well guarded by race condition between message sending/directly-dispatching-pending thread (from publisher) and subscription deactivating thread (from subscriber's closing), especially when subscriber's closing (javax.jms.MessageConsumer#close) and message publishing happen simultaneously. Observations and the test scenario are described at below in detail: http://activemq.2283324.n4.nabble.com/persistent-message-missing-to-a-durable-subscriber-when-it-reconnects-restarts-td4665130.html Attached please find Test.java that I used to verify this issue. I found the issue initially with activemq-core-5.7.0.jar then confirmed that it's reproducible with other upper versions (i.e. apache-activemq-5.8-SNAPSHOT, apache-activemq-5.9-SNAPSHOT). This message loss issue is pretty critical as it can happen whenever durable subscriber reconnects either purposely or unexpectedly, and it could be violating the one of primitive features that messaging platform guarantees: no message loss, if happens, whereas it's so easy to reproduce the trouble. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4413) Persistent message loss when JMS durable subscriber reconnects regardless of message store impl.
[ https://issues.apache.org/jira/browse/AMQ-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-4413. --- Resolution: Fixed Fix Version/s: 5.9.0 Assignee: Timothy Bish Fixed on trunk, to workaround the issue you can set keepDurableSubsActive to false and you shouldn't see this. Persistent message loss when JMS durable subscriber reconnects regardless of message store impl. Key: AMQ-4413 URL: https://issues.apache.org/jira/browse/AMQ-4413 Project: ActiveMQ Issue Type: Bug Components: Broker, JMS client, Message Store Affects Versions: 5.7.0, 5.8.0 Reporter: Jaewoong Choi Assignee: Timothy Bish Priority: Critical Fix For: 5.9.0 Attachments: AMQ4413-testcase.patch, AMQ4413Test.java, AMQ4413Test.java, Test.java Persistent message is lost intermittently when JMS durable topic subscriber reconnects to the broker service. From the log observation, it seems that the internal states of the store cursor (i.e. AbstractStoreCursor) is not well guarded by race condition between message sending/directly-dispatching-pending thread (from publisher) and subscription deactivating thread (from subscriber's closing), especially when subscriber's closing (javax.jms.MessageConsumer#close) and message publishing happen simultaneously. Observations and the test scenario are described at below in detail: http://activemq.2283324.n4.nabble.com/persistent-message-missing-to-a-durable-subscriber-when-it-reconnects-restarts-td4665130.html Attached please find Test.java that I used to verify this issue. I found the issue initially with activemq-core-5.7.0.jar then confirmed that it's reproducible with other upper versions (i.e. apache-activemq-5.8-SNAPSHOT, apache-activemq-5.9-SNAPSHOT). This message loss issue is pretty critical as it can happen whenever durable subscriber reconnects either purposely or unexpectedly, and it could be violating the one of primitive features that messaging platform guarantees: no message loss, if happens, whereas it's so easy to reproduce the trouble. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4413) Persistent message loss when JMS durable subscriber reconnects regardless of message store impl.
[ https://issues.apache.org/jira/browse/AMQ-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658994#comment-13658994 ] Jaewoong Choi commented on AMQ-4413: Thanks for the fix. Any impact to the persistence message consumption of durable subscribers by turning keepDurableSubsActive option off? Persistent message loss when JMS durable subscriber reconnects regardless of message store impl. Key: AMQ-4413 URL: https://issues.apache.org/jira/browse/AMQ-4413 Project: ActiveMQ Issue Type: Bug Components: Broker, JMS client, Message Store Affects Versions: 5.7.0, 5.8.0 Reporter: Jaewoong Choi Assignee: Timothy Bish Priority: Critical Fix For: 5.9.0 Attachments: AMQ4413-testcase.patch, AMQ4413Test.java, AMQ4413Test.java, Test.java Persistent message is lost intermittently when JMS durable topic subscriber reconnects to the broker service. From the log observation, it seems that the internal states of the store cursor (i.e. AbstractStoreCursor) is not well guarded by race condition between message sending/directly-dispatching-pending thread (from publisher) and subscription deactivating thread (from subscriber's closing), especially when subscriber's closing (javax.jms.MessageConsumer#close) and message publishing happen simultaneously. Observations and the test scenario are described at below in detail: http://activemq.2283324.n4.nabble.com/persistent-message-missing-to-a-durable-subscriber-when-it-reconnects-restarts-td4665130.html Attached please find Test.java that I used to verify this issue. I found the issue initially with activemq-core-5.7.0.jar then confirmed that it's reproducible with other upper versions (i.e. apache-activemq-5.8-SNAPSHOT, apache-activemq-5.9-SNAPSHOT). This message loss issue is pretty critical as it can happen whenever durable subscriber reconnects either purposely or unexpectedly, and it could be violating the one of primitive features that messaging platform guarantees: no message loss, if happens, whereas it's so easy to reproduce the trouble. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
