Build failed in Jenkins: ActiveMQ-Trunk-Deploy #875

[Apache Jenkins Server]

See 

Changes:

[gtully] remove unneeded deps that pull in older amq versions

[hiram] Add a toString() method to the replicated leveldb store so that it 
displays a nicer message when the broker starts it up.

[hiram] https://issues.apache.org/jira/browse/AMQ-4471 - Fixing bug where stomp 
ws example allows remote JS execution.

[hiram] Fixes https://issues.apache.org/jira/browse/AMQ-4840 - Invalid STOMP 
frame sent on websocket connections with heartbeats.

[hiram] Makes it easier to launch activemq from an IDE in debug mode.

[hiram] Only register the leveldb store MBeans in JMX if jmx is enabled on the 
broker.

[hiram] Working on a test case for 
https://issues.apache.org/jira/browse/AMQ-4837 : LevelDB corrupted in AMQ 
cluster.

--
[...truncated 13840 lines...]
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/deployer/org.apache.karaf.deployer.blueprint/2.3.3/org.apache.karaf.deployer.blueprint-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/deployer/org.apache.karaf.deployer.features/2.3.3/org.apache.karaf.deployer.features-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/deployer/org.apache.karaf.deployer.kar/2.3.3/org.apache.karaf.deployer.kar-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/deployer/org.apache.karaf.deployer.wrap/2.3.3/org.apache.karaf.deployer.wrap-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/features/org.apache.karaf.features.core/2.3.3/org.apache.karaf.features.core-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/features/org.apache.karaf.features.command/2.3.3/org.apache.karaf.features.command-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/features/org.apache.karaf.features.management/2.3.3/org.apache.karaf.features.management-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/features/org.apache.karaf.features.obr/2.3.3/org.apache.karaf.features.obr-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/diagnostic/org.apache.karaf.diagnostic.core/2.3.3/org.apache.karaf.diagnostic.core-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/diagnostic/org.apache.karaf.diagnostic.common/2.3.3/org.apache.karaf.diagnostic.common-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/diagnostic/org.apache.karaf.diagnostic.command/2.3.3/org.apache.karaf.diagnostic.command-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/diagnostic/org.apache.karaf.diagnostic.management/2.3.3/org.apache.karaf.diagnostic.management-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/admin/org.apache.karaf.admin.core/2.3.3/org.apache.karaf.admin.core-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/admin/org.apache.karaf.admin.command/2.3.3/org.apache.karaf.admin.command-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/admin/org.apache.karaf.admin.management/2.3.3/org.apache.karaf.admin.management-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/shell/org.apache.karaf.shell.obr/2.3.3/org.apache.karaf.shell.obr-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/shell/org.apache.karaf.shell.osgi/2.3.3/org.apache.karaf.shell.osgi-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/shell/org.apache.karaf.shell.log/2.3.3/org.apache.karaf.shell.log-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/shell/org.apache.karaf.shell.config/2.3.3/org.apache.karaf.shell.config-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/shell/org.apache.karaf.shell.packages/2.3.3/org.apache.karaf.shell.packages-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/shell/org.apache.karaf.shell.commands/2.3.3/org.apache.karaf.shell.commands-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/shell/org.apache.karaf.shell.ssh/2.3.3/org.apache.karaf.shell.ssh-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/jaas/org.apache.karaf.jaas.command/2.3.3/org.apache.karaf.jaas.command-2.3.3.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/apache/karaf/management/org.apache.karaf.managemen

[jira] [Commented] (AMQ-4354) Persist JMX statistics so they survive a restart

[Matt Pavlovich (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809941#comment-13809941
 ] 

Matt Pavlovich commented on AMQ-4354:
-

Consistency definitely gets over a big hurdle, but I think we still have a 
problem of how to show lifetime metrics through the system.  

Broker enqueues 500 messages.. dequeues 250.. >> restart <<.. broker comes back 
up and shows 250 messages enqueued. Monitoring tools will only be able to 
provide "as-is", instead of absolute values. The total message traffic numbers 
driving things like capacity planning over time. If the thought process would 
be to move that tracking to the monitoring tools, that'd work, but we'd need a 
way to readAndReset() statistics in a somewhat atomic way to preserve correct 
values.

Thoughts?

> Persist JMX statistics so they survive a restart
> 
>
> Key: AMQ-4354
> URL: https://issues.apache.org/jira/browse/AMQ-4354
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: JMX
>Affects Versions: 5.8.0
> Environment: All
>Reporter: Matt Pavlovich
>
> It would be really handy if JMX statistics survived a restart. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Build failed in Jenkins: ActiveMQ #1405

[Apache Jenkins Server]

See 

Changes:

[gtully] remove unneeded deps that pull in older amq versions

[hiram] Add a toString() method to the replicated leveldb store so that it 
displays a nicer message when the broker starts it up.

[hiram] https://issues.apache.org/jira/browse/AMQ-4471 - Fixing bug where stomp 
ws example allows remote JS execution.

[hiram] Fixes https://issues.apache.org/jira/browse/AMQ-4840 - Invalid STOMP 
frame sent on websocket connections with heartbeats.

[hiram] Makes it easier to launch activemq from an IDE in debug mode.

[hiram] Only register the leveldb store MBeans in JMX if jmx is enabled on the 
broker.

[hiram] Working on a test case for 
https://issues.apache.org/jira/browse/AMQ-4837 : LevelDB corrupted in AMQ 
cluster.

--
[...truncated 2307 lines...]
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at 
org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:117)
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.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:178)
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 hudson.maven.Maven3Builder.call(Maven3Builder.java:130)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:67)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.xmlpull.v1.XmlPullParserException: unexpected type 
(position:END_DOCUMENT null@3:1 in java.io.InputStreamReader@5d471e) 
at org.kxml2.io.KXmlParser.exception(Unknown Source)
at org.kxml2.io.KXmlParser.nextTag(Unknown Source)
at 
org.apache.felix.bundlerepository.impl.PullParser.parseRepository(PullParser.java:43)
at 
org.apache.felix.bundlerepository.impl.DataModelHelperImpl.repository(DataModelHelperImpl.java:147)
at 
org.apache.felix.bundlerepository.impl.DataModelHelperImpl.repository(DataModelHelperImpl.java:118)
at 
org.apache.felix.obrplugin.ObrUpdate.parseRepositoryXml(ObrUpdate.java:316)
... 34 more
[05:05:43] Oct 31, 2013 5:05:43 AM 
org.apache.maven.cli.event.ExecutionEventLogger projectSkipped
INFO: 
Oct 31, 2013 5:05:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: 
Oct 31, 2013 5:05:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: Skipping ActiveMQ :: Web Demo
Oct 31, 2013 5:05:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: This project has been banned from the build due to previous failures.
Oct 31, 2013 5:05:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: 
Oct 31, 2013 5:05:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: 
Oct 31, 2013 5:05:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: 
Oct 31, 2013 5:05:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: Skipping ActiveMQ :: Web Console
Oct 31, 2013 5:05:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: This project has been banned from the build due to previous failures.
Oct 31, 2013 5:05:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectSkipped
INFO: ---

Build failed in Jenkins: ActiveMQ » ActiveMQ :: STOMP Protocol #1405

[Apache Jenkins Server]

See 


Changes:

[hiram] Fixes https://issues.apache.org/jira/browse/AMQ-4840 - Invalid STOMP 
frame sent on websocket connections with heartbeats.

--
[03:50:30] Oct 31, 2013 3:50:37 AM 
org.apache.maven.cli.event.ExecutionEventLogger projectStarted
INFO: 
Oct 31, 2013 3:50:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 31, 2013 3:50:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: Building ActiveMQ :: STOMP Protocol 5.10-SNAPSHOT
Oct 31, 2013 3:50:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 31, 2013 3:50:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 3:50:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-stomp ---
[INFO] Deleting 

Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-stomp ---
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-consolets-plugin:1.30:install (default) @ activemq-stomp ---
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-stomp ---
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-remote-resources-plugin:1.3:process (default) @ activemq-stomp 
---
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-stomp ---
[03:50:38] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 14 resources
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 3:50:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-stomp ---
[INFO] Compiling 24 source files to 

Oct 31, 2013 3:50:39 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 3:50:39 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
activemq-stomp ---
[03:50:39] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 6 resources
[INFO] Copying 3 resources
Oct 31, 2013 3:50:39 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 3:50:39 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
activemq-stomp ---
[INFO] Compiling 30 source files to 

Oct 31, 2013 3:50:39 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 3:50:39 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-surefire-plugin:2.10:test (default-test) @ activemq-stomp ---
[INFO] Surefire report directory: 

[03:50:39] 
[03:50:39] ---
[03:50:39]  T E S T S
[03:50:39] ---
[03:50:39] 
[03:50:39] ---
[03:50:39]  T E S T S
[03:50:39] ---
[03:50:40] Running org.apache.activemq.transport.stomp.ConnectTest
[03:51:15] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
35

Build failed in Jenkins: ActiveMQ » ActiveMQ :: MQTT Protocol #1405

[Apache Jenkins Server]

See 


--
[04:39:33] Oct 31, 2013 4:39:40 AM 
org.apache.maven.cli.event.ExecutionEventLogger projectStarted
INFO: 
Oct 31, 2013 4:39:40 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 31, 2013 4:39:40 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: Building ActiveMQ :: MQTT Protocol 5.10-SNAPSHOT
Oct 31, 2013 4:39:40 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 31, 2013 4:39:40 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:40 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-mqtt ---
[INFO] Deleting 

Oct 31, 2013 4:39:41 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:41 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-mqtt ---
Oct 31, 2013 4:39:41 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:41 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-consolets-plugin:1.30:install (default) @ activemq-mqtt ---
Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-mqtt ---
Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- activemq-protobuf:1.1:compile (default) @ activemq-mqtt ---
[WARNING] No proto files found in directory: 

Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-remote-resources-plugin:1.3:process (default) @ activemq-mqtt 
---
Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-mqtt ---
[04:39:42] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-compiler-plugin:2.5.1:compile (default-compile) @ activemq-mqtt 
---
[INFO] Compiling 16 source files to 

Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:42 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
activemq-mqtt ---
[04:39:42] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources
Oct 31, 2013 4:39:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
activemq-mqtt ---
[INFO] Compiling 6 source files to 

Oct 31, 2013 4:39:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:39:43 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-surefire-plugin:2.10:test (default-test) @ activemq-mqtt ---
[INFO] Surefire report directory: 

[04:39:43] 
[04:39:43] ---
[04:39:43]  T E S T S
[04:39:43] ---
[04:39:43] 
[04:39:43] ---
[04:39:43]  T E 

Build failed in Jenkins: ActiveMQ » ActiveMQ :: LevelDB Store #1405

[Apache Jenkins Server]

See 


Changes:

[hiram] Add a toString() method to the replicated leveldb store so that it 
displays a nicer message when the broker starts it up.

[hiram] Only register the leveldb store MBeans in JMX if jmx is enabled on the 
broker.

[hiram] Working on a test case for 
https://issues.apache.org/jira/browse/AMQ-4837 : LevelDB corrupted in AMQ 
cluster.

--
[04:48:17] Oct 31, 2013 4:48:26 AM 
org.apache.maven.cli.event.ExecutionEventLogger projectStarted
INFO: 
Oct 31, 2013 4:48:26 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 31, 2013 4:48:26 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: Building ActiveMQ :: LevelDB Store 5.10-SNAPSHOT
Oct 31, 2013 4:48:26 AM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/fusesource/hawtdispatch/hawtdispatch-scala/1.18/hawtdispatch-scala-1.18.pom
Downloaded: 
http://repo.fusesource.com/nexus/content/groups/public/org/fusesource/hawtdispatch/hawtdispatch-scala/1.18/hawtdispatch-scala-1.18.pom
 (7 KB at 9.5 KB/sec)
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/xerial/snappy/snappy-java/1.1.0-M4/snappy-java-1.1.0-M4.pom
Downloading: 
http://repo.maven.apache.org/maven2/org/xerial/snappy/snappy-java/1.1.0-M4/snappy-java-1.1.0-M4.pom
Downloaded: 
http://repo.maven.apache.org/maven2/org/xerial/snappy/snappy-java/1.1.0-M4/snappy-java-1.1.0-M4.pom
 (13 KB at 487.1 KB/sec)
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/fusesource/hawtdispatch/hawtdispatch-scala/1.18/hawtdispatch-scala-1.18.jar
Downloading: 
http://repo.fusesource.com/nexus/content/groups/public/org/xerial/snappy/snappy-java/1.1.0-M4/snappy-java-1.1.0-M4.jar
Downloaded: 
http://repo.fusesource.com/nexus/content/groups/public/org/fusesource/hawtdispatch/hawtdispatch-scala/1.18/hawtdispatch-scala-1.18.jar
 (135 KB at 80.5 KB/sec)
Downloading: 
http://repo.maven.apache.org/maven2/org/xerial/snappy/snappy-java/1.1.0-M4/snappy-java-1.1.0-M4.jar
Downloaded: 
http://repo.maven.apache.org/maven2/org/xerial/snappy/snappy-java/1.1.0-M4/snappy-java-1.1.0-M4.jar
 (514 KB at 11945.7 KB/sec)
Oct 31, 2013 4:48:34 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:48:34 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-leveldb-store 
---
[INFO] Deleting 

Oct 31, 2013 4:48:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:48:36 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-enforcer-plugin:1.0.1:enforce (default) @ 
activemq-leveldb-store ---
Oct 31, 2013 4:48:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:48:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-consolets-plugin:1.30:install (default) @ 
activemq-leveldb-store ---
Oct 31, 2013 4:48:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:48:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-leveldb-store ---
Oct 31, 2013 4:48:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:48:37 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- hawtbuf-protoc:1.9:compile (default) @ activemq-leveldb-store ---
[INFO] Compiling: 

Oct 31, 2013 4:48:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:48:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-remote-resources-plugin:1.3:process (default) @ 
activemq-leveldb-store ---
Oct 31, 2013 4:48:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 31, 2013 4:48:38 AM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-leveldb-store ---
[04:48:38] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
Oct 31, 2013 4:48:38 AM org.apache.maven.cli.event.Ex

Jenkins build is back to normal : ActiveMQ » ActiveMQ :: RA #1405

[Apache Jenkins Server]

See 

[jira] [Updated] (AMQ-4832) Broker limits store space, not taking into account what it's already using

[Matthew Walker (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthew Walker updated AMQ-4832:


Attachment: 0001-Store-limit-check-current-usage-and-disk-free-space.patch

Patch sets the limit of the store to the sum of the usage and the free space.

> Broker limits store space, not taking into account what it's already using
> --
>
> Key: AMQ-4832
> URL: https://issues.apache.org/jira/browse/AMQ-4832
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.9.0
>Reporter: Matthew Walker
> Fix For: 5.10.0
>
> Attachments: 
> 0001-Store-limit-check-current-usage-and-disk-free-space.patch
>
>
> https://issues.apache.org/jira/browse/AMQ-4638 sets the usage limit of a 
> store to only the available disk space. It does not take into account that 
> the store itself is using space on the disk.
> In our environment the store was taking 30 GB of space and there was 17 GB 
> free on disk. Therefore, on startup the store was limited to 17 GB; where it 
> should have been limited to 47 GB. Because of this, by design, no new message 
> can be added to the queue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Dummy/unwanted queues created

[CodeCruiser]

Hi chirino,
Thanks for the reply. That is the route I am going to take. As a workaround,
removed the kahadb folder which deleted all queues and allowed ActiveMQ to
breathe again. But long term solution is to prohibit the creation of queues
automatically as we don't need that feature.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Dummy-unwanted-queues-created-tp4673208p4673533.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster

[Hiram Chirino (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809446#comment-13809446
 ] 

Hiram Chirino commented on AMQ-4837:


Ok. thx. I was able to reproduce.. looking into the root cause now.

> LevelDB corrupted in AMQ cluster
> 
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper. 
> When performing some tests using Web UI, I can across issues that appears to 
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web 
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the 
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message 
> summary ok however when clicking on the queue, no message details. An error 
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error 
> occurs to each node infinitely (shutdown/restart). The only way around is to 
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t 
> occur.
> =
> Leveldb configuration on the 3 instances:
>   
>  directory="${activemq.data}/leveldb"
>   replicas="3"
>   bind="tcp://0.0.0.0:0"
>   zkAddress="zkserver:2181"
>   zkPath="/activemq/leveldb-stores"
>   />
>   
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at 
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at 
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at 
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at 
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at 
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at 
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at 
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at 
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at 
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
> at 
> org.apache.activemq.leveldb.LevelDBCli

Re: Dummy/unwanted queues created

[Hiram Chirino]

You could use activemq's security feature to only allow the expected
application queues to get created.  For more info see:
http://activemq.apache.org/security.html

The other users that are creating those unknown queues will get error
when they try to create/use them.

On Thu, Oct 24, 2013 at 11:56 AM, CodeCruiser
 wrote:
> Hi,
> On our installation of ActiveMQ, there are a lot (1000s) of queues created
> which are not being used and we have no idea why these get recreated after a
> restarted as well. These are named like
>
> .FOO.portal.diag.index.jsp191586.swp
>
> and
>
> FOO.non-existant-1479944305
>
> This results in ActiveMQ throwing out of memory exceptions and not accepting
> any consumer connections.
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Dummy-unwanted-queues-created-tp4673208.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



-- 
Hiram Chirino

Engineering | Red Hat, Inc.

hchir...@redhat.com | fusesource.com | redhat.com

skype: hiramchirino | twitter: @hiramchirino

blog: Hiram Chirino's Bit Mojo

[jira] [Updated] (AMQ-4840) Invalid STOMP frame sent on websocket connections with heartbeats.

[Hiram Chirino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hiram Chirino updated AMQ-4840:
---

Description: a KEEPALIVE frame was being sent by ActiveMQ to stomp 
websocket clients that enabled heartbeats. 

> Invalid STOMP frame sent on websocket connections with heartbeats.
> --
>
> Key: AMQ-4840
> URL: https://issues.apache.org/jira/browse/AMQ-4840
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.9.0
>Reporter: Hiram Chirino
>Assignee: Hiram Chirino
>
> a KEEPALIVE frame was being sent by ActiveMQ to stomp websocket clients that 
> enabled heartbeats. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (AMQ-4840) Invalid STOMP frame sent on websocket connections with heartbeats.

[Hiram Chirino (JIRA)]

Hiram Chirino created AMQ-4840:
--

 Summary: Invalid STOMP frame sent on websocket connections with 
heartbeats.
 Key: AMQ-4840
 URL: https://issues.apache.org/jira/browse/AMQ-4840
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.9.0
Reporter: Hiram Chirino
Assignee: Hiram Chirino






--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster

[Guillaume (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809398#comment-13809398
 ] 

Guillaume commented on AMQ-4837:


Hi Hiram,
I was using the activemq web console to send messages (destination: default 
foo.bar, default content and Persistent option ticked), to view the queue 
summary and to display the list of messages.
I have performed a couple of tests using the swissarmy example. I cannot 
reproduce the issue with 10 messages. However I managed to reproduce the 
problem when sending 1 message at the time (other parameter similar to yours). 
I am using the default activemq UI to view the queue summary and looking the 
queue content - which triggers the error at step 7.


> LevelDB corrupted in AMQ cluster
> 
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper. 
> When performing some tests using Web UI, I can across issues that appears to 
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web 
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the 
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message 
> summary ok however when clicking on the queue, no message details. An error 
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error 
> occurs to each node infinitely (shutdown/restart). The only way around is to 
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t 
> occur.
> =
> Leveldb configuration on the 3 instances:
>   
>  directory="${activemq.data}/leveldb"
>   replicas="3"
>   bind="tcp://0.0.0.0:0"
>   zkAddress="zkserver:2181"
>   zkPath="/activemq/leveldb-stores"
>   />
>   
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at 
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at 
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at 
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at 
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at 
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at 
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at 
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at 
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at 
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Threa

[jira] [Commented] (AMQ-4354) Persist JMX statistics so they survive a restart

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809335#comment-13809335
 ] 

Claus Ibsen commented on AMQ-4354:
--

Yes I am with Hiram, I think when the broker startup then its services such as 
the datastores and whatnot, should ensure their JMX stats are "consistent'. eg 
such as in your use-case, then the pending and enqueded would be set to the 
same value. 

And so forth.

Doing a full JMX persistent of state, seems like a general problem and outside 
the scope. 

And maybe doing this better "consistency" check on startup would also prevent 
any of those, why is this counter negative we have had reported in the past.

> Persist JMX statistics so they survive a restart
> 
>
> Key: AMQ-4354
> URL: https://issues.apache.org/jira/browse/AMQ-4354
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: JMX
>Affects Versions: 5.8.0
> Environment: All
>Reporter: Matt Pavlovich
>
> It would be really handy if JMX statistics survived a restart. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"

[Les Hazlewood (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809336#comment-13809336
 ] 

Les Hazlewood commented on AMQ-3621:


Thanks for the update Claus.  I do not use any other 3rd party lib than Apache 
Shiro, and yes, I'm aware of the licensing.

I already have karma for the docs - I wrote the documentation that I linked to 
above - I just need to finish it :)

Thanks!

> Integrate Apache Shiro with ActiveMQ as "security solution"
> ---
>
> Key: AMQ-3621
> URL: https://issues.apache.org/jira/browse/AMQ-3621
> Project: ActiveMQ
>  Issue Type: New Feature
>Reporter: Cservenak, Tamas
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> Integrate Apache Shiro with ActiveMQ as "security solution".
> This would benefit for ActiveMQ to have support for a vast amount of already 
> existing solution (Realm implementations) that are out there for Shiro.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4354) Persist JMX statistics so they survive a restart

[Hiram Chirino (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809334#comment-13809334
 ] 

Hiram Chirino commented on AMQ-4354:


Persisting the stats could have significant performance impact if done naively. 
 

> Persist JMX statistics so they survive a restart
> 
>
> Key: AMQ-4354
> URL: https://issues.apache.org/jira/browse/AMQ-4354
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: JMX
>Affects Versions: 5.8.0
> Environment: All
>Reporter: Matt Pavlovich
>
> It would be really handy if JMX statistics survived a restart. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned AMQ-3621:


Assignee: Claus Ibsen

> Integrate Apache Shiro with ActiveMQ as "security solution"
> ---
>
> Key: AMQ-3621
> URL: https://issues.apache.org/jira/browse/AMQ-3621
> Project: ActiveMQ
>  Issue Type: New Feature
>Reporter: Cservenak, Tamas
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> Integrate Apache Shiro with ActiveMQ as "security solution".
> This would benefit for ActiveMQ to have support for a vast amount of already 
> existing solution (Realm implementations) that are out there for Shiro.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4354) Persist JMX statistics so they survive a restart

[Hiram Chirino (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809333#comment-13809333
 ] 

Hiram Chirino commented on AMQ-4354:


We could also just make the stats more consistent after a restart.  For 
example, make the enqueue count match the queue size on restart.

> Persist JMX statistics so they survive a restart
> 
>
> Key: AMQ-4354
> URL: https://issues.apache.org/jira/browse/AMQ-4354
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: JMX
>Affects Versions: 5.8.0
> Environment: All
>Reporter: Matt Pavlovich
>
> It would be really handy if JMX statistics survived a restart. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-3621:
-

Fix Version/s: 5.10.0

> Integrate Apache Shiro with ActiveMQ as "security solution"
> ---
>
> Key: AMQ-3621
> URL: https://issues.apache.org/jira/browse/AMQ-3621
> Project: ActiveMQ
>  Issue Type: New Feature
>Reporter: Cservenak, Tamas
> Fix For: 5.10.0
>
>
> Integrate Apache Shiro with ActiveMQ as "security solution".
> This would benefit for ActiveMQ to have support for a vast amount of already 
> existing solution (Realm implementations) that are out there for Shiro.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"

[Hiram Chirino (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809331#comment-13809331
 ] 

Hiram Chirino commented on AMQ-3621:


5.9 was just released so, its probably going to be a while before we build up 
enough new features to cut 5.10.

> Integrate Apache Shiro with ActiveMQ as "security solution"
> ---
>
> Key: AMQ-3621
> URL: https://issues.apache.org/jira/browse/AMQ-3621
> Project: ActiveMQ
>  Issue Type: New Feature
>Reporter: Cservenak, Tamas
> Fix For: 5.10.0
>
>
> Integrate Apache Shiro with ActiveMQ as "security solution".
> This would benefit for ActiveMQ to have support for a vast amount of already 
> existing solution (Realm implementations) that are out there for Shiro.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809330#comment-13809330
 ] 

Claus Ibsen commented on AMQ-3621:
--

Sounds great.

Yeah we would love to include this in next minor release, eg 5.10. 

So to do that its a matter of when you think the code at the github repo is 
okay. Then possilbe you can .zip that and attach as file to this JIRA, then you 
do a "code grant" that way.

I assume you do not use any other 3rd party than Apache Shiro? And that you are 
aware of the Apache licesning here
http://www.apache.org/legal/3party.html

For the docs, then I can grant you karma to the AcitveMQ wiki system so you can 
add the documentation.

> Integrate Apache Shiro with ActiveMQ as "security solution"
> ---
>
> Key: AMQ-3621
> URL: https://issues.apache.org/jira/browse/AMQ-3621
> Project: ActiveMQ
>  Issue Type: New Feature
>Reporter: Cservenak, Tamas
>
> Integrate Apache Shiro with ActiveMQ as "security solution".
> This would benefit for ActiveMQ to have support for a vast amount of already 
> existing solution (Realm implementations) that are out there for Shiro.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-3643) vmQueueCursor does not honour system wide memoryUsage limit

[Gary Tully (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809316#comment-13809316
 ] 

Gary Tully commented on AMQ-3643:
-

the whole point of limits is to avoid oom, so this may need some work. I think 
the destination limits may be ignored but the system limits should not be.

> vmQueueCursor does not honour system wide memoryUsage limit
> ---
>
> Key: AMQ-3643
> URL: https://issues.apache.org/jira/browse/AMQ-3643
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.5.1
> Environment: vmQueueCursor
>Reporter: Torsten Mielke
>Priority: Critical
>  Labels: vmQueueCursor
> Fix For: NEEDS_REVIEWED
>
> Attachments: VMQueueCursorBug.tgz
>
>
> The vmQueueCursor isn't bound to configured memoryUsage limit and hence can 
> grow indefinitely and cause OutOfMemoryErrors.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster

[Hiram Chirino (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809313#comment-13809313
 ] 

Hiram Chirino commented on AMQ-4837:


I failed to reproduce using the procedure outlined.  I was testing on 3 Fedora 
Core 18 VMs.

I was pushing messages using the example in: examples/openwire/swissarmy
and running: ant producer 
-Durl='failover:(tcp://demo01:61616,tcp://demo02:61616,tcp://demo03:61616)' 
-Ddurable=true -Dtopic=false -Dmax=10

I was just browsing the queue using the new hawtio web console.  Not really 
drilling into each of the messages.

Guillaume, could you add more details on how you you've been reproducing.  How 
you adding the messages?  Perhaps the number and size of the messages makes a 
difference.


> LevelDB corrupted in AMQ cluster
> 
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper. 
> When performing some tests using Web UI, I can across issues that appears to 
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web 
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the 
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message 
> summary ok however when clicking on the queue, no message details. An error 
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error 
> occurs to each node infinitely (shutdown/restart). The only way around is to 
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t 
> occur.
> =
> Leveldb configuration on the 3 instances:
>   
>  directory="${activemq.data}/leveldb"
>   replicas="3"
>   bind="tcp://0.0.0.0:0"
>   zkAddress="zkserver:2181"
>   zkPath="/activemq/leveldb-stores"
>   />
>   
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at 
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at 
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at 
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at 
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at 
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at 
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at 
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at 
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at 
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.

[jira] [Commented] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"

[Les Hazlewood (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809298#comment-13809298
 ] 

Les Hazlewood commented on AMQ-3621:


Actually, I recant that last statement :)  There are some minor architectural 
changes I want to clean up first before they make it into the ActiveMQ 
repository.  When are you guys releasing 5.10?  I'd like to get it in that 
release if possible.

> Integrate Apache Shiro with ActiveMQ as "security solution"
> ---
>
> Key: AMQ-3621
> URL: https://issues.apache.org/jira/browse/AMQ-3621
> Project: ActiveMQ
>  Issue Type: New Feature
>Reporter: Cservenak, Tamas
>
> Integrate Apache Shiro with ActiveMQ as "security solution".
> This would benefit for ActiveMQ to have support for a vast amount of already 
> existing solution (Realm implementations) that are out there for Shiro.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (AMQ-4837) LevelDB corrupted in AMQ cluster

[Hiram Chirino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hiram Chirino reassigned AMQ-4837:
--

Assignee: Hiram Chirino

Looking into it...

> LevelDB corrupted in AMQ cluster
> 
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper. 
> When performing some tests using Web UI, I can across issues that appears to 
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web 
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the 
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message 
> summary ok however when clicking on the queue, no message details. An error 
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error 
> occurs to each node infinitely (shutdown/restart). The only way around is to 
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t 
> occur.
> =
> Leveldb configuration on the 3 instances:
>   
>  directory="${activemq.data}/leveldb"
>   replicas="3"
>   bind="tcp://0.0.0.0:0"
>   zkAddress="zkserver:2181"
>   zkPath="/activemq/leveldb-stores"
>   />
>   
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at 
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at 
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at 
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at 
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at 
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at 
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at 
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at 
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at 
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBC

[jira] [Commented] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"

[Les Hazlewood (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809296#comment-13809296
 ] 

Les Hazlewood commented on AMQ-3621:


Hi Claus,

The initial implementation is complete and has 100% test coverage for all 
functionality.  The only thing remaining is to finish up the documentation: 
http://activemq.apache.org/shiro.html

How would you guys like to receive the code contribution?  Can we get it in to 
the 5.10 release?

As an Apache PMC Chair, I already have CLAs on file, so everything should be 
clear/ready to go.

> Integrate Apache Shiro with ActiveMQ as "security solution"
> ---
>
> Key: AMQ-3621
> URL: https://issues.apache.org/jira/browse/AMQ-3621
> Project: ActiveMQ
>  Issue Type: New Feature
>Reporter: Cservenak, Tamas
>
> Integrate Apache Shiro with ActiveMQ as "security solution".
> This would benefit for ActiveMQ to have support for a vast amount of already 
> existing solution (Realm implementations) that are out there for Shiro.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster

[Guillaume (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809251#comment-13809251
 ] 

Guillaume commented on AMQ-4837:


Note that the problem also occurs when the replication sync parameter is set to 
quorum_disk and quorum_mem.


> LevelDB corrupted in AMQ cluster
> 
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper. 
> When performing some tests using Web UI, I can across issues that appears to 
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web 
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the 
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message 
> summary ok however when clicking on the queue, no message details. An error 
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error 
> occurs to each node infinitely (shutdown/restart). The only way around is to 
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t 
> occur.
> =
> Leveldb configuration on the 3 instances:
>   
>  directory="${activemq.data}/leveldb"
>   replicas="3"
>   bind="tcp://0.0.0.0:0"
>   zkAddress="zkserver:2181"
>   zkPath="/activemq/leveldb-stores"
>   />
>   
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at 
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at 
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at 
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at 
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at 
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at 
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at 
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at 
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at 
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
> at 
> org.apache.activemq.leveldb.LevelDBClient

Should vmCursor honor memory usage limits

[Claus Ibsen]

See
https://issues.apache.org/jira/browse/AMQ-3643

Any comments on this ticket?

-- 
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[jira] [Commented] (AMQ-3643) vmQueueCursor does not honour system wide memoryUsage limit

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809160#comment-13809160
 ] 

Claus Ibsen commented on AMQ-3643:
--

Yeah maybe we should get the AMQ people to see if they think its a good idea to 
have this baked into the vm cursor. Its been like this for a long time, so 
maybe the change looks good at first, but maybe not.

Let me post on @dev to get their attention. 

> vmQueueCursor does not honour system wide memoryUsage limit
> ---
>
> Key: AMQ-3643
> URL: https://issues.apache.org/jira/browse/AMQ-3643
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.5.1
> Environment: vmQueueCursor
>Reporter: Torsten Mielke
>Priority: Critical
>  Labels: vmQueueCursor
> Fix For: NEEDS_REVIEWED
>
> Attachments: VMQueueCursorBug.tgz
>
>
> The vmQueueCursor isn't bound to configured memoryUsage limit and hence can 
> grow indefinitely and cause OutOfMemoryErrors.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (AMQ-1063) Journaled JDBC checkpoint fails with java.io.IOException: Already started.

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned AMQ-1063:


Assignee: Claus Ibsen

> Journaled JDBC checkpoint fails with java.io.IOException: Already started.
> --
>
> Key: AMQ-1063
> URL: https://issues.apache.org/jira/browse/AMQ-1063
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.0.0
> Environment: Windows XP Professional, JVM 1.5.0_09, MySQL 5.0.27
>Reporter: j...@penguinsfan.com
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
> Attachments: activemq.log.zip
>
>
> I am running trunk using JDBC against MySQL 5.0.27.  I am seeing the above 
> mentioned IOException.  Do not have specific instructions on how to reproduce 
> at the current time, but I was using durable subscriptions with the store 
> durable cursor if that helps.  (I'll post if I find out more information.)
>   
>
>dataSource="#mysql-ds"/>
> 
>destroy-method="close">
> 
>  value="jdbc:mysql://localhost/activemq?relaxAutoCommit=true"/>
> 
> 
> 
> 
> Log trace:
> 2006-11-19 19:19:48,078 [/127.0.0.1:4898] DEBUG JournalPersistenceAdapter 
>  - Waking for checkpoint to complete.
> 2006-11-19 19:19:48,078 [eckpoint Worker] DEBUG JournalPersistenceAdapter 
>  - Checkpoint started.
> 2006-11-19 19:19:48,078 [eckpoint Worker] ERROR JournalPersistenceAdapter 
>  - Failed to checkpoint a message store: 
> java.util.concurrent.ExecutionException: java.io.IOException: Already started.
> java.util.concurrent.ExecutionException: java.io.IOException: Already started.
>   at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:205)
>   at java.util.concurrent.FutureTask.get(FutureTask.java:80)
>   at 
> org.apache.activemq.store.journal.JournalPersistenceAdapter.doCheckpoint(JournalPersistenceAdapter.java:386)
>   at 
> org.apache.activemq.store.journal.JournalPersistenceAdapter$2.iterate(JournalPersistenceAdapter.java:129)
>   at 
> org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:88)
>   at 
> org.apache.activemq.thread.DedicatedTaskRunner.access$0(DedicatedTaskRunner.java:76)
>   at 
> org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:39)
> Caused by: java.io.IOException: Already started.
>   at 
> org.apache.activemq.store.jdbc.TransactionContext.begin(TransactionContext.java:145)
>   at 
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransaction(JDBCPersistenceAdapter.java:358)
>   at 
> org.apache.activemq.store.journal.JournalPersistenceAdapter.beginTransaction(JournalPersistenceAdapter.java:189)
>   at 
> org.apache.activemq.util.TransactionTemplate.run(TransactionTemplate.java:41)
>   at 
> org.apache.activemq.store.journal.JournalMessageStore.checkpoint(JournalMessageStore.java:247)
>   at 
> org.apache.activemq.store.journal.JournalTopicMessageStore.checkpoint(JournalTopicMessageStore.java:162)
>   at 
> org.apache.activemq.store.journal.JournalPersistenceAdapter$5.call(JournalPersistenceAdapter.java:373)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:123)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>   at java.lang.Thread.run(Thread.java:595)
> 2006-11-19 19:19:48,109 [eckpoint Worker] DEBUG JournalPersistenceAdapter 
>  - Checkpoint done.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-3082) Broker doesn't stop using the activemq script if the JMX port is changed

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-3082:
-

Fix Version/s: 5.10.0

> Broker doesn't stop using the activemq script if the JMX port is changed
> 
>
> Key: AMQ-3082
> URL: https://issues.apache.org/jira/browse/AMQ-3082
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.4.1
> Environment: CentOS 5.4 64 bits
>Reporter: Iker Jimenez
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> I have two activemq instances on the same machine. One running on all the 
> default port settings and the other one on the following ports:
> Changed to the second activemq instance:
> in bin/activemq:
> ACTIVEMQ_SUNJMX_CONTROL="--jmxurl 
> service:jmx:rmi:///jndi/rmi://localhost:1100/jmxrmi"
> in conf/activemq.xml
>  jmxDomainName="broker2"/>
> ...
> 
> in conf/jetty.xml
> 
> So when I execute bin/activemq start:
> ...
>  INFO | JMX consoles can connect to 
> service:jmx:rmi:///jndi/rmi://localhost:1100/jmxrmi
>  INFO | Listening for connections at: tcp://myhostname:61617
> ...
> When I try to stop it, bin/activemq stop:
> ...
> INFO: There are no brokers to stop.
> .
> INFO: Regular shutdown not successful,  sending SIGKILL to process with pid 
> '26137'
> I added some logging to the script to discover that it was doing this call:
> /usr/bin/java 
> -Dactivemq.classpath="/home/myuser/activeMQ2/apache-activemq-5.4.1/conf;" 
> -Dactivemq.home="/home/myuser/activeMQ2/apache-activemq-5.4.1" 
> -Dactivemq.base="/home/myuser/activeMQ2/apache-activemq-5.4.1" -jar 
> "/home/myuser/activeMQ2/apache-activemq-5.4.1/bin/run.jar" stop --jmxurl 
> service:jmx:rmi:///jndi/rmi://localhost:1100/jmxrmi
> This doesn't seem to find the JMX service in the specified location, even 
> though it is the URL that was printed at start up (See log above).
> All I wanted to have is two instances running on the same box to test a 
> cluster configuration, but starting/stopping them correctly with the scripts 
> seem to be a pain. A simple kill to the process PID works much better.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4120) SqlServer - SQL Syntax error in initial table creation

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809153#comment-13809153
 ] 

Claus Ibsen commented on AMQ-4120:
--

Dont we have a SQL server adaptor now? Can you check AMQ 5.9 release?

> SqlServer - SQL Syntax error in initial table creation
> --
>
> Key: AMQ-4120
> URL: https://issues.apache.org/jira/browse/AMQ-4120
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.7.0
> Environment: Windows Server 2008 R2, 64bit, MS SQL Server 2008 
> persistence adapter.
>Reporter: Rasitha Wijesinghe
>Priority: Minor
> Fix For: NEEDS_REVIEWED
>
>
> When using SQL Server as the backing data store and creating the AMQ tables 
> for the very first time, the following error is logged:
> INFO   | jvm 1| 2012/10/19 11:12:03 |  WARN | Could not create JDBC 
> tables; they could already exist. Failure was: ALTER TABLE ACTIVEMQ_ACKS DROP 
> PRIMARY KEY Message: Incorrect syntax near the keyword 'PRIMARY'. SQLState: 
> S1000 Vendor code: 156
> INFO   | jvm 1| 2012/10/19 11:12:03 |  WARN | Failure details: Incorrect 
> syntax near the keyword 'PRIMARY'.
> INFO   | jvm 1| 2012/10/19 11:12:03 | java.sql.SQLException: Incorrect 
> syntax near the keyword 'PRIMARY'.
> Since there is no specific adapter for SQL Server it uses the 
> DefaultJDBCAdapter which has getDropAckPKAlterStatementEnd() returning "DROP 
> PRIMARY KEY".
> Not sure if this is an issue with other databases as well.
> (Note: If you already have the tables, this error is still present but only 
> logs a DEBUG entry).
> Does it make sense to add a MSSqlJDBCAdapter that overrides 
> getDropAckPKAlterStatementEnd?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4120) SqlServer - SQL Syntax error in initial table creation

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4120:
-

Fix Version/s: NEEDS_REVIEWED
   Issue Type: Improvement  (was: Bug)

> SqlServer - SQL Syntax error in initial table creation
> --
>
> Key: AMQ-4120
> URL: https://issues.apache.org/jira/browse/AMQ-4120
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.7.0
> Environment: Windows Server 2008 R2, 64bit, MS SQL Server 2008 
> persistence adapter.
>Reporter: Rasitha Wijesinghe
>Priority: Minor
> Fix For: NEEDS_REVIEWED
>
>
> When using SQL Server as the backing data store and creating the AMQ tables 
> for the very first time, the following error is logged:
> INFO   | jvm 1| 2012/10/19 11:12:03 |  WARN | Could not create JDBC 
> tables; they could already exist. Failure was: ALTER TABLE ACTIVEMQ_ACKS DROP 
> PRIMARY KEY Message: Incorrect syntax near the keyword 'PRIMARY'. SQLState: 
> S1000 Vendor code: 156
> INFO   | jvm 1| 2012/10/19 11:12:03 |  WARN | Failure details: Incorrect 
> syntax near the keyword 'PRIMARY'.
> INFO   | jvm 1| 2012/10/19 11:12:03 | java.sql.SQLException: Incorrect 
> syntax near the keyword 'PRIMARY'.
> Since there is no specific adapter for SQL Server it uses the 
> DefaultJDBCAdapter which has getDropAckPKAlterStatementEnd() returning "DROP 
> PRIMARY KEY".
> Not sure if this is an issue with other databases as well.
> (Note: If you already have the tables, this error is still present but only 
> logs a DEBUG entry).
> Does it make sense to add a MSSqlJDBCAdapter that overrides 
> getDropAckPKAlterStatementEnd?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-1063) Journaled JDBC checkpoint fails with java.io.IOException: Already started.

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-1063:
-

Fix Version/s: (was: NEEDS_REVIEWED)
   5.10.0

> Journaled JDBC checkpoint fails with java.io.IOException: Already started.
> --
>
> Key: AMQ-1063
> URL: https://issues.apache.org/jira/browse/AMQ-1063
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.0.0
> Environment: Windows XP Professional, JVM 1.5.0_09, MySQL 5.0.27
>Reporter: j...@penguinsfan.com
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
> Attachments: activemq.log.zip
>
>
> I am running trunk using JDBC against MySQL 5.0.27.  I am seeing the above 
> mentioned IOException.  Do not have specific instructions on how to reproduce 
> at the current time, but I was using durable subscriptions with the store 
> durable cursor if that helps.  (I'll post if I find out more information.)
>   
>
>dataSource="#mysql-ds"/>
> 
>destroy-method="close">
> 
>  value="jdbc:mysql://localhost/activemq?relaxAutoCommit=true"/>
> 
> 
> 
> 
> Log trace:
> 2006-11-19 19:19:48,078 [/127.0.0.1:4898] DEBUG JournalPersistenceAdapter 
>  - Waking for checkpoint to complete.
> 2006-11-19 19:19:48,078 [eckpoint Worker] DEBUG JournalPersistenceAdapter 
>  - Checkpoint started.
> 2006-11-19 19:19:48,078 [eckpoint Worker] ERROR JournalPersistenceAdapter 
>  - Failed to checkpoint a message store: 
> java.util.concurrent.ExecutionException: java.io.IOException: Already started.
> java.util.concurrent.ExecutionException: java.io.IOException: Already started.
>   at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:205)
>   at java.util.concurrent.FutureTask.get(FutureTask.java:80)
>   at 
> org.apache.activemq.store.journal.JournalPersistenceAdapter.doCheckpoint(JournalPersistenceAdapter.java:386)
>   at 
> org.apache.activemq.store.journal.JournalPersistenceAdapter$2.iterate(JournalPersistenceAdapter.java:129)
>   at 
> org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:88)
>   at 
> org.apache.activemq.thread.DedicatedTaskRunner.access$0(DedicatedTaskRunner.java:76)
>   at 
> org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:39)
> Caused by: java.io.IOException: Already started.
>   at 
> org.apache.activemq.store.jdbc.TransactionContext.begin(TransactionContext.java:145)
>   at 
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransaction(JDBCPersistenceAdapter.java:358)
>   at 
> org.apache.activemq.store.journal.JournalPersistenceAdapter.beginTransaction(JournalPersistenceAdapter.java:189)
>   at 
> org.apache.activemq.util.TransactionTemplate.run(TransactionTemplate.java:41)
>   at 
> org.apache.activemq.store.journal.JournalMessageStore.checkpoint(JournalMessageStore.java:247)
>   at 
> org.apache.activemq.store.journal.JournalTopicMessageStore.checkpoint(JournalTopicMessageStore.java:162)
>   at 
> org.apache.activemq.store.journal.JournalPersistenceAdapter$5.call(JournalPersistenceAdapter.java:373)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:123)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>   at java.lang.Thread.run(Thread.java:595)
> 2006-11-19 19:19:48,109 [eckpoint Worker] DEBUG JournalPersistenceAdapter 
>  - Checkpoint done.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4137) Create a store import/export command line tool to covert between store types

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4137:
-

Issue Type: New Feature  (was: Bug)

> Create a store import/export command line tool to covert between store types
> 
>
> Key: AMQ-4137
> URL: https://issues.apache.org/jira/browse/AMQ-4137
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Message Store
>Reporter: Hiram Chirino
>Assignee: Hiram Chirino
>
> Ideally is should be compatible with the Apollo store export/import file 
> format.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4105) InactivityIOException exception leading to ServiceMix not functioning

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4105:
-

Fix Version/s: AGING_TO_DIE

> InactivityIOException exception leading to ServiceMix not functioning
> -
>
> Key: AMQ-4105
> URL: https://issues.apache.org/jira/browse/AMQ-4105
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.4.2
> Environment: OS: SunOS 5.10 Generic_147440-23 sun4v sparc 
> SUNW,Netra-T5440
> HW: Sun sparc Netra T5440
> ActiveMq version: 5.4.2
> ServiceMix version: 4.3.0
> Java version: 1.5.0_32
>Reporter: Mithun Sunku
>Priority: Critical
> Fix For: AGING_TO_DIE
>
> Attachments: servicemix.log.zip
>
>
> We are using ActiveMQ broker with ServiceMix and have observed following 
> InactivityIOException being reported in ServiceMix logs and ActiveMq closes 
> MessageProducer and MessageComsumer. Then JMS related 
> activemq.ConnectionFailedExceptions are observed and the ServiceMix stops 
> functioning and clients are not able to register for topics and get any data 
> from ServiceMix.
> Transport failed: org.apache.activemq.transport.InactivityIOException: 
> Channel was inactive for too (>3) long: /127.0.0.1:44650 
> Based on the information provided in forum, we have tried to disable 
> Inactivity Monitor in the ActiveMq-broker.xml file available in 
> ServiceMix/etc directory, however Inactivity monitor is not changed from 
> default value of 3. 
> ActiveMq-broker.xml from our setup:
> 
> 
> 
>   uri="tcp://localhost:61616?wireFormat.maxInactivityDuration=0"/>
>  
>
> 
> Please let us know what has caused InactivityTimeout exception and how to 
> reproduce this issue and how this issue will be resolved.
> ServiceMix Logs:
> [2012-10-09 03:26:24,964] | INFO  | InactivityMonitor Async Task: 
> java.util.concurrent.ThreadPoolExecutor$Worker@49754b | Transport 
>| emq.broker.TransportConnection  238 | Transport failed: 
> org.apache.activemq.transport.InactivityIOException: Channel was inactive for 
> too (>3) long: /127.0.0.1:44650
> [2012-10-09 03:26:25,306] | INFO  | ActiveMQ Transport: 
> tcp:///127.0.0.1:44705 | Transport| 
> emq.broker.TransportConnection  238 | Transport failed: java.io.EOFException
> [2012-10-09 03:26:26,443] | WARN  | 
> pool-component.servicemix-wsn2005.provider-thread-36 | JmsPublisher   
>   | ervicemix.wsn.jms.JmsPublisher   97 | Error dispatching message
> javax.jms.IllegalStateException: The producer is closed
>   at 
> org.apache.activemq.ActiveMQMessageProducer.checkClosed(ActiveMQMessageProducer.java:169)
>   at 
> org.apache.activemq.ActiveMQMessageProducerSupport.getDeliveryMode(ActiveMQMessageProducerSupport.java:148)
>   at 
> org.apache.activemq.pool.PooledProducer.(PooledProducer.java:44)
>   at 
> org.apache.activemq.pool.PooledSession.createProducer(PooledSession.java:278)
>   at 
> org.apache.servicemix.wsn.jms.JmsPublisher.notify(JmsPublisher.java:89)[166:servicemix-wsn2005:2011.01.0]
>   at 
> org.apache.servicemix.wsn.AbstractNotificationBroker.handleNotify(AbstractNotificationBroker.java:134)[166:servicemix-wsn2005:2011.01.0]
>   at 
> org.apache.servicemix.wsn.AbstractNotificationBroker.notify(AbstractNotificationBroker.java:126)[166:servicemix-wsn2005:2011.01.0]
>   at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown 
> Source)[:1.6.0_33]
>   at java.lang.reflect.Method.invoke(Unknown Source)[:1.6.0_33]
>   at 
> org.apache.servicemix.wsn.component.WSNEndpoint.process(WSNEndpoint.java:166)[166:servicemix-wsn2005:2011.01.0]
>   at 
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:651)[121:servicemix-common:2011.01.0]
>   at 
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:606)[121:servicemix-common:2011.01.0]
>   at 
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInTx(AsyncBaseLifeCycle.java:501)[121:servicemix-common:2011.01.0]
>   at 
> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLifeCycle.java:370)[121:servicemix-common:2011.01.0]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source)[:1.6.0_33]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
> Source)[:1.6.0_33]
>   at java.lang.Thread.run(Unknown Source)[:1.6.0_33]
> [2012-10-09 03:26:26,631] | INFO  | 
> pool-component.servicemix-wsn2005.provider-thread-37 | JmsPullPoint   
>   | ervicemix.wsn.jms.JmsPullPoint  125 | Error retrieving messages
> javax.jms.IllegalStateException: The Consumer is closed
>   at 
> 

[jira] [Updated] (AMQ-4155) Can't start Blueprint broker in Apache Karaf without having Spring JARs

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4155:
-

Fix Version/s: 5.10.0

> Can't start Blueprint broker in Apache Karaf without having Spring JARs
> ---
>
> Key: AMQ-4155
> URL: https://issues.apache.org/jira/browse/AMQ-4155
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Apache Karaf 2.3.0
>Reporter: Victor Antonovich
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> ActiveMQ 5.8-SNAPSHOT (compiled from trunk) is unable to start blueprint 
> broker:
> {code}
> karaf@root> features:addurl 
> mvn:org.apache.activemq/activemq-karaf/5.8-SNAPSHOT/xml/features
> karaf@root> features:install activemq activemq-blueprint
> karaf@root> activemq:create-broker -t blueprint
> Creating file: @|green 
> /usr/java/apache-karaf-2.3.0/deploy/localhost-broker.xml|
> Default ActiveMQ Broker (localhost) configuration file created at: 
> /usr/java/apache-karaf-2.3.0/deploy/localhost-broker.xml
> Please review the configuration and modify to suite your needs.  
> 0
> karaf@root> la | grep localhost-broker
> [ 105] [Active ] [Failure ] [   80] localhost-broker.xml (0.0.0)
> {code}
> Blueprint component doesn't start due to the {{NoClassDefFoundError}}:
> {code}
> 2012-11-02 16:26:24,702 | ERROR | rint Extender: 3 | BlueprintContainerImpl   
> | container.BlueprintContainerImpl  375 | 7 - 
> org.apache.aries.blueprint.core - 1.0.1 | Unable to start blueprint container 
> for bundle localhost-broker.xml
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when 
> instanciating bean .component-2 of class class 
> org.apache.activemq.xbean.XBeanBrokerService
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_37]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_37]
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:646)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:353)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:252)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)[:1.6.0_37]
>   at 
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_37]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_37]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_37]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_37]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_37]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_37]
>   at java.lang.Thread.run(Thread.java:662)[:1.6.0_37]
> Caused by: java.lang.NoClassDefFoundError: 
> org/springframework/beans/BeansException
>   at 
> org.apache.activemq.xbean.XBeanBrokerService.(XBeanBrokerService.java:47)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)[:1.6.0_37]
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)[:1.6.0_37]
>   at 
> sun.refle

[jira] [Commented] (AMQ-4151) Duplicate non-persistent messages that are sent to a queue are either dispatched multiple times (i.e., not detected as duplicates) or cause the queue size to be miscalcul

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809149#comment-13809149
 ] 

Claus Ibsen commented on AMQ-4151:
--

Did you ever manage to build an unit test?

> Duplicate non-persistent messages that are sent to a queue are either 
> dispatched multiple times (i.e., not detected as duplicates) or cause the 
> queue size to be miscalculated.
> ---
>
> Key: AMQ-4151
> URL: https://issues.apache.org/jira/browse/AMQ-4151
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: Stirling Chow
>
> Symptom
> ===
> We have a virtual topic that is shared by a network of brokers.  Each broker 
> has consumers that process the corresponding Consumer.*.VirtualTopic.> queue.
> While testing the effects of memory limits on our system, we encountered 
> AMQ-4148, which resulted in duplicate subscriptions being made to the virtual 
> topic.  These duplicate subcriptions were attempting to enqueue the same 
> topic message multiple times to the corresponding Consumer.*.VirtualTopic.>.
> Although logic exists in queues to handle duplicate messages, we noticed lots 
> of strange behaviour with duplicate handling.  We decided to investigate 
> further and found a race condition whereby duplicate non-persistent messages 
> that were correctly ignored resulted in the queue size appearing to be 
> non-empty when in fact there were no messages.
> While our original investigation was prompted by AMQ-4148, the test case we 
> attached to this ticket does not rely on the misbehaviour caused by AMQ-4148, 
> but can occur during normal operation of network bridges when there are 
> multiple consumers for a virtual topic (as is the case, e.g., when conduit 
> subscriptions are disabled).
> Cause
> =
> If a virtual topic has multiple consumers, then sending a message to the 
> topic results in multiple dispatches of the same message (one to each 
> consumer).  If the multiple consumers originate from the same remote broker 
> (e.g., because conduit subscriptions are disabled), then a single message 
> sent to the virtual topic on broker1 will result in multiple duplicate 
> messages being sent to the virtual topic on broker2.
> If broker2 has corresponding Consumer.*.VirtualTopic.> queue, then the 
> multiple duplicate messages sent to the virtual topic on broker2 will result 
> in multiple duplicate messages being sent to the queue.  
> If the messages are non-persistent, the only logic that prevents each 
> duplicate message from being dispatched to a consumer is as follows:
> {code:title=Queue.java}
> private PendingList doPageInForDispatch(boolean force) throws Exception {
> ...
> // Only add new messages, not already pagedIn to avoid multiple
> // dispatch attempts
> pagedInMessagesLock.writeLock().lock();
> try {
> if(isPrioritizedMessages()) {
> resultList = new PrioritizedPendingList();
> } else {
> resultList = new OrderedPendingList();
> }
> for (QueueMessageReference ref : result) {
> if (!pagedInMessages.containsKey(ref.getMessageId())) {
> pagedInMessages.put(ref.getMessageId(), ref);
> resultList.addMessageLast(ref);
> } else {
> ref.decrementReferenceCount();
> }
> }
> } finally {
> pagedInMessagesLock.writeLock().unlock();
> }
> ...
> {code}
> If the consumers are fast and acknowledge the initial message dispatch before 
> the next duplicate message is sent to the queue, then the 
> {{pagedInMessages.constainsKey(...)}} check will *not* prevent the duplicate 
> message from being dispatched since the message ID will have already been 
> removed as part of the acknowledgement.
> This is problem 1: duplicate detection fails if acknowledgements are quick
> If the consumers are slow and don't acknowledge the initial message dispatch 
> before the next duplicate message is sent to the queue, then duplicate 
> detection will correctly ignore the message.  However, by this time, the 
> duplicate message has already incremented the queue size:
> {code:title=Queue.java}
> final void messageSent(final ConnectionContext context, final Message msg) 
> throws Exception {
> destinationStatistics.getEnqueues().increment();
> destinationStatistics.getMessages().increment();
> messageDelivered(context, msg);
> {code}
> The call to {{messageSent}} is made by the thread sending the message to the 
> queue.  This thread is completely unaware that the message was ignored since 
> the call to {{doPageInForDisp

[jira] [Assigned] (AMQ-4155) Can't start Blueprint broker in Apache Karaf without having Spring JARs

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned AMQ-4155:


Assignee: Claus Ibsen

> Can't start Blueprint broker in Apache Karaf without having Spring JARs
> ---
>
> Key: AMQ-4155
> URL: https://issues.apache.org/jira/browse/AMQ-4155
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Apache Karaf 2.3.0
>Reporter: Victor Antonovich
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> ActiveMQ 5.8-SNAPSHOT (compiled from trunk) is unable to start blueprint 
> broker:
> {code}
> karaf@root> features:addurl 
> mvn:org.apache.activemq/activemq-karaf/5.8-SNAPSHOT/xml/features
> karaf@root> features:install activemq activemq-blueprint
> karaf@root> activemq:create-broker -t blueprint
> Creating file: @|green 
> /usr/java/apache-karaf-2.3.0/deploy/localhost-broker.xml|
> Default ActiveMQ Broker (localhost) configuration file created at: 
> /usr/java/apache-karaf-2.3.0/deploy/localhost-broker.xml
> Please review the configuration and modify to suite your needs.  
> 0
> karaf@root> la | grep localhost-broker
> [ 105] [Active ] [Failure ] [   80] localhost-broker.xml (0.0.0)
> {code}
> Blueprint component doesn't start due to the {{NoClassDefFoundError}}:
> {code}
> 2012-11-02 16:26:24,702 | ERROR | rint Extender: 3 | BlueprintContainerImpl   
> | container.BlueprintContainerImpl  375 | 7 - 
> org.apache.aries.blueprint.core - 1.0.1 | Unable to start blueprint container 
> for bundle localhost-broker.xml
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when 
> instanciating bean .component-2 of class class 
> org.apache.activemq.xbean.XBeanBrokerService
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_37]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_37]
>   at 
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:646)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:353)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:252)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.0.1]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)[:1.6.0_37]
>   at 
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_37]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_37]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_37]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_37]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_37]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_37]
>   at java.lang.Thread.run(Thread.java:662)[:1.6.0_37]
> Caused by: java.lang.NoClassDefFoundError: 
> org/springframework/beans/BeansException
>   at 
> org.apache.activemq.xbean.XBeanBrokerService.(XBeanBrokerService.java:47)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)[:1.6.0_37]
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)[:1.6.0_37]
>   at 
> sun

[jira] [Updated] (AMQ-4184) Multiple TestSupport classes, could possibly be merged into one

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4184:
-

Issue Type: Improvement  (was: Bug)

> Multiple TestSupport classes, could possibly be merged into one
> ---
>
> Key: AMQ-4184
> URL: https://issues.apache.org/jira/browse/AMQ-4184
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Test Cases
>Affects Versions: 5.7.0
>Reporter: Christian Posta
>Assignee: Christian Posta
>Priority: Trivial
>
> activemq-broker/org.apache.activemq.test.TestSupport
> activemq-core/org.apache.activemq.TestSupport
> activemq-core/org.apache.activemq.usecases.TestSupport



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4242) JMS Stream may lost data

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809139#comment-13809139
 ] 

Claus Ibsen commented on AMQ-4242:
--

Yeah we are deprecating this functionality.

> JMS Stream may lost data
> 
>
> Key: AMQ-4242
> URL: https://issues.apache.org/jira/browse/AMQ-4242
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.x
>Reporter: SuoNayi
>  Labels: JMSStream
> Fix For: NEEDS_REVIEWED
>
> Attachments: AMQ4242Test.java
>
>
> When more than 75 percent prefetch messages are delivered,the standard ack 
> occurs.
> If consumer/recipient fails after that, the rest messages will be one part of 
> the whole.
> New coming up consumer will discard the rest messages because it's expected 
> to read sequential messages from seq 0.
> From the view of the end user, the data transfered by JMS Stream is 
> incomplete 
> and data is lost in this case.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (AMQ-4242) JMS Stream may lost data

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved AMQ-4242.
--

   Resolution: Won't Fix
Fix Version/s: (was: NEEDS_REVIEWED)
   5.10.0
 Assignee: Claus Ibsen

> JMS Stream may lost data
> 
>
> Key: AMQ-4242
> URL: https://issues.apache.org/jira/browse/AMQ-4242
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.x
>Reporter: SuoNayi
>Assignee: Claus Ibsen
>  Labels: JMSStream
> Fix For: 5.10.0
>
> Attachments: AMQ4242Test.java
>
>
> When more than 75 percent prefetch messages are delivered,the standard ack 
> occurs.
> If consumer/recipient fails after that, the rest messages will be one part of 
> the whole.
> New coming up consumer will discard the rest messages because it's expected 
> to read sequential messages from seq 0.
> From the view of the end user, the data transfered by JMS Stream is 
> incomplete 
> and data is lost in this case.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (AMQ-4839) deprecated JMS streams

[Claus Ibsen (JIRA)]

Claus Ibsen created AMQ-4839:


 Summary: deprecated JMS streams
 Key: AMQ-4839
 URL: https://issues.apache.org/jira/browse/AMQ-4839
 Project: ActiveMQ
  Issue Type: Task
  Components: Broker
Reporter: Claus Ibsen
 Fix For: 5.10.0


This feature
http://activemq.apache.org/jms-streams.html

Is seldom used and its not good practice with streaming types in a message 
broker.

For large payloads people can use out of bands transports such as the FTP or 
whatnot.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4244) RA activation spec maxMessagesPerSessions property not honored.

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4244:
-

Fix Version/s: 5.10.0

> RA activation spec maxMessagesPerSessions property not honored.
> ---
>
> Key: AMQ-4244
> URL: https://issues.apache.org/jira/browse/AMQ-4244
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JCA Container
>Affects Versions: 5.7.0
>Reporter: Hiram Chirino
> Fix For: 5.10.0
>
>
> Seems like it was supposed to control prefetching, right now it has no 
> effect.  see:
> https://github.com/apache/activemq/blob/trunk/activemq-ra/src/main/java/org/apache/activemq/ra/ActiveMQEndpointWorker.java#L170
> Connection settings are the only way to configure the prefetching when used 
> in a resource adapter now.
> Would be nice if a the maxMessagesPerSessions setting could be renamed to 
> something simpler like prefetchSize.  And IF set, then it overrides the 
> connection defaults.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4242) JMS Stream may lost data

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809113#comment-13809113
 ] 

Claus Ibsen commented on AMQ-4242:
--

Yeah I wonder if we should mark this jms streams as @deprecated.?

> JMS Stream may lost data
> 
>
> Key: AMQ-4242
> URL: https://issues.apache.org/jira/browse/AMQ-4242
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.x
>Reporter: SuoNayi
>  Labels: JMSStream
> Fix For: NEEDS_REVIEWED
>
> Attachments: AMQ4242Test.java
>
>
> When more than 75 percent prefetch messages are delivered,the standard ack 
> occurs.
> If consumer/recipient fails after that, the rest messages will be one part of 
> the whole.
> New coming up consumer will discard the rest messages because it's expected 
> to read sequential messages from seq 0.
> From the view of the end user, the data transfered by JMS Stream is 
> incomplete 
> and data is lost in this case.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4244) RA activation spec maxMessagesPerSessions property not honored.

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809116#comment-13809116
 ] 

Claus Ibsen commented on AMQ-4244:
--

We did some RAR fixes/improvements for 5.9. Wonder if this is still a problem?

> RA activation spec maxMessagesPerSessions property not honored.
> ---
>
> Key: AMQ-4244
> URL: https://issues.apache.org/jira/browse/AMQ-4244
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JCA Container
>Affects Versions: 5.7.0
>Reporter: Hiram Chirino
> Fix For: 5.10.0
>
>
> Seems like it was supposed to control prefetching, right now it has no 
> effect.  see:
> https://github.com/apache/activemq/blob/trunk/activemq-ra/src/main/java/org/apache/activemq/ra/ActiveMQEndpointWorker.java#L170
> Connection settings are the only way to configure the prefetching when used 
> in a resource adapter now.
> Would be nice if a the maxMessagesPerSessions setting could be renamed to 
> something simpler like prefetchSize.  And IF set, then it overrides the 
> connection defaults.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4232) Kahadb does not allow to obtain count of used/free bytes in the storage

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4232:
-

Issue Type: Improvement  (was: Bug)

> Kahadb does not allow to obtain count of used/free bytes in the storage
> ---
>
> Key: AMQ-4232
> URL: https://issues.apache.org/jira/browse/AMQ-4232
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.4.2, 5.7.0
> Environment: fedora15, ubuntu12.10; debian; probably independent
>Reporter: Tomáš Martinec
>  Labels: hangs, kahadb, usage
> Fix For: 5.10.0
>
> Attachments: extending.kahadb.diff
>
>
> The full story is user forum under title:
> Activemq 5.4.2 hangs when the temp disk usage is used
> TempUsage.retrieveUsage() always returns the size of the allocated storage 
> instead of the actual usage. I could not see what methods of kahadb returns 
> the needed information, so I extended the kahadb interface.
> Note that this issue may cause other problems such as AMQ-4136.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (AMQ-4229) activemq-web-console unusable in OSGi due to massive exports

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved AMQ-4229.
--

   Resolution: Won't Fix
Fix Version/s: 5.9.0
 Assignee: Claus Ibsen

The old web console is deprecated. From AMQ 5.9 onwards hawtio is the new 
console that works in OSGi and any other JVM out of the box.

> activemq-web-console unusable in OSGi due to massive exports
> 
>
> Key: AMQ-4229
> URL: https://issues.apache.org/jira/browse/AMQ-4229
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.7.0
>Reporter: Raul Kripalani
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 5.9.0
>
>
> {{activemq-web-console}} is unusable in an OSGi environment because it embeds 
> all of AMQ classes inside it and exports them to the OSGi container. Thus, 
> classloading conflicts start to appear in bundles importing 
> org.apache.activemq packages.
> smx@root> list | grep activemq
> [ 198] [Active ] [] [   ] [   50] activemq-web-console 
> (5.7.0)
> smx@root> exports 198
> ID Packages
>198 org.apache.activemq.jaas; version="5.7.0"
>198 org.apache.activemq.memory.list; version="5.7.0"
>198 org.apache.activemq.transport.discovery.simple; version="5.7.0"
>198 org.apache.activemq.transport.xmpp; version="5.7.0"
>198 org.apache.activemq.advisory; version="5.7.0"
>198 org.apache.activemq.broker.jmx; version="5.7.0"
>198 org.apache.activemq.broker; version="5.7.0"
>198 org.apache.activemq.blob; version="5.7.0"
>198 org.apache.activemq.usage; version="5.7.0"
>198 org.apache.activemq.transport.discovery.zeroconf; version="5.7.0"
>198 org.apache.activemq.transport.stomp; version="5.7.0"
>198 org.apache.activemq.transport.mqtt; version="5.7.0"
>198 org.apache.activemq.transport.peer; version="5.7.0"
>198 org.apache.activemq.transport.failover; version="5.7.0"
>198 org.apache.activemq.broker.region.group; version="5.7.0"
>198 org.apache.activemq.transport; version="5.7.0"
>198 org.apache.activemq.kaha.impl.index; version="5.7.0"
>198 org.apache.activemq.store.memory; version="5.7.0"
>198 org.apache.activemq.console.command.store.amq.reader; version="5.7.0"
>198 org.apache.activemq.broker.region; version="5.7.0"
>198 org.apache.activemq.store.jdbc.adapter; version="5.7.0"
>198 org.apache.activemq.transport.reliable; version="5.7.0"
>198 org.apache.activemq.transport.discovery.multicast; version="5.7.0"
>198 org.apache.activemq.transport.tcp; version="5.7.0"
>198 org.apache.activemq.kaha.impl.container; version="5.7.0"
>198 org.apache.activemq.state; version="5.7.0"
>198 org.apache.activemq.broker.scheduler; version="5.7.0"
>198 org.apache.activemq.console.filter; version="5.7.0"
>198 org.apache.activemq.management; version="5.7.0"
>198 org.apache.activemq.transport.mock; version="5.7.0"
>198 org.apache.activemq.transport.vm; version="5.7.0"
>198 org.apache.activemq.xbean; version="5.7.0"
>198 org.apache.activemq.kaha.impl; version="5.7.0"
>198 org.apache.activemq.camel; version="5.7.0"
>198 org.apache.activemq.web.config; version="5.7.0"
>198 org.apache.activemq.openwire.v1; version="5.7.0"
>198 org.apache.activemq.openwire.v2; version="5.7.0"
>198 org.apache.activemq.openwire.v3; version="5.7.0"
>198 org.apache.activemq.openwire.v4; version="5.7.0"
> ...



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4232) Kahadb does not allow to obtain count of used/free bytes in the storage

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4232:
-

Priority: Major  (was: Critical)

> Kahadb does not allow to obtain count of used/free bytes in the storage
> ---
>
> Key: AMQ-4232
> URL: https://issues.apache.org/jira/browse/AMQ-4232
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.4.2, 5.7.0
> Environment: fedora15, ubuntu12.10; debian; probably independent
>Reporter: Tomáš Martinec
>  Labels: hangs, kahadb, usage
> Fix For: 5.10.0
>
> Attachments: extending.kahadb.diff
>
>
> The full story is user forum under title:
> Activemq 5.4.2 hangs when the temp disk usage is used
> TempUsage.retrieveUsage() always returns the size of the allocated storage 
> instead of the actual usage. I could not see what methods of kahadb returns 
> the needed information, so I extended the kahadb interface.
> Note that this issue may cause other problems such as AMQ-4136.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4232) Kahadb does not allow to obtain count of used/free bytes in the storage

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809123#comment-13809123
 ] 

Claus Ibsen commented on AMQ-4232:
--

I noticed a report about the free space check on startup may only check for 
disk free space, and not take into account used space already. So wonder if 
this ticket isn't functionality we would need to help some that other problem?

> Kahadb does not allow to obtain count of used/free bytes in the storage
> ---
>
> Key: AMQ-4232
> URL: https://issues.apache.org/jira/browse/AMQ-4232
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.4.2, 5.7.0
> Environment: fedora15, ubuntu12.10; debian; probably independent
>Reporter: Tomáš Martinec
>Priority: Critical
>  Labels: hangs, kahadb, usage
> Fix For: 5.10.0
>
> Attachments: extending.kahadb.diff
>
>
> The full story is user forum under title:
> Activemq 5.4.2 hangs when the temp disk usage is used
> TempUsage.retrieveUsage() always returns the size of the allocated storage 
> instead of the actual usage. I could not see what methods of kahadb returns 
> the needed information, so I extended the kahadb interface.
> Note that this issue may cause other problems such as AMQ-4136.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4232) Kahadb does not allow to obtain count of used/free bytes in the storage

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4232:
-

Fix Version/s: 5.10.0

> Kahadb does not allow to obtain count of used/free bytes in the storage
> ---
>
> Key: AMQ-4232
> URL: https://issues.apache.org/jira/browse/AMQ-4232
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.4.2, 5.7.0
> Environment: fedora15, ubuntu12.10; debian; probably independent
>Reporter: Tomáš Martinec
>  Labels: hangs, kahadb, usage
> Fix For: 5.10.0
>
> Attachments: extending.kahadb.diff
>
>
> The full story is user forum under title:
> Activemq 5.4.2 hangs when the temp disk usage is used
> TempUsage.retrieveUsage() always returns the size of the allocated storage 
> instead of the actual usage. I could not see what methods of kahadb returns 
> the needed information, so I extended the kahadb interface.
> Note that this issue may cause other problems such as AMQ-4136.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4242) JMS Stream may lost data

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4242:
-

Fix Version/s: NEEDS_REVIEWED

> JMS Stream may lost data
> 
>
> Key: AMQ-4242
> URL: https://issues.apache.org/jira/browse/AMQ-4242
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.x
>Reporter: SuoNayi
>  Labels: JMSStream
> Fix For: NEEDS_REVIEWED
>
> Attachments: AMQ4242Test.java
>
>
> When more than 75 percent prefetch messages are delivered,the standard ack 
> occurs.
> If consumer/recipient fails after that, the rest messages will be one part of 
> the whole.
> New coming up consumer will discard the rest messages because it's expected 
> to read sequential messages from seq 0.
> From the view of the end user, the data transfered by JMS Stream is 
> incomplete 
> and data is lost in this case.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4354) Persist JMX statistics so they survive a restart

[Matt Pavlovich (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809114#comment-13809114
 ] 

Matt Pavlovich commented on AMQ-4354:
-

All the stats for non-transitive objects under org.apache.activemq. Broker 
stats, destination stats, transport/network connector stats, etc.. (connection 
stats wouldn't make any sense b/c they are transitive).

Not persisting statistics results in weird scenarios where after a restart you 
have "4,232" pending messages, but "0" enqueued messages.

Admins could then rely on "resetStatistics" to clear them, instead of a broker 
restart



> Persist JMX statistics so they survive a restart
> 
>
> Key: AMQ-4354
> URL: https://issues.apache.org/jira/browse/AMQ-4354
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: JMX
>Affects Versions: 5.8.0
> Environment: All
>Reporter: Matt Pavlovich
>
> It would be really handy if JMX statistics survived a restart. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (AMQNET-418) Recovery File Logger does not support multiple concurrent transactions

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQNET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved AMQNET-418.
-

   Resolution: Fixed
Fix Version/s: 1.7.0
   1.6.2
 Assignee: Timothy Bish  (was: Jim Gomes)

Applied to trunk and 1.6.x following review.  

> Recovery File Logger does not support multiple concurrent transactions
> --
>
> Key: AMQNET-418
> URL: https://issues.apache.org/jira/browse/AMQNET-418
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Timothy Bish
> Fix For: 1.6.2, 1.7.0
>
> Attachments: allDTCImprovments.patch, 
> RecoveryLoggerDoesNotSupportMultipleTransactions.patch, 
> RecoveryLoggerDoesNotSupportMultipleTransactions.patch
>
>
> Currently it is not possible to use more than one session if you use DTC 
> Transactions. This is because the RecoveryFileLogger can not handle more than 
> one transaction simultanously.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4269) Messages stuck and never gets processed

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809105#comment-13809105
 ] 

Claus Ibsen commented on AMQ-4269:
--

Yeah use the mailing list / user forum for getting help.

> Messages stuck and never gets processed
> ---
>
> Key: AMQ-4269
> URL: https://issues.apache.org/jira/browse/AMQ-4269
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.7.0
> Environment: RHEL 6.3
>Reporter: Mohit Anchlia
>Priority: Critical
> Fix For: 5.10.0
>
>
> We have messages that get stuck and never gets processed. We also have 
> network of broker configured but that also is not picking up these messages. 
> We have 2 queues DLQ and events queue that show the same behaviour.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (AMQ-4263) [ActiveMQ web-console] HTTP ERROR 405 instead of clear warning message in case Topic\Queue name did not set when trying to create.

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved AMQ-4263.
--

   Resolution: Won't Fix
Fix Version/s: 5.9.0
 Assignee: Claus Ibsen

The old web console is deprecated. From AMQ 5.9 onwards hawtio is the new 
console.

> [ActiveMQ web-console] HTTP ERROR 405 instead of clear warning message in 
> case Topic\Queue name did not set when trying to create.
> --
>
> Key: AMQ-4263
> URL: https://issues.apache.org/jira/browse/AMQ-4263
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.7.0
> Environment: ActiveMQ modules are used in Karaf 2.2.9 OSGi container
>Reporter: Roman Minko
>Assignee: Claus Ibsen
>Priority: Minor
>  Labels: osgi, web-console
> Fix For: 5.9.0
>
> Attachments: name_null_create_topic.JPG
>
>
> 1. In Karaf console:
> features:addUrl mvn:org.apache.activemq/activemq-karaf/5.7.0/xml/features
> features:install activemq-spring
> features:install activemq-web-console
> activemq:create-broker
> 2. After install and start the web console with embedded broker going to use 
> it at
> http://localhost:8181/activemqweb/
> 3. Go to topic/queue page. If the name is null, click the "create" button, 
> will get the following exception:
> {code}
> HTTP ERROR 405
> Problem accessing /activemqweb/500.html. Reason:
> HTTP method POST is not supported by this URL
> Caused by:
> java.lang.IllegalArgumentException: No JMSDestination parameter specified
>   at 
> org.apache.activemq.web.DestinationFacade.getValidDestination(DestinationFacade.java:112)
>   at 
> org.apache.activemq.web.DestinationFacade.addDestination(DestinationFacade.java:56)
>   at 
> org.apache.activemq.web.controller.CreateDestination.handleRequest(CreateDestination.java:38)
>   at 
> org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
>   at 
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:790)
>   at 
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
>   at 
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:669)
>   at 
> org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:585)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
>   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.apache.activemq.web.AuditFilter.doFilter(AuditFilter.java:59)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300)
>   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.filter.ApplicationContextFilter.doFilter(ApplicationContextFilter.java:96)
>   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.ops4j.pax.web.service.internal.WelcomeFilesFilter.doFilter(WelcomeFilesFilter.java:193)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445)
>   at 
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:559)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1038)
>   at 
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:374)
>   at 
> org.eclipse.jetty.s

[jira] [Resolved] (AMQ-4269) Messages stuck and never gets processed

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved AMQ-4269.
--

   Resolution: Invalid
Fix Version/s: 5.10.0
 Assignee: Claus Ibsen

> Messages stuck and never gets processed
> ---
>
> Key: AMQ-4269
> URL: https://issues.apache.org/jira/browse/AMQ-4269
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.7.0
> Environment: RHEL 6.3
>Reporter: Mohit Anchlia
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 5.10.0
>
>
> We have messages that get stuck and never gets processed. We also have 
> network of broker configured but that also is not picking up these messages. 
> We have 2 queues DLQ and events queue that show the same behaviour.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (AMQ-3090) Improve/refine the "Send (Message)" form of the AMQ Web Console

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved AMQ-3090.
--

   Resolution: Won't Fix
Fix Version/s: 5.9.0
 Assignee: Claus Ibsen

The old web console is deprecated. From AMQ 5.9 onwards hawtio is the new web 
console.

> Improve/refine the "Send (Message)" form of the AMQ Web Console
> ---
>
> Key: AMQ-3090
> URL: https://issues.apache.org/jira/browse/AMQ-3090
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.4.2, 5.7.0
>Reporter: Robert Liguori
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 5.9.0
>
> Attachments: JMS Message.xls, send_form.PNG
>
>
> (Please look at screenshot for requested improvements)
> Comparing the Send (Message) web page to the JMS Spec, I have a few 
> refinements that would aid in the clarity of the "Send" form 
> (http://localhost:8161/admin/send.jsp) for AMQ users.
> Please see the table in the attached spreadsheet for details.
> Here's a quick look at my recommendations:
> - Add tooltips to each web component.  
> - Add validators to the components.
> - Add a feature to disable all of the validators at once by deselecting a 
> checkbox.
> - Devide the page into more group boxes (sections); e.g., message header 
> fields/values, misc fields, message bodies
> - Use radio buttons for the "Persistent Delivery" where the default is set to 
> "Persistent"
> - Use radio buttons for Queue and Topic   
> - Use smarter components/validators for the "Priority" component. 
> - Add support for different types of message bodies.  
> - Analyze if other JMSX[XXX] messages can have components incorporated in the 
> web page.   



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4325) camel doen't honor credentials set on activemqcomponent bean via spring

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4325:
-

Fix Version/s: 5.10.0

> camel doen't honor credentials set on activemqcomponent bean via spring
> ---
>
> Key: AMQ-4325
> URL: https://issues.apache.org/jira/browse/AMQ-4325
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Affects Versions: 5.8.0
> Environment: activemq 5.8.0
>Reporter: Kot Kot
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> I use this configuration to create activemq component.
>class="org.apache.activemq.camel.component.ActiveMQComponent" 
> factory-method="activeMQComponent">
> 
> 
> 
> 
> 
> Endpoint url doesn't have username and password set which results jms client 
> not being able to connect to broker which responds with "username is null".
> Setting username and password in endpoint url works   



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (AMQ-4325) camel doen't honor credentials set on activemqcomponent bean via spring

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned AMQ-4325:


Assignee: Claus Ibsen

> camel doen't honor credentials set on activemqcomponent bean via spring
> ---
>
> Key: AMQ-4325
> URL: https://issues.apache.org/jira/browse/AMQ-4325
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Affects Versions: 5.8.0
> Environment: activemq 5.8.0
>Reporter: Kot Kot
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> I use this configuration to create activemq component.
>class="org.apache.activemq.camel.component.ActiveMQComponent" 
> factory-method="activeMQComponent">
> 
> 
> 
> 
> 
> Endpoint url doesn't have username and password set which results jms client 
> not being able to connect to broker which responds with "username is null".
> Setting username and password in endpoint url works   



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4313) Queue.isOptimizeStorage() returns true when it should be returning false.

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809101#comment-13809101
 ] 

Claus Ibsen commented on AMQ-4313:
--

Hiram is this still a problem?

> Queue.isOptimizeStorage() returns true when it should be returning false.
> -
>
> Key: AMQ-4313
> URL: https://issues.apache.org/jira/browse/AMQ-4313
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store, Broker
>Affects Versions: 5.8.0
>Reporter: Hiram Chirino
>
> Queue.isOptimizeStorage() is returning true even when you attach a consumer 
> that does not ack.
> This causes the leveldb store will delay storing messages which in turn make 
> producers wait longer for the sync send receipt .
> for an example of that see the 
> SparseAckReplayAfterStoreCleanupLevelDBStoreTest
> if you comment out 'store.setFlushDelay(0);' the test will take a long time 
> due to Queue.isOptimizeStorage() reporting true.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4354) Persist JMX statistics so they survive a restart

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4354:
-

Issue Type: New Feature  (was: Improvement)

> Persist JMX statistics so they survive a restart
> 
>
> Key: AMQ-4354
> URL: https://issues.apache.org/jira/browse/AMQ-4354
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: JMX
>Affects Versions: 5.8.0
> Environment: All
>Reporter: Matt Pavlovich
>
> It would be really handy if JMX statistics survived a restart. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4354) Persist JMX statistics so they survive a restart

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809098#comment-13809098
 ] 

Claus Ibsen commented on AMQ-4354:
--

Which statistics are you referring to?

> Persist JMX statistics so they survive a restart
> 
>
> Key: AMQ-4354
> URL: https://issues.apache.org/jira/browse/AMQ-4354
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: JMX
>Affects Versions: 5.8.0
> Environment: All
>Reporter: Matt Pavlovich
>
> It would be really handy if JMX statistics survived a restart. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (AMQNET-417) DTC Recovery should be done once for each application start

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQNET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved AMQNET-417.
-

Resolution: Fixed
  Assignee: Timothy Bish  (was: Jim Gomes)

Patch applied following review.  Added to trunk and 1.6.x

> DTC Recovery should be done once for each application start
> ---
>
> Key: AMQNET-417
> URL: https://issues.apache.org/jira/browse/AMQNET-417
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Timothy Bish
> Fix For: 1.6.2, 1.7.0
>
> Attachments: allDTCImprovments.patch, 
> DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch, 
> DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch
>
>
> DTC recovery is currently executed when a new session is created. This is not 
> correct because there can be other sessions that are currently commiting a 
> transaction. This transactions must not be recovered, otherwise there are 
> strange behaviors.
> The recovery should be done just once foreach ressource manager ID.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQNET-417) DTC Recovery should be done once for each application start

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQNET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish updated AMQNET-417:


Fix Version/s: 1.7.0
   1.6.2

> DTC Recovery should be done once for each application start
> ---
>
> Key: AMQNET-417
> URL: https://issues.apache.org/jira/browse/AMQNET-417
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Jim Gomes
> Fix For: 1.6.2, 1.7.0
>
> Attachments: allDTCImprovments.patch, 
> DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch, 
> DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch
>
>
> DTC recovery is currently executed when a new session is created. This is not 
> correct because there can be other sessions that are currently commiting a 
> transaction. This transactions must not be recovered, otherwise there are 
> strange behaviors.
> The recovery should be done just once foreach ressource manager ID.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (AMQ-4838) java.lang.ClassCastException: org.apache.activemq.store.kahadb.data.KahaTraceCommand cannot be cast to org.apache.activemq.store.kahadb.data.KahaAddMessageCommand

[Ron Koerner (JIRA)]

Ron Koerner created AMQ-4838:


 Summary: java.lang.ClassCastException: 
org.apache.activemq.store.kahadb.data.KahaTraceCommand cannot be cast to 
org.apache.activemq.store.kahadb.data.KahaAddMessageCommand
 Key: AMQ-4838
 URL: https://issues.apache.org/jira/browse/AMQ-4838
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0
 Environment: Standalone single ActiveMQ 5.8.0, Linux
Reporter: Ron Koerner
Priority: Critical


I got this exception out of the blue on a standalone ActiveMQ broker which was 
running for 8 days at that time. I set the priority to critical as we lost a 
lot of data due to this bug.

{code}
2013-10-29 16:09:54,439 ERROR on.cursors.AbstractStoreCursor - 
org.apache.activemq.broker.region.cursors.QueueStorePrefetch@261c44
:esf.deubait.ice,batchResetNeeded=false,storeHasMessages=true,size=41413,cacheEnabled=false,maxBatchSize:200
 - Failed to fill batc
h [ActiveMQ Transport: tcp:///10.254.98.20:36270@6909]
java.lang.RuntimeException: java.lang.ClassCastException: 
org.apache.activemq.store.kahadb.data.KahaTraceCommand cannot be cast to
 org.apache.activemq.store.kahadb.data.KahaAddMessageCommand
at 
org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:277)
 ~[activemq-broker
-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:110)
 ~[activemq-broker-5.8
.0.jar:5.8.0]
at 
org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
 [activemq-broker-5.8.0.jar:
5.8.0]
at 
org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1775) 
[activemq-broker-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2003) 
[activemq-broker-5.8.0.jar:5.8.0]
at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1491) 
[activemq-broker-5.8.0.jar:5.8.0]
at org.apache.activemq.broker.region.Queue.wakeup(Queue.java:1709) 
[activemq-broker-5.8.0.jar:5.8.0]
at org.apache.activemq.broker.region.Queue.messageSent(Queue.java:1704) 
[activemq-broker-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.region.Queue.doMessageSend(Queue.java:795) 
[activemq-broker-5.8.0.jar:5.8.0]
at org.apache.activemq.broker.region.Queue.send(Queue.java:721) 
[activemq-broker-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:406) 
[activemq-broker-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:392) 
[activemq-broker-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:282)
 [activemq-broker-5.8.0.jar:5.8.0]
at org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:129) 
[activemq-broker-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:96)
 [activemq-broker-5.8.0.j
ar:5.8.0]
at 
org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:317) 
[activemq-broker-5.8.0.jar:5.8.0]
at org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:129) 
[activemq-broker-5.8.0.jar:5.8.0]
at 
org.apache.activemq.security.AuthorizationBroker.send(AuthorizationBroker.java:202)
 [activemq-broker-5.8.0.jar:5.8.0]
at org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:129) 
[activemq-broker-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:135)
 [activemq-broker-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:499)
 [activemq-broker-5.8.0.jar:
5.8.0]
at 
org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:749) 
[activemq-client-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:329)
 [activemq-broker-5.8.0.jar:5.8.0]
at 
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:184)
 [activemq-broker-5.8.0.jar:5.8
.0]
at 
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50) 
[activemq-client-5.8.0.jar:5.8.0]
at 
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
 [activemq-client-5.8.0.jar:
5.8.0]
at 
org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:288)
 [activemq-client-
5.8.0.jar:5.8.0]
at 
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
 [activemq-client-5.8.0.jar:5.8.0]
at 
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214) 
[activemq-client-5.8.0.jar:5.8.0]
at 
org.apache.activemq.tr

Setting dead message to a specific queue at the same time discard expired message

[clar]

Hi, I wanted to set dead message to a specific queue, at the same time
discard expired message. Below is a snippet of my activemq.xml.


 
   
 
   
 
   
 
 
 
 
   
 
   


But however, the message does not seems to be discarded even though I  had
set time to live to 10 sec. It still goes to the specific DLQ. Any idea
where has gone wrong? Many thanks.

(My apology for hijacking another thread to post the above )



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Setting-dead-message-to-a-specific-queue-at-the-same-time-discard-expired-message-tp4673344.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

amq 5.9 Persistent queue bug

[jason peng]

i create 3 persistent queue:a1,a2,a3
bug :
a1 have 401 message(every message 1mb)
a2 have 1 message(message 1mb)
a3 have 1 message(message 1mb)
if start amq ,i first browse a1 at
webconsole(http://localhost:8161/admin),then i get 200 message, and next i
 browse a2 queue (Number Of Pending Messages  is 1),i will not get any
message.
and i found ,if i modify the section  in
activemq.xml,restart amq ,a1,a2,a3 browse a1,a2,a3 is ok

5.9 fixed:AMQ-4595 QueueBrowser hangs when browsing large queues,i guess fix
the quession,but lead the new bug.









--
View this message in context: 
http://activemq.2283324.n4.nabble.com/amq-5-9-Persistent-queue-bug-tp4673345.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] [Updated] (AMQ-4837) LevelDB corrupted in AMQ cluster

[Guillaume (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume updated AMQ-4837:
---

Attachment: LevelDBCorrupted.zip

Attached the ActiveMQ configuration and the logs of the 3 nodes. 
WRK01 is first elected as Master, then WRK02, then WRK03 (fails).


> LevelDB corrupted in AMQ cluster
> 
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper. 
> When performing some tests using Web UI, I can across issues that appears to 
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web 
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the 
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message 
> summary ok however when clicking on the queue, no message details. An error 
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error 
> occurs to each node infinitely (shutdown/restart). The only way around is to 
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t 
> occur.
> =
> Leveldb configuration on the 3 instances:
>   
>  directory="${activemq.data}/leveldb"
>   replicas="3"
>   bind="tcp://0.0.0.0:0"
>   zkAddress="zkserver:2181"
>   zkPath="/activemq/leveldb-stores"
>   />
>   
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at 
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at 
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at 
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at 
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at 
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at 
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at 
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at 
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at 
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at 
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at 
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
> at 
> org.apache.activemq.leveldb.LevelDBCl

[jira] [Created] (AMQ-4837) LevelDB corrupted in AMQ cluster

[Guillaume (JIRA)]

Guillaume created AMQ-4837:
--

 Summary: LevelDB corrupted in AMQ cluster
 Key: AMQ-4837
 URL: https://issues.apache.org/jira/browse/AMQ-4837
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-leveldb-store
Affects Versions: 5.9.0
 Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
zookeeper-3.4.5.2
Reporter: Guillaume
Priority: Critical


I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper. 
When performing some tests using Web UI, I can across issues that appears to 
corrupt the leveldb data files.

The issue can be replicated by performing the following steps:
1.  Start 3 activemq nodes.
2.  Push a message to the master (Node1) and browse the queue using the web 
UI
3.  Stop master node (Node1)
4.  Push a message to the new master (Node2) and browse the queue using the 
web UI. Message summary and queue content ok.
5.  Start Node1
6.  Stop master node (Node2)
7.  Browse the queue using the web UI on new master (Node3). Message 
summary ok however when clicking on the queue, no message details. An error 
(see below) is logged by the master, which attempts a restart.

>From this point, the database appears to be corrupted and the same error 
>occurs to each node infinitely (shutdown/restart). The only way around is to 
>stop the nodes and clear the data files.

However when a message is pushed between step 5 and 6, the error doesn’t occur.

=
Leveldb configuration on the 3 instances:




=
The error is:
INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
java.io.IOException
at 
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
at 
org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
at 
org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
at 
org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
at 
org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
at 
org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
   at 
org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
at 
org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
at 
org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
at 
org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
at 
org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
at 
org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
at 
org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
at 
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
at 
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NullPointerException
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1271)
at 
org.apache.activemq.leveldb.LevelDBClient$RichDB.check$4(LevelDBClient.scala:315)
at 
org.apache.activemq.leveldb.LevelDBClient$RichDB.cursorRange(LevelDBClient.scala:317)
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply$mcV$sp(LevelDBClient.scala:1271)
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1271)
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1271)
at 
org.apache.activemq.leveldb.LevelDBClient.usingIndex(LevelDBClient.scala:968)
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$might_fail_using_index$1.apply(LevelDBClient.scala:974)
at 
org.apache.act

[jira] [Updated] (AMQ-4399) jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4399:
-

Issue Type: Improvement  (was: Bug)

> jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery
> --
>
> Key: AMQ-4399
> URL: https://issues.apache.org/jira/browse/AMQ-4399
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.7.0
> Environment: 5.7.0.fuse-71-047
> MySQL with Journal
>Reporter: Jason Shepherd
> Fix For: 5.10.0
>
> Attachments: activemq.xml
>
>
> Using the attached configuration, we have configured JDBC persistence with a 
> journal. After sending 30,000 messages to a queue, using persistent messages, 
> we see that shutdown of the broker timeouts out and the process is killed by 
> the OS.
> After restarting the broker, a journal recovery takes place, which takes a 
> long time to complete. We would like to avoid such a long restart time in 
> this scenario.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4399) jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4399:
-

Fix Version/s: 5.10.0

> jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery
> --
>
> Key: AMQ-4399
> URL: https://issues.apache.org/jira/browse/AMQ-4399
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.7.0
> Environment: 5.7.0.fuse-71-047
> MySQL with Journal
>Reporter: Jason Shepherd
> Fix For: 5.10.0
>
> Attachments: activemq.xml
>
>
> Using the attached configuration, we have configured JDBC persistence with a 
> journal. After sending 30,000 messages to a queue, using persistent messages, 
> we see that shutdown of the broker timeouts out and the process is killed by 
> the OS.
> After restarting the broker, a journal recovery takes place, which takes a 
> long time to complete. We would like to avoid such a long restart time in 
> this scenario.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4399) jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809001#comment-13809001
 ] 

Claus Ibsen commented on AMQ-4399:
--

Thanks Gary

Lets try to implement this for next release.

> jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery
> --
>
> Key: AMQ-4399
> URL: https://issues.apache.org/jira/browse/AMQ-4399
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.7.0
> Environment: 5.7.0.fuse-71-047
> MySQL with Journal
>Reporter: Jason Shepherd
> Attachments: activemq.xml
>
>
> Using the attached configuration, we have configured JDBC persistence with a 
> journal. After sending 30,000 messages to a queue, using persistent messages, 
> we see that shutdown of the broker timeouts out and the process is killed by 
> the OS.
> After restarting the broker, a journal recovery takes place, which takes a 
> long time to complete. We would like to avoid such a long restart time in 
> this scenario.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4399) jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery

[Gary Tully (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808993#comment-13808993
 ] 

Gary Tully commented on AMQ-4399:
-

i think 
org.apache.activemq.store.journal.JournalPersistenceAdapter#checkpointInterval 
needs to be configurable so that the work done on close can be reduced.

> jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery
> --
>
> Key: AMQ-4399
> URL: https://issues.apache.org/jira/browse/AMQ-4399
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.7.0
> Environment: 5.7.0.fuse-71-047
> MySQL with Journal
>Reporter: Jason Shepherd
> Attachments: activemq.xml
>
>
> Using the attached configuration, we have configured JDBC persistence with a 
> journal. After sending 30,000 messages to a queue, using persistent messages, 
> we see that shutdown of the broker timeouts out and the process is killed by 
> the OS.
> After restarting the broker, a journal recovery takes place, which takes a 
> long time to complete. We would like to avoid such a long restart time in 
> this scenario.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4471) Inconsistent messages with the WebSocket/Stomp Demo

[JIRA]

[ 
https://issues.apache.org/jira/browse/AMQ-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808976#comment-13808976
 ] 

Matthias Weßendorf commented on AMQ-4471:
-

Don't see this this error any more. However, for the shake of I tried inserting 
this in the input element:
{code}
alert('hallo');
{code}

And it works :-) 

> Inconsistent messages with the WebSocket/Stomp Demo
> ---
>
> Key: AMQ-4471
> URL: https://issues.apache.org/jira/browse/AMQ-4471
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp, Transport
>Affects Versions: 5.8.0
>Reporter: Matthias Weßendorf
>Priority: Minor
>
> Playing with the "demo/websocket/index.html" demo (5.8.0), I see an 
> inconsistent messaging behavioir
> Having two browsers (FF and chrome) and not always the message receives the 
> other browser
> * TEST in FF => displayed in Chrome (and FF)
> * TEST (1) in Chrome => displayed in both
> * TEST (2) in Chrome => this time, only visible in Chrome; no message arrived 
> at the Firefox browser



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4476) ActiveMQ WebSphere 7 JMS Provider - MBD - message consumed even though transaction marked for rollback

[JIRA]

[ 
https://issues.apache.org/jira/browse/AMQ-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808960#comment-13808960
 ] 

Andrzej Więcław commented on AMQ-4476:
--

No, in fact I'm using AMQ as custom JMS provider.
I believe it could have something to do with DLQ concept.
Doesn't it work this way that rejected messages are moved to DLQ's? 
Could that behavior be modified so rejected message is rolled back to the 
original queue (instead of DLQ) and therefore stops processing of other 
awaiting messages?

> ActiveMQ WebSphere 7 JMS Provider - MBD - message consumed even though 
> transaction marked for rollback
> --
>
> Key: AMQ-4476
> URL: https://issues.apache.org/jira/browse/AMQ-4476
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.6.0, 5.7.0, 5.8.0
> Environment: Windows Server 2008 R2
>Reporter: Andrzej Więcław
>
> I have an EAR that is deployed to Websphere 7.
> It includes EJB module containing a couple of MDBs that are listening on 
> Message Listener Port, pointing to connection factory and queue exposed by 
> custom ActiveMQ JMS Provider.
> ActiveMQ JMS Provider configuration script (JACL):
> {code}
> import sys
> jmsProviderUrl = "tcp://x.x.x.x:61616"
> # Retrieve cell name
> cell = AdminControl.getCell()
> scope = "Cell=" + cell
> jmsProviderName = "ActiveMQ"
> node = sys.argv[0]
> server = sys.argv[1]
> # 
> # Add JMS Provider
> # 
> attributes = [["description", "ActiveMQ JMS Provider"], \
>   ["propertySet", [["resourceProperties", [ \
>[["name", 
> "java.naming.connectionFactoryNames"], ["type", "java.lang.String"], 
> ["value", "ConnectionFactory,XAConnectionFactory"]], \
>[["name", 
> "java.naming.queue.MXITEMIN"], ["type", "java.lang.String"], ["value", 
> "MX.ITEM.IN"]] \
>] \
> ]] \
>]]
> AdminJMS.createJMSProviderAtScope(scope, jmsProviderName, \
>   
> "org.apache.activemq.jndi.ActiveMQWASInitialContextFactory", \
>   jmsProviderUrl, attributes)
> # --
> # Add Connection Factory
> # --
> attributes = [["description", "ActiveMQ Queue Connection Factory"], \
>   ["type", "UNIFIED"], \
>   ["connectionPool", [ \
>   ["connectionTimeout", "1800"], \
>   ["maxConnections", "6"], \
>   ["minConnections", "0"], \
>   ["reapTime", "180"], \
>   ["unusedTimeout", "1800"], \
>   ["agedTimeout", "1800"], \
>   ["purgePolicy", "EntirePool"] \
>   ] \
>], \
>   ["sessionPool", [ \
>   ["connectionTimeout", "1800"], \
>   ["maxConnections", "1"], \
>   ["minConnections", "0"], \
>   ["reapTime", "10"], \
>   ["unusedTimeout", "1800"], \
>   ["agedTimeout", "1800"], \
>   ["purgePolicy", "EntirePool"] \
>   ] \
> ]]
> AdminJMS.createGenericJMSConnectionFactoryAtScope(scope, jmsProviderName, 
> "ACTIVEMQCF", \
>   "if/maximo/activemq/cf", 
> "XAConnectionFactory", \
>   attributes)
> # --
> # Add Queues
> # --
> # 1. MX.ASSET.IN
> attributes = [["description", "ActiveMQ ASSET Queue"], ["type", "QUEUE"]]
> AdminJMS.createGenericJMSDestinationAtScope(scope, jmsProviderName, 
> "MAXIMO04IN", \
> "if/maximo/activemq/q04cin", 
> "MXASSETIN", \
> attributes) 
> # ---
> # Create IF-server Message Listener Ports 
> # ---
> # PORTMAXIMO01IN
> attributes = [["description", "ActiveMQ Item"]]
> AdminServerManagement.configureListenerPortForMessageListenerService(node, 
> server, "PORTMAXIMO01IN", \
>  
> "if/maximo/activemq/cf", \
>  
> "if/maximo/activemq/q01c

[jira] [Commented] (AMQ-4471) Inconsistent messages with the WebSocket/Stomp Demo

[JIRA]

[ 
https://issues.apache.org/jira/browse/AMQ-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808948#comment-13808948
 ] 

Matthias Weßendorf commented on AMQ-4471:
-

sure

> Inconsistent messages with the WebSocket/Stomp Demo
> ---
>
> Key: AMQ-4471
> URL: https://issues.apache.org/jira/browse/AMQ-4471
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp, Transport
>Affects Versions: 5.8.0
>Reporter: Matthias Weßendorf
>Priority: Minor
>
> Playing with the "demo/websocket/index.html" demo (5.8.0), I see an 
> inconsistent messaging behavioir
> Having two browsers (FF and chrome) and not always the message receives the 
> other browser
> * TEST in FF => displayed in Chrome (and FF)
> * TEST (1) in Chrome => displayed in both
> * TEST (2) in Chrome => this time, only visible in Chrome; no message arrived 
> at the Firefox browser



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4367) ActiveMQXAConnectionFactory does not respect redelivery policy

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4367:
-

Fix Version/s: 5.10.0

> ActiveMQXAConnectionFactory does not respect redelivery policy
> --
>
> Key: AMQ-4367
> URL: https://issues.apache.org/jira/browse/AMQ-4367
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Affects Versions: 5.8.0
>Reporter: Pär Wenåker
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
> Attachments: ActiveMQXAConnectionFactoryTest.patch
>
>
> A redelivery policy set on an ActiveMQXAConnectionFactory is not respected. A 
> test that in ActiveMQXAConnectionFactoryTest is added in the attached 
> .patch-file.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4367) ActiveMQXAConnectionFactory does not respect redelivery policy

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4367:
-

Component/s: Test Cases
 Issue Type: Task  (was: Bug)

> ActiveMQXAConnectionFactory does not respect redelivery policy
> --
>
> Key: AMQ-4367
> URL: https://issues.apache.org/jira/browse/AMQ-4367
> Project: ActiveMQ
>  Issue Type: Task
>  Components: Test Cases
>Affects Versions: 5.8.0
>Reporter: Pär Wenåker
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
> Attachments: ActiveMQXAConnectionFactoryTest.patch
>
>
> A redelivery policy set on an ActiveMQXAConnectionFactory is not respected. A 
> test that in ActiveMQXAConnectionFactoryTest is added in the attached 
> .patch-file.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (AMQ-4367) ActiveMQXAConnectionFactory does not respect redelivery policy

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned AMQ-4367:


Assignee: Claus Ibsen

> ActiveMQXAConnectionFactory does not respect redelivery policy
> --
>
> Key: AMQ-4367
> URL: https://issues.apache.org/jira/browse/AMQ-4367
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Affects Versions: 5.8.0
>Reporter: Pär Wenåker
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
> Attachments: ActiveMQXAConnectionFactoryTest.patch
>
>
> A redelivery policy set on an ActiveMQXAConnectionFactory is not respected. A 
> test that in ActiveMQXAConnectionFactoryTest is added in the attached 
> .patch-file.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4399) jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808946#comment-13808946
 ] 

Claus Ibsen commented on AMQ-4399:
--

Is there more to this ticket? Or can it be closed?

> jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery
> --
>
> Key: AMQ-4399
> URL: https://issues.apache.org/jira/browse/AMQ-4399
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.7.0
> Environment: 5.7.0.fuse-71-047
> MySQL with Journal
>Reporter: Jason Shepherd
> Attachments: activemq.xml
>
>
> Using the attached configuration, we have configured JDBC persistence with a 
> journal. After sending 30,000 messages to a queue, using persistent messages, 
> we see that shutdown of the broker timeouts out and the process is killed by 
> the OS.
> After restarting the broker, a journal recovery takes place, which takes a 
> long time to complete. We would like to avoid such a long restart time in 
> this scenario.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4416) NoClassDefFoundError logged on DEBUG level

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808942#comment-13808942
 ] 

Claus Ibsen commented on AMQ-4416:
--

Maybe there is a initCause call needed on IOException or something.

> NoClassDefFoundError logged on DEBUG level
> --
>
> Key: AMQ-4416
> URL: https://issues.apache.org/jira/browse/AMQ-4416
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.8.0
> Environment: N/A
>Reporter: W.Mazur
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 5.10.0
>
>
> After upgrade from AMQ 5.5.0 to AMQ 5.8.0 my Client started to throw 
> EOFException. After long long time I've found the DEBUG information on Server 
> side, that Hawtbuf is missing. Such an information should be logged as an 
> error, not debug information.
> Full Stack trace:
> 2013-03-28 10:58:56,301 DEBUG 
> org.apache.activemq.broker.TransportConnection.serviceTransportException(TransportConnection.java:236):
>  Transport Connection to: tcp://XXX failed: java.io.IOException: Unexpected 
> error occured: java.lang.NoClassDefFoundError: 
> org/fusesource/hawtbuf/UTF8Buffer 
> java.io.IOException: Unexpected error occured: 
> java.lang.NoClassDefFoundError: org/fusesource/hawtbuf/UTF8Buffer
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NoClassDefFoundError: org/fusesource/hawtbuf/UTF8Buffer
>   at 
> org.apache.activemq.util.MarshallingSupport.readUTF(MarshallingSupport.java:229)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitive(MarshallingSupport.java:200)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitiveMap(MarshallingSupport.java:98)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitiveMap(MarshallingSupport.java:78)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitiveMap(MarshallingSupport.java:70)
>   at 
> org.apache.activemq.command.Message.unmarsallProperties(Message.java:217)
>   at org.apache.activemq.command.Message.getProperties(Message.java:185)
>   at org.apache.activemq.command.Message.toString(Message.java:810)
>   at org.apache.activemq.command.Message.toString(Message.java:804)
>   at 
> org.apache.activemq.command.ActiveMQTextMessage.toString(ActiveMQTextMessage.java:178)
>   at java.lang.String.valueOf(Unknown Source)
>   at java.lang.StringBuilder.append(Unknown Source)
>   at 
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:335)
>   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.SslTransport.doConsume(SslTransport.java:91)
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
>   ... 1 more



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4416) NoClassDefFoundError logged on DEBUG level

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4416:
-

Fix Version/s: 5.10.0

> NoClassDefFoundError logged on DEBUG level
> --
>
> Key: AMQ-4416
> URL: https://issues.apache.org/jira/browse/AMQ-4416
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.8.0
> Environment: N/A
>Reporter: W.Mazur
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 5.10.0
>
>
> After upgrade from AMQ 5.5.0 to AMQ 5.8.0 my Client started to throw 
> EOFException. After long long time I've found the DEBUG information on Server 
> side, that Hawtbuf is missing. Such an information should be logged as an 
> error, not debug information.
> Full Stack trace:
> 2013-03-28 10:58:56,301 DEBUG 
> org.apache.activemq.broker.TransportConnection.serviceTransportException(TransportConnection.java:236):
>  Transport Connection to: tcp://XXX failed: java.io.IOException: Unexpected 
> error occured: java.lang.NoClassDefFoundError: 
> org/fusesource/hawtbuf/UTF8Buffer 
> java.io.IOException: Unexpected error occured: 
> java.lang.NoClassDefFoundError: org/fusesource/hawtbuf/UTF8Buffer
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NoClassDefFoundError: org/fusesource/hawtbuf/UTF8Buffer
>   at 
> org.apache.activemq.util.MarshallingSupport.readUTF(MarshallingSupport.java:229)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitive(MarshallingSupport.java:200)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitiveMap(MarshallingSupport.java:98)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitiveMap(MarshallingSupport.java:78)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitiveMap(MarshallingSupport.java:70)
>   at 
> org.apache.activemq.command.Message.unmarsallProperties(Message.java:217)
>   at org.apache.activemq.command.Message.getProperties(Message.java:185)
>   at org.apache.activemq.command.Message.toString(Message.java:810)
>   at org.apache.activemq.command.Message.toString(Message.java:804)
>   at 
> org.apache.activemq.command.ActiveMQTextMessage.toString(ActiveMQTextMessage.java:178)
>   at java.lang.String.valueOf(Unknown Source)
>   at java.lang.StringBuilder.append(Unknown Source)
>   at 
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:335)
>   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.SslTransport.doConsume(SslTransport.java:91)
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
>   ... 1 more



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (AMQ-4425) Tomcat support in ActiveMQ

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved AMQ-4425.
--

   Resolution: Duplicate
Fix Version/s: 5.10.0
 Assignee: Claus Ibsen

> Tomcat support in ActiveMQ
> --
>
> Key: AMQ-4425
> URL: https://issues.apache.org/jira/browse/AMQ-4425
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: linux
>Reporter: Bhanu
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> The AjaxServlet is tightly coupled with Jetty due to Jetty continuations. Now 
> with Servlet 3.0 specification of suspendable requests, can something be done 
> to make ActiveMQ easily be plugged with other servlet containers like tomcat? 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4425) Tomcat support in ActiveMQ

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808943#comment-13808943
 ] 

Claus Ibsen commented on AMQ-4425:
--

There is a ticket about this also.

> Tomcat support in ActiveMQ
> --
>
> Key: AMQ-4425
> URL: https://issues.apache.org/jira/browse/AMQ-4425
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: linux
>Reporter: Bhanu
> Fix For: 5.10.0
>
>
> The AjaxServlet is tightly coupled with Jetty due to Jetty continuations. Now 
> with Servlet 3.0 specification of suspendable requests, can something be done 
> to make ActiveMQ easily be plugged with other servlet containers like tomcat? 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4434) AcitveMQ stop responding when OS running out of free disk space

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808939#comment-13808939
 ] 

Claus Ibsen commented on AMQ-4434:
--

There is some disk space left check in AMQ 5.9 on startup. You get a WARN 
logging if the broker does not have as much free space as configured to allow 
to use.

> AcitveMQ stop responding when OS running out of free disk space
> ---
>
> Key: AMQ-4434
> URL: https://issues.apache.org/jira/browse/AMQ-4434
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: RHEL 6.4 x64 bit
>Reporter: Andriy Kalashnykov
>
> AcitveMQ stop responding when OS running out of free disk space.
> Steps to reproduce: run ActiveMQ with almost no disk space left, use hdd to 
> the point that there is no more left. 
> This behavior directly affect HA: in my case, i have four instances of 
> ActiveMQ on different physical servers and ActiveMQ configured to share 
> Oracle DB. First server became master worked for a while and went down, then 
> second server (the one with little disk space left) became a master and 
> worked for a while, than it became unresponsive and all AcitveMQ cluster was 
> unaccessible. 
> I belive it's due the fact that on the box with little space ActiveMQ was 
> still running and perhaps preventing DB connection to be release for other 
> servers to use.  
> Suggestion: check disk space on start and periodically after start, once disk 
> space is low on none left - gracefully exit.
> Regards.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (AMQ-4416) NoClassDefFoundError logged on DEBUG level

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned AMQ-4416:


Assignee: Claus Ibsen

> NoClassDefFoundError logged on DEBUG level
> --
>
> Key: AMQ-4416
> URL: https://issues.apache.org/jira/browse/AMQ-4416
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.8.0
> Environment: N/A
>Reporter: W.Mazur
>Assignee: Claus Ibsen
>Priority: Minor
>
> After upgrade from AMQ 5.5.0 to AMQ 5.8.0 my Client started to throw 
> EOFException. After long long time I've found the DEBUG information on Server 
> side, that Hawtbuf is missing. Such an information should be logged as an 
> error, not debug information.
> Full Stack trace:
> 2013-03-28 10:58:56,301 DEBUG 
> org.apache.activemq.broker.TransportConnection.serviceTransportException(TransportConnection.java:236):
>  Transport Connection to: tcp://XXX failed: java.io.IOException: Unexpected 
> error occured: java.lang.NoClassDefFoundError: 
> org/fusesource/hawtbuf/UTF8Buffer 
> java.io.IOException: Unexpected error occured: 
> java.lang.NoClassDefFoundError: org/fusesource/hawtbuf/UTF8Buffer
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NoClassDefFoundError: org/fusesource/hawtbuf/UTF8Buffer
>   at 
> org.apache.activemq.util.MarshallingSupport.readUTF(MarshallingSupport.java:229)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitive(MarshallingSupport.java:200)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitiveMap(MarshallingSupport.java:98)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitiveMap(MarshallingSupport.java:78)
>   at 
> org.apache.activemq.util.MarshallingSupport.unmarshalPrimitiveMap(MarshallingSupport.java:70)
>   at 
> org.apache.activemq.command.Message.unmarsallProperties(Message.java:217)
>   at org.apache.activemq.command.Message.getProperties(Message.java:185)
>   at org.apache.activemq.command.Message.toString(Message.java:810)
>   at org.apache.activemq.command.Message.toString(Message.java:804)
>   at 
> org.apache.activemq.command.ActiveMQTextMessage.toString(ActiveMQTextMessage.java:178)
>   at java.lang.String.valueOf(Unknown Source)
>   at java.lang.StringBuilder.append(Unknown Source)
>   at 
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:335)
>   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.SslTransport.doConsume(SslTransport.java:91)
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
>   ... 1 more



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4109) Negative queue counters

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808937#comment-13808937
 ] 

Claus Ibsen commented on AMQ-4109:
--

Can you try with 5.9?

> Negative queue counters
> ---
>
> Key: AMQ-4109
> URL: https://issues.apache.org/jira/browse/AMQ-4109
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.7.0
>Reporter: Markus Hahn
>
> http://{server}:8161/admin/queues.jsp
> I get negative numbers in the "Number Of Pending Messages". Running a simple 
> PTP scenario, but am purging the queue right in the middle of the action.
> Below's the experiment. 5.7.0 was run out of the box on a CentOS 6.3 with 
> Java 6.
> _
> import javax.jms.Connection;
> import javax.jms.ConnectionFactory;
> import javax.jms.DeliveryMode;
> import javax.jms.Destination;
> import javax.jms.Message;
> import javax.jms.MessageConsumer;
> import javax.jms.MessageProducer;
> import javax.jms.Session;
> import javax.jms.TextMessage;
> import org.apache.activemq.ActiveMQConnection;
> import org.apache.activemq.ActiveMQConnectionFactory;
> public class PTPTest {
>   //static String _url = "failover://tcp://activemqtest:61616";
>   static String _url = ActiveMQConnection.DEFAULT_BROKER_URL;
>   
>   public void enqueue() throws Exception {
>   
>   Connection connection = null;
>   try 
>   {
>   System.out.println("enqueuing...");
>   
>   ConnectionFactory connectionFactory =
>new ActiveMQConnectionFactory(_url);
>   connection = connectionFactory.createConnection();
>   connection.start();
>   Session s = connection.createSession(false, 
> Session.CLIENT_ACKNOWLEDGE);
>   //Session s = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
>   Destination dest = s.createQueue("Q2");
>   MessageProducer mp = s.createProducer(dest);
>   mp.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
>   for(int num = 1; num <= 100;num++) {
>   String txt = "this is message #" + num;
>   TextMessage tmsg = s.createTextMessage(txt);
>   mp.send(tmsg);
>   Thread.sleep(10);
>   //System.out.printf(">>> %s\n", txt);   
>   }
>   }
>   finally {
>if (null != connection) {
>connection.close();
>}
>   }
>   }
>   
>   public void dequeue(int id) throws Exception {
>   
>   Connection connection = null;
>   
>   try {
>   ConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory(_url);
>   connection = connectionFactory.createConnection();
>   connection.start();
>   Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
>   Destination destination = session.createQueue("Q2");
>   MessageConsumer consumer = 
> session.createConsumer(destination);
>   for(;;) {
>   Message msg = consumer.receive();
>   TextMessage tmsg = (TextMessage)msg;
>   String txt = tmsg.getText();
>   System.out.printf("<<< [%d] '%s', %s, %s\n", 
>   id, txt, 
>   tmsg.getJMSMessageID(), 
>   tmsg.getJMSDestination());
>   Thread.sleep(1000);
>   }
>   }
>   finally {
>   connection.close();
>   }
>   }
>   
>   public void exec() throws Exception {
>   Thread ethrd, dthrds[];
>   ethrd = new Thread() {
>   public void run() {
>   try {
>   enqueue();
>   }
>   catch (Exception e) {
>   e.printStackTrace();
>   }
>   }
>   };
>   ethrd.start();
>   Thread.sleep(1000);
>   final int D_COUNT = 4;
>   dthrds = new Thread[D_COUNT];
>   for (int i = 0; i < dthrds.length; i++) {
>   final int ii = i;
>   dthrds[i] = new Thread() {
> 

[jira] [Commented] (AMQ-2748) Jboss Adapter Configuration : connection-factory datasource does not overload ra.xml

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808934#comment-13808934
 ] 

Claus Ibsen commented on AMQ-2748:
--

The RAR for ActiveMQ 5.9 has been improved/fixed. Can you try with that?

> Jboss Adapter Configuration : connection-factory datasource does not overload 
> ra.xml
> 
>
> Key: AMQ-2748
> URL: https://issues.apache.org/jira/browse/AMQ-2748
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: 5.3.2
>Reporter: Marc Schöchlin
>Priority: Critical
> Fix For: NEEDS_REVIEWED
>
>
> I defined a connection-facory datasource in jboss 5.1
> {code}
> 
>  PUBLIC "-//JBoss//DTD JBOSS JCA Config 1.5//EN"
> "http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd";>
> 
>
>   activemq/QueueConnectionFactory
>   
>   
>   activemq-rar-5.3.2.rar
>   
> javax.jms.QueueConnectionFactory
>   tcp://foo.bar.org:61616
>   
>   1
>   20
>   3
>   3
>
>  ...
>  ...
> 
> {code}
> My message driven beans are using this factory. The default 
> "tcp://localhost:61616", defined in activemq-ra-5.3.2.rar/META-INF/ra.xml, is 
> not overloaded.
> {code}
> 
> 
> org.apache.activemq.ra.ActiveMQResourceAdapter
> 
> 
>   The URL to the ActiveMQ server that you want this connection to 
> connect to.  If using
>   an embedded broker, this value should be 'vm://localhost'.
> 
> ServerUrl
> java.lang.String
> tcp://localhost:61616
> {code}
> My application never connects to "tcp://foo.bar.org:61616" until i configure 
> this in activemq-ra-5.3.2.rar/META-INF/ra.xml.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-2748) Jboss Adapter Configuration : connection-factory datasource does not overload ra.xml

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-2748:
-

Fix Version/s: (was: 5.x)
   NEEDS_REVIEWED

> Jboss Adapter Configuration : connection-factory datasource does not overload 
> ra.xml
> 
>
> Key: AMQ-2748
> URL: https://issues.apache.org/jira/browse/AMQ-2748
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: 5.3.2
>Reporter: Marc Schöchlin
> Fix For: NEEDS_REVIEWED
>
>
> I defined a connection-facory datasource in jboss 5.1
> {code}
> 
>  PUBLIC "-//JBoss//DTD JBOSS JCA Config 1.5//EN"
> "http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd";>
> 
>
>   activemq/QueueConnectionFactory
>   
>   
>   activemq-rar-5.3.2.rar
>   
> javax.jms.QueueConnectionFactory
>   tcp://foo.bar.org:61616
>   
>   1
>   20
>   3
>   3
>
>  ...
>  ...
> 
> {code}
> My message driven beans are using this factory. The default 
> "tcp://localhost:61616", defined in activemq-ra-5.3.2.rar/META-INF/ra.xml, is 
> not overloaded.
> {code}
> 
> 
> org.apache.activemq.ra.ActiveMQResourceAdapter
> 
> 
>   The URL to the ActiveMQ server that you want this connection to 
> connect to.  If using
>   an embedded broker, this value should be 'vm://localhost'.
> 
> ServerUrl
> java.lang.String
> tcp://localhost:61616
> {code}
> My application never connects to "tcp://foo.bar.org:61616" until i configure 
> this in activemq-ra-5.3.2.rar/META-INF/ra.xml.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-2748) Jboss Adapter Configuration : connection-factory datasource does not overload ra.xml

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-2748:
-

Priority: Major  (was: Critical)

> Jboss Adapter Configuration : connection-factory datasource does not overload 
> ra.xml
> 
>
> Key: AMQ-2748
> URL: https://issues.apache.org/jira/browse/AMQ-2748
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: 5.3.2
>Reporter: Marc Schöchlin
> Fix For: NEEDS_REVIEWED
>
>
> I defined a connection-facory datasource in jboss 5.1
> {code}
> 
>  PUBLIC "-//JBoss//DTD JBOSS JCA Config 1.5//EN"
> "http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd";>
> 
>
>   activemq/QueueConnectionFactory
>   
>   
>   activemq-rar-5.3.2.rar
>   
> javax.jms.QueueConnectionFactory
>   tcp://foo.bar.org:61616
>   
>   1
>   20
>   3
>   3
>
>  ...
>  ...
> 
> {code}
> My message driven beans are using this factory. The default 
> "tcp://localhost:61616", defined in activemq-ra-5.3.2.rar/META-INF/ra.xml, is 
> not overloaded.
> {code}
> 
> 
> org.apache.activemq.ra.ActiveMQResourceAdapter
> 
> 
>   The URL to the ActiveMQ server that you want this connection to 
> connect to.  If using
>   an embedded broker, this value should be 'vm://localhost'.
> 
> ServerUrl
> java.lang.String
> tcp://localhost:61616
> {code}
> My application never connects to "tcp://foo.bar.org:61616" until i configure 
> this in activemq-ra-5.3.2.rar/META-INF/ra.xml.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4471) Inconsistent messages with the WebSocket/Stomp Demo

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808932#comment-13808932
 ] 

Claus Ibsen commented on AMQ-4471:
--

Can you try to see if you can reproduce in AMQ 5.9 release?

> Inconsistent messages with the WebSocket/Stomp Demo
> ---
>
> Key: AMQ-4471
> URL: https://issues.apache.org/jira/browse/AMQ-4471
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp, Transport
>Affects Versions: 5.8.0
>Reporter: Matthias Weßendorf
>Priority: Minor
>
> Playing with the "demo/websocket/index.html" demo (5.8.0), I see an 
> inconsistent messaging behavioir
> Having two browsers (FF and chrome) and not always the message receives the 
> other browser
> * TEST in FF => displayed in Chrome (and FF)
> * TEST (1) in Chrome => displayed in both
> * TEST (2) in Chrome => this time, only visible in Chrome; no message arrived 
> at the Firefox browser



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4471) Inconsistent messages with the WebSocket/Stomp Demo

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4471:
-

Priority: Minor  (was: Major)

> Inconsistent messages with the WebSocket/Stomp Demo
> ---
>
> Key: AMQ-4471
> URL: https://issues.apache.org/jira/browse/AMQ-4471
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp, Transport
>Affects Versions: 5.8.0
>Reporter: Matthias Weßendorf
>Priority: Minor
>
> Playing with the "demo/websocket/index.html" demo (5.8.0), I see an 
> inconsistent messaging behavioir
> Having two browsers (FF and chrome) and not always the message receives the 
> other browser
> * TEST in FF => displayed in Chrome (and FF)
> * TEST (1) in Chrome => displayed in both
> * TEST (2) in Chrome => this time, only visible in Chrome; no message arrived 
> at the Firefox browser



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4476) ActiveMQ WebSphere 7 JMS Provider - MBD - message consumed even though transaction marked for rollback

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808931#comment-13808931
 ] 

Claus Ibsen commented on AMQ-4476:
--

Are you using the ActiveMQ RAR in WebSphere?

If so this RAR has been improved/fixed in AMQ 5.9 release. Can you give that a 
try?

> ActiveMQ WebSphere 7 JMS Provider - MBD - message consumed even though 
> transaction marked for rollback
> --
>
> Key: AMQ-4476
> URL: https://issues.apache.org/jira/browse/AMQ-4476
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.6.0, 5.7.0, 5.8.0
> Environment: Windows Server 2008 R2
>Reporter: Andrzej Więcław
>
> I have an EAR that is deployed to Websphere 7.
> It includes EJB module containing a couple of MDBs that are listening on 
> Message Listener Port, pointing to connection factory and queue exposed by 
> custom ActiveMQ JMS Provider.
> ActiveMQ JMS Provider configuration script (JACL):
> {code}
> import sys
> jmsProviderUrl = "tcp://x.x.x.x:61616"
> # Retrieve cell name
> cell = AdminControl.getCell()
> scope = "Cell=" + cell
> jmsProviderName = "ActiveMQ"
> node = sys.argv[0]
> server = sys.argv[1]
> # 
> # Add JMS Provider
> # 
> attributes = [["description", "ActiveMQ JMS Provider"], \
>   ["propertySet", [["resourceProperties", [ \
>[["name", 
> "java.naming.connectionFactoryNames"], ["type", "java.lang.String"], 
> ["value", "ConnectionFactory,XAConnectionFactory"]], \
>[["name", 
> "java.naming.queue.MXITEMIN"], ["type", "java.lang.String"], ["value", 
> "MX.ITEM.IN"]] \
>] \
> ]] \
>]]
> AdminJMS.createJMSProviderAtScope(scope, jmsProviderName, \
>   
> "org.apache.activemq.jndi.ActiveMQWASInitialContextFactory", \
>   jmsProviderUrl, attributes)
> # --
> # Add Connection Factory
> # --
> attributes = [["description", "ActiveMQ Queue Connection Factory"], \
>   ["type", "UNIFIED"], \
>   ["connectionPool", [ \
>   ["connectionTimeout", "1800"], \
>   ["maxConnections", "6"], \
>   ["minConnections", "0"], \
>   ["reapTime", "180"], \
>   ["unusedTimeout", "1800"], \
>   ["agedTimeout", "1800"], \
>   ["purgePolicy", "EntirePool"] \
>   ] \
>], \
>   ["sessionPool", [ \
>   ["connectionTimeout", "1800"], \
>   ["maxConnections", "1"], \
>   ["minConnections", "0"], \
>   ["reapTime", "10"], \
>   ["unusedTimeout", "1800"], \
>   ["agedTimeout", "1800"], \
>   ["purgePolicy", "EntirePool"] \
>   ] \
> ]]
> AdminJMS.createGenericJMSConnectionFactoryAtScope(scope, jmsProviderName, 
> "ACTIVEMQCF", \
>   "if/maximo/activemq/cf", 
> "XAConnectionFactory", \
>   attributes)
> # --
> # Add Queues
> # --
> # 1. MX.ASSET.IN
> attributes = [["description", "ActiveMQ ASSET Queue"], ["type", "QUEUE"]]
> AdminJMS.createGenericJMSDestinationAtScope(scope, jmsProviderName, 
> "MAXIMO04IN", \
> "if/maximo/activemq/q04cin", 
> "MXASSETIN", \
> attributes) 
> # ---
> # Create IF-server Message Listener Ports 
> # ---
> # PORTMAXIMO01IN
> attributes = [["description", "ActiveMQ Item"]]
> AdminServerManagement.configureListenerPortForMessageListenerService(node, 
> server, "PORTMAXIMO01IN", \
>  
> "if/maximo/activemq/cf", \
>  
> "if/maximo/activemq/q01cin", \
>  1, 5, 1, 
> attributes)
> {code}
> MDB code:
> {code}
> public class MQQueueListener implements MessageListener, MessageDrivenBean {
>   
>

[jira] [Resolved] (AMQ-2826) Look at the possibility of incorporating a cassandra persistence adapter from http://github.com/ticktock/qsandra

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved AMQ-2826.
--

   Resolution: Later
Fix Version/s: 5.10.0
 Assignee: Claus Ibsen

Seems like the project is dead, no update for 3 years.

> Look at the possibility of incorporating a cassandra persistence adapter from 
> http://github.com/ticktock/qsandra 
> -
>
> Key: AMQ-2826
> URL: https://issues.apache.org/jira/browse/AMQ-2826
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Message Store
>Affects Versions: 5.3.2
>Reporter: Scott Clasen
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> I am the author of http://github.com/ticktock/qsandra, which is a cassandra 
> persistence adapter for activemq. I am willing to donate it if it is 
> something that is of interest to ActiveMQ..
> Only current trouble with that is it needs JDK 1.6, so it would probably need 
> to wait until (if and when) ActiveMQ 5.x is built with JDK 6.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4742) 64-bit Java wrapper ignores wrapper.java.maxmemory values over 4096mb

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808929#comment-13808929
 ] 

Claus Ibsen commented on AMQ-4742:
--

Update the wiki page with better warning

> 64-bit Java wrapper ignores wrapper.java.maxmemory values over 4096mb
> -
>
> Key: AMQ-4742
> URL: https://issues.apache.org/jira/browse/AMQ-4742
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.5.0
> Environment: Red Hat Enterprise Linux Server release 5.7 (Tikanga)
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> ActiveMQ 5.5.0
>Reporter: Paul Lewis
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> When increasing the maximum memory available to ActiveMQ via the 
> wrapper.java.maxmemory parameter in wrapper.conf, any values above 4096mb are 
> ignored, and ActiveMQ defaults to 4096mb. I have also tried passing in a 
> custom 'wrapper.java.additional' parameter to set the -Xmx parameter, but 
> this also gets ignored.
> The issue is well documented at this blog: 
> http://www.evanhoffman.com/evan/2013/08/13/java-wrapper-does-whatever-it-wants/
> This is a fairly major issue at it prevents ActiveMQ scaling to memory 
> capacities above 4GB, which in turn limits the number of messages we can 
> effectively store on a single queue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4742) 64-bit Java wrapper ignores wrapper.java.maxmemory values over 4096mb

[Paul Lewis (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808928#comment-13808928
 ] 

Paul Lewis commented on AMQ-4742:
-

I'm not sure how I can make this any clearer - I'm not interested in running 
this on Windows!

The ticket I've raised specifically refers to the 64-bit wrapper on Linux. Can 
you please comment on whether the linux 64-bit wrapper will be fixed to support 
more than 4GB of RAM, or whether we will need to look for a paid 
version/alternative queue service?

Thanks,

Paul

> 64-bit Java wrapper ignores wrapper.java.maxmemory values over 4096mb
> -
>
> Key: AMQ-4742
> URL: https://issues.apache.org/jira/browse/AMQ-4742
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.5.0
> Environment: Red Hat Enterprise Linux Server release 5.7 (Tikanga)
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> ActiveMQ 5.5.0
>Reporter: Paul Lewis
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> When increasing the maximum memory available to ActiveMQ via the 
> wrapper.java.maxmemory parameter in wrapper.conf, any values above 4096mb are 
> ignored, and ActiveMQ defaults to 4096mb. I have also tried passing in a 
> custom 'wrapper.java.additional' parameter to set the -Xmx parameter, but 
> this also gets ignored.
> The issue is well documented at this blog: 
> http://www.evanhoffman.com/evan/2013/08/13/java-wrapper-does-whatever-it-wants/
> This is a fairly major issue at it prevents ActiveMQ scaling to memory 
> capacities above 4GB, which in turn limits the number of messages we can 
> effectively store on a single queue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (AMQ-4742) 64-bit Java wrapper ignores wrapper.java.maxmemory values over 4096mb

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808926#comment-13808926
 ] 

Claus Ibsen commented on AMQ-4742:
--

You need to buy a license for the wrapper if you want to use it with Windows. 
Or upgrade to newer release of wrapper yourself, as we cannot distribute a 
newer release because they changed the license terms, so ASF does not allow 
included that in their releases.



> 64-bit Java wrapper ignores wrapper.java.maxmemory values over 4096mb
> -
>
> Key: AMQ-4742
> URL: https://issues.apache.org/jira/browse/AMQ-4742
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.5.0
> Environment: Red Hat Enterprise Linux Server release 5.7 (Tikanga)
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> ActiveMQ 5.5.0
>Reporter: Paul Lewis
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
>
> When increasing the maximum memory available to ActiveMQ via the 
> wrapper.java.maxmemory parameter in wrapper.conf, any values above 4096mb are 
> ignored, and ActiveMQ defaults to 4096mb. I have also tried passing in a 
> custom 'wrapper.java.additional' parameter to set the -Xmx parameter, but 
> this also gets ignored.
> The issue is well documented at this blog: 
> http://www.evanhoffman.com/evan/2013/08/13/java-wrapper-does-whatever-it-wants/
> This is a fairly major issue at it prevents ActiveMQ scaling to memory 
> capacities above 4GB, which in turn limits the number of messages we can 
> effectively store on a single queue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQ-4545) ActiveMQ Ajax API does not provide support for setting JMS properties.

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated AMQ-4545:
-

Component/s: Transport
   Priority: Minor  (was: Major)

> ActiveMQ Ajax API does not provide support for setting JMS properties.
> --
>
> Key: AMQ-4545
> URL: https://issues.apache.org/jira/browse/AMQ-4545
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 5.8.0
>Reporter: Bhanu
>Priority: Minor
>
> ActiveMQ Ajax API i.e amq.js does not have any support for setting message 
> properties. The sendMessage() call accepts only two parameters:- destination 
> and message. Can this be enhanced to support sending message properties like 
> JMSReplyTo, JMSCorrelationID etc.
> Thanks,
> Bhanu



--
This message was sent by Atlassian JIRA
(v6.1#6144)