[jira] [Commented] (AMQ-4830) ActiveMQ Mbeans do not show attributes consistently

2013-10-30 Thread Bhanu (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808802#comment-13808802
 ] 

Bhanu commented on AMQ-4830:


Ping !!

 ActiveMQ Mbeans do not show attributes consistently
 ---

 Key: AMQ-4830
 URL: https://issues.apache.org/jira/browse/AMQ-4830
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker, JMX
Affects Versions: 5.8.0, 5.9.0
 Environment: Linux
Reporter: Bhanu
 Attachments: jconsole_mbeans.PNG


 Hi,
 ActiveMQ Queues and Topics mbeans do not show the attributes consistently. 
 What I mean to say is if you would see the attached jconsole snippet, you 
 would find that some queues have attributes and operations, some have 
 attributes, operations and consumers but some have *only consumers* ! I use 
 the activemq-admin utility to retrieve these mbeans and the fact that not 
 every queue (or topic) has an attribute affects a lot of my scripts.
 Can somebody please fix this or at least provide a plausible explanation for 
 this weird behavior ?
 Thanks,
 Bhanu



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


[jira] [Assigned] (AMQ-4833) Unable to install the feature activemq-blueprint in Karaf 2.3.3

2013-10-30 Thread JIRA

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

Jean-Baptiste Onofré reassigned AMQ-4833:
-

Assignee: Jean-Baptiste Onofré

 Unable to install the feature activemq-blueprint in Karaf 2.3.3
 ---

 Key: AMQ-4833
 URL: https://issues.apache.org/jira/browse/AMQ-4833
 Project: ActiveMQ
  Issue Type: Improvement
Affects Versions: 5.9.0, 5.10.0
 Environment: CentOS 6.4, Java 7 Update 45, Karaf 2.3.3
Reporter: Andreas Gies
Assignee: Jean-Baptiste Onofré
Priority: Minor

 Hi,
 with Active MQ 5.9.0 and 5.10-SNAPSHOT I was encountering a problem when I 
 tried to install the activemq-blueprint feature into a Karaf 2.3.3 container.
 The error message was
 Error executing command: URL 
 [mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.scala-library/2.9.1_3]
  could not be resolved
 My container was able to resolve all other bundles from maven central, this 
 was the only one failing. 
 Best regards
 Andreas



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


[jira] [Commented] (AMQ-4833) Unable to install the feature activemq-blueprint in Karaf 2.3.3

2013-10-30 Thread Freeman Fang (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808822#comment-13808822
 ] 

Freeman Fang commented on AMQ-4833:
---

Hi,

Figured out that if it's HttpURLConnection, some http server need User-Agent 
http header.
need fix it in OPS4J Base project, create BASE-48[1] to track it there

[1]https://ops4j1.jira.com/browse/BASE-48

Cheers
Freeman

 Unable to install the feature activemq-blueprint in Karaf 2.3.3
 ---

 Key: AMQ-4833
 URL: https://issues.apache.org/jira/browse/AMQ-4833
 Project: ActiveMQ
  Issue Type: Improvement
Affects Versions: 5.9.0, 5.10.0
 Environment: CentOS 6.4, Java 7 Update 45, Karaf 2.3.3
Reporter: Andreas Gies
Assignee: Jean-Baptiste Onofré
Priority: Minor

 Hi,
 with Active MQ 5.9.0 and 5.10-SNAPSHOT I was encountering a problem when I 
 tried to install the activemq-blueprint feature into a Karaf 2.3.3 container.
 The error message was
 Error executing command: URL 
 [mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.scala-library/2.9.1_3]
  could not be resolved
 My container was able to resolve all other bundles from maven central, this 
 was the only one failing. 
 Best regards
 Andreas



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


[jira] [Created] (AMQ-4834) Unable to create the native threads while using apache activemq

2013-10-30 Thread sheshasai (JIRA)
sheshasai created AMQ-4834:
--

 Summary: Unable to create the native threads while using apache 
activemq
 Key: AMQ-4834
 URL: https://issues.apache.org/jira/browse/AMQ-4834
 Project: ActiveMQ
  Issue Type: Bug
Reporter: sheshasai


Oct 11, 2013 5:19:49 PM sun.rmi.transport.tcp.TCPTransport$AcceptLoop 
executeAcceptLoop
WARNING: RMI TCP Accept-0: accept loop for 
ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=58864] throws
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at 
java.util.concurrent.ThreadPoolExecutor.addIfUnderMaximumPoolSize(Unknown 
Source)
at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source)
at 
sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)



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


[jira] [Commented] (AMQ-4834) Unable to create the native threads while using apache activemq

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808827#comment-13808827
 ] 

Claus Ibsen commented on AMQ-4834:
--

Your JVM is running out of memory. This is not a bug in ActiveMQ.

And you should use the mailing list / user forum for this kind of help. Not 
this JIRA tracker.
http://activemq.apache.org/discussion-forums.html
http://activemq.apache.org/mailing-lists.html

 Unable to create the native threads while using apache activemq
 ---

 Key: AMQ-4834
 URL: https://issues.apache.org/jira/browse/AMQ-4834
 Project: ActiveMQ
  Issue Type: Bug
Reporter: sheshasai

 Oct 11, 2013 5:19:49 PM sun.rmi.transport.tcp.TCPTransport$AcceptLoop 
 executeAcceptLoop
 WARNING: RMI TCP Accept-0: accept loop for 
 ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=58864] throws
 java.lang.OutOfMemoryError: unable to create new native thread
   at java.lang.Thread.start0(Native Method)
   at java.lang.Thread.start(Unknown Source)
   at 
 java.util.concurrent.ThreadPoolExecutor.addIfUnderMaximumPoolSize(Unknown 
 Source)
   at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source)
   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown 
 Source)
   at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)



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


[jira] [Resolved] (AMQ-4834) Unable to create the native threads while using apache activemq

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved AMQ-4834.
--

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

 Unable to create the native threads while using apache activemq
 ---

 Key: AMQ-4834
 URL: https://issues.apache.org/jira/browse/AMQ-4834
 Project: ActiveMQ
  Issue Type: Bug
Reporter: sheshasai
Assignee: Claus Ibsen
 Fix For: 5.10.0


 Oct 11, 2013 5:19:49 PM sun.rmi.transport.tcp.TCPTransport$AcceptLoop 
 executeAcceptLoop
 WARNING: RMI TCP Accept-0: accept loop for 
 ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=58864] throws
 java.lang.OutOfMemoryError: unable to create new native thread
   at java.lang.Thread.start0(Native Method)
   at java.lang.Thread.start(Unknown Source)
   at 
 java.util.concurrent.ThreadPoolExecutor.addIfUnderMaximumPoolSize(Unknown 
 Source)
   at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source)
   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown 
 Source)
   at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)



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


[jira] [Updated] (AMQ-4828) Bug in web console

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4828:
-

Priority: Minor  (was: Critical)

 Bug in web console
 --

 Key: AMQ-4828
 URL: https://issues.apache.org/jira/browse/AMQ-4828
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.0
 Environment: Karaf 2.3.3, Java 1.6.0.45 x64, Windows 7 Pro x64 
Reporter: brat
Priority: Minor
  Labels: web-console
 Attachments: error.txt


 I think I discovered a bug in activemq-web-console under karaf (not sure
 if it exists in the standalone amq).
 When you try to open http://localhost:8181/activemqweb/connections.jsp it will
 show Error! and Exception occurred while processing this request, check 
 the log for more information!.
 Stack trace attached. Seems like networkTTL property cannot be found for some 
 reason?



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


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

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4832:
-

Fix Version/s: 5.10.0

 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


 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)


[jira] [Commented] (AMQ-4828) Bug in web console

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808828#comment-13808828
 ] 

Claus Ibsen commented on AMQ-4828:
--

The old web console is deprecated. You can try the new hawtio console instead.

features:choose hawtio 1.2-M25
features:install hawtio

And then access localhost:8181/hawtio for this console.



 Bug in web console
 --

 Key: AMQ-4828
 URL: https://issues.apache.org/jira/browse/AMQ-4828
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.0
 Environment: Karaf 2.3.3, Java 1.6.0.45 x64, Windows 7 Pro x64 
Reporter: brat
Priority: Minor
  Labels: web-console
 Attachments: error.txt


 I think I discovered a bug in activemq-web-console under karaf (not sure
 if it exists in the standalone amq).
 When you try to open http://localhost:8181/activemqweb/connections.jsp it will
 show Error! and Exception occurred while processing this request, check 
 the log for more information!.
 Stack trace attached. Seems like networkTTL property cannot be found for some 
 reason?



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


[jira] [Commented] (AMQ-4813) Viewing message details when message ID contains a plus results in No message could be found for ID {messageID}

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808833#comment-13808833
 ] 

Claus Ibsen commented on AMQ-4813:
--

Are you using a custom uuid on AMQ that uses + signs in the id?

The old web console is deprecated in favor of the new hawtio console from 5.9 
onwards. You can try using that to browse/view your messages. 

 Viewing message details when message ID contains a plus results in  No 
 message could be found for ID {messageID}
 --

 Key: AMQ-4813
 URL: https://issues.apache.org/jira/browse/AMQ-4813
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0
Reporter: Michael Bildner
Priority: Minor

 Steps to reproduce:
 # Using the admin console, go to the Queues page.
 # Click on one of the queues to get to the queue's browse page.
 # Click on a message ID that contains a plus sign (+).
 Expected:
 See the message's headers, properties, actions, and details.
 Actual:
 Get a page with the error message No message could be found for ID 
 {messageID}, where {messageID} contains the message ID clicked on.  Note 
 that the message ID displayed in the error message replaces the plus sign (+) 
 with a space.
 Underlying cause:
 The html link that is created for each message ID in the queue's browse page 
 does not properly URL encode the message ID.  In my particular example, the 
 link for message ID AgXkceW74zCq+kZB1llPos1QcmTfOziGAmWRuk1forI= is:
 
 http://localhost:8161/admin/message.jsp?id=AgXkceW74zCq{color:red}+{color}kZB1llPos1QcmTfOziGAmWRuk1forI=JMSDestination=AMQPTest
 when it should be:
 
 http://localhost:8161/admin/message.jsp?id=AgXkceW74zCq{color:red}%2B{color}kZB1llPos1QcmTfOziGAmWRuk1forI=JMSDestination=AMQPTest
 The trouble area is shown with a red font.



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


[jira] [Updated] (AMQ-4813) webconsole - Viewing message details when message ID contains a plus results in No message could be found for ID {messageID}

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4813:
-

Summary: webconsole - Viewing message details when message ID contains a 
plus results in  No message could be found for ID {messageID}  (was: Viewing 
message details when message ID contains a plus results in  No message could 
be found for ID {messageID})

 webconsole - Viewing message details when message ID contains a plus results 
 in  No message could be found for ID {messageID}
 ---

 Key: AMQ-4813
 URL: https://issues.apache.org/jira/browse/AMQ-4813
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0
Reporter: Michael Bildner
Priority: Minor

 Steps to reproduce:
 # Using the admin console, go to the Queues page.
 # Click on one of the queues to get to the queue's browse page.
 # Click on a message ID that contains a plus sign (+).
 Expected:
 See the message's headers, properties, actions, and details.
 Actual:
 Get a page with the error message No message could be found for ID 
 {messageID}, where {messageID} contains the message ID clicked on.  Note 
 that the message ID displayed in the error message replaces the plus sign (+) 
 with a space.
 Underlying cause:
 The html link that is created for each message ID in the queue's browse page 
 does not properly URL encode the message ID.  In my particular example, the 
 link for message ID AgXkceW74zCq+kZB1llPos1QcmTfOziGAmWRuk1forI= is:
 
 http://localhost:8161/admin/message.jsp?id=AgXkceW74zCq{color:red}+{color}kZB1llPos1QcmTfOziGAmWRuk1forI=JMSDestination=AMQPTest
 when it should be:
 
 http://localhost:8161/admin/message.jsp?id=AgXkceW74zCq{color:red}%2B{color}kZB1llPos1QcmTfOziGAmWRuk1forI=JMSDestination=AMQPTest
 The trouble area is shown with a red font.



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


[jira] [Updated] (AMQ-4828) Bug in web console

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4828:
-

Component/s: webconsole

 Bug in web console
 --

 Key: AMQ-4828
 URL: https://issues.apache.org/jira/browse/AMQ-4828
 Project: ActiveMQ
  Issue Type: Bug
  Components: webconsole
Affects Versions: 5.9.0
 Environment: Karaf 2.3.3, Java 1.6.0.45 x64, Windows 7 Pro x64 
Reporter: brat
Priority: Minor
  Labels: web-console
 Attachments: error.txt


 I think I discovered a bug in activemq-web-console under karaf (not sure
 if it exists in the standalone amq).
 When you try to open http://localhost:8181/activemqweb/connections.jsp it will
 show Error! and Exception occurred while processing this request, check 
 the log for more information!.
 Stack trace attached. Seems like networkTTL property cannot be found for some 
 reason?



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


[jira] [Updated] (AMQ-4813) webconsole - Viewing message details when message ID contains a plus results in No message could be found for ID {messageID}

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4813:
-

Component/s: webconsole

 webconsole - Viewing message details when message ID contains a plus results 
 in  No message could be found for ID {messageID}
 ---

 Key: AMQ-4813
 URL: https://issues.apache.org/jira/browse/AMQ-4813
 Project: ActiveMQ
  Issue Type: Bug
  Components: webconsole
Affects Versions: 5.8.0
Reporter: Michael Bildner
Priority: Minor

 Steps to reproduce:
 # Using the admin console, go to the Queues page.
 # Click on one of the queues to get to the queue's browse page.
 # Click on a message ID that contains a plus sign (+).
 Expected:
 See the message's headers, properties, actions, and details.
 Actual:
 Get a page with the error message No message could be found for ID 
 {messageID}, where {messageID} contains the message ID clicked on.  Note 
 that the message ID displayed in the error message replaces the plus sign (+) 
 with a space.
 Underlying cause:
 The html link that is created for each message ID in the queue's browse page 
 does not properly URL encode the message ID.  In my particular example, the 
 link for message ID AgXkceW74zCq+kZB1llPos1QcmTfOziGAmWRuk1forI= is:
 
 http://localhost:8161/admin/message.jsp?id=AgXkceW74zCq{color:red}+{color}kZB1llPos1QcmTfOziGAmWRuk1forI=JMSDestination=AMQPTest
 when it should be:
 
 http://localhost:8161/admin/message.jsp?id=AgXkceW74zCq{color:red}%2B{color}kZB1llPos1QcmTfOziGAmWRuk1forI=JMSDestination=AMQPTest
 The trouble area is shown with a red font.



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


[jira] [Resolved] (AMQ-4809) activemq:dstat - Sort list of queues/topics by default

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved AMQ-4809.
--

Resolution: Fixed

dstat now sorts

 activemq:dstat - Sort list of queues/topics by default
 --

 Key: AMQ-4809
 URL: https://issues.apache.org/jira/browse/AMQ-4809
 Project: ActiveMQ
  Issue Type: Improvement
  Components: OSGi/Karaf
Affects Versions: 5.9.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Priority: Minor
 Fix For: 5.10.0


 We should sort the queue names out of the box, so they are listed A..Z.
 Today you can get
 {code}
 karaf@root activemq:dstat queues
 NameQueue Size  Producer #  
 Consumer #   Enqueue #   Dequeue #Memory %
 wine 0   0
0   0   0   0
 beer 1   0
0   1   0   0
 {code}
 And its not even the creation order, as beer queue was created before wine.



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


[jira] [Updated] (AMQ-4814) Memory leak when unsubscribing durable consumer

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4814:
-

Fix Version/s: 5.10.0

 Memory leak when unsubscribing durable consumer
 ---

 Key: AMQ-4814
 URL: https://issues.apache.org/jira/browse/AMQ-4814
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.8.0
Reporter: jok
  Labels: broker, durable_subscription, memory_leak
 Fix For: 5.10.0

 Attachments: DurableSubscriberLeakDemo.java, 
 StoreDurableSubscriberCursor.diff


 When creating and closing durable subscribers, references to 
 FilePendingMessageCursor in MemoryUsage.listeners are not cleaned up.
 The reason seems to be a missing call to FilePendingMessageCursor.destroy() 
 in StoreDurableSubscriberCursor.stop().
 A simple demo to reproduce the issue is attached (the leak is clearly visible 
 after a few hundred to thousand runs). Also, i have attached a patch which 
 resolves this issue for me - could someone check if this is correct?



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


[jira] [Resolved] (AMQ-4794) activemq web console fails in karaf+equinox

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved AMQ-4794.
--

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

 activemq web console fails in karaf+equinox
 ---

 Key: AMQ-4794
 URL: https://issues.apache.org/jira/browse/AMQ-4794
 Project: ActiveMQ
  Issue Type: Bug
  Components: OSGi/Karaf, webconsole
Affects Versions: 5.8.0, 5.9.0
 Environment: Linux 64-bit, Oracle JDK 7u40, Karaf 2.3.3
Reporter: Amichai Rothman
Assignee: Claus Ibsen
 Fix For: 5.10.0


 The web console fails when using equinox.
 Steps to reproduce:
 1. Extract a stock karaf 2.3.3 installation.
 2. Set karaf.framework=equinox in etc/config.properties.
 3. Start karaf.
 4. Add the activemq feature url (5.8.0 or 5.9-SNAPSHOT).
 5. Install the activemq-broker feature.
 6. Browse to http://localhost:8181/activemqweb and see the error page.
 The karaf log shows the stack trace below.
 btw two of the links on the error page are broken, linking to 
 http://localhost:8181/admin and /demo which are invalid even when the web 
 console does work.
 javax.el.ELException: java.lang.RuntimeException: java.io.IOException: Failed 
 to retrieve RMIServer stub: javax.naming.CommunicationException [Root 
 exception is java.rmi.UnmarshalException: error unmarshalling return; nested 
 exception is:java.lang.ClassNotFoundException: 
 javax.management.remote.rmi.RMIServerImpl_Stub (no security manager: RMI 
 class loader disabled)]
 at 
 javax.el.BeanELResolver.getValue(BeanELResolver.java:298)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 com.sun.el.parser.AstValue.getValue(AstValue.java:138)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:1001)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.apache.jsp.index_jsp._jspService(org.apache.jsp.index_jsp:51)[file:/home/amichai/apps/itrade/apache-karaf-2.3.3/data/pax-web-jsp/activemqweb/:]
 at 
 org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 javax.servlet.http.HttpServlet.service(HttpServlet.java:806)[69:org.apache.geronimo.specs.geronimo-servlet_2.5_spec:1.2]
 at 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:389)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 javax.servlet.http.HttpServlet.service(HttpServlet.java:806)[69:org.apache.geronimo.specs.geronimo-servlet_2.5_spec:1.2]
 at 
 org.ops4j.pax.web.jsp.JspServletWrapper$2.call(JspServletWrapper.java:144)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.ops4j.pax.web.jsp.JspServletWrapper$2.call(JspServletWrapper.java:139)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.ops4j.pax.web.jsp.JspServletWrapper.service(JspServletWrapper.java:136)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652)[79:org.eclipse.jetty.servlet:7.6.8.v20121106]
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1329)[79:org.eclipse.jetty.servlet:7.6.8.v20121106]
 at 
 org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83)[107:org.apache.activemq.activemq-web-console:5.8.0]
 at 
 org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)[107:org.apache.activemq.activemq-web-console:5.8.0]
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300)[79:org.eclipse.jetty.servlet:7.6.8.v20121106]
 at 
 org.apache.activemq.web.SessionFilter.doFilter(SessionFilter.java:45)[107:org.apache.activemq.activemq-web-console:5.8.0]
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300)[79:org.eclipse.jetty.servlet:7.6.8.v20121106]
 at 
 

[jira] [Updated] (AMQ-4794) activemq web console fails in karaf+equinox

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4794:
-

Component/s: webconsole

 activemq web console fails in karaf+equinox
 ---

 Key: AMQ-4794
 URL: https://issues.apache.org/jira/browse/AMQ-4794
 Project: ActiveMQ
  Issue Type: Bug
  Components: OSGi/Karaf, webconsole
Affects Versions: 5.8.0, 5.9.0
 Environment: Linux 64-bit, Oracle JDK 7u40, Karaf 2.3.3
Reporter: Amichai Rothman
 Fix For: 5.10.0


 The web console fails when using equinox.
 Steps to reproduce:
 1. Extract a stock karaf 2.3.3 installation.
 2. Set karaf.framework=equinox in etc/config.properties.
 3. Start karaf.
 4. Add the activemq feature url (5.8.0 or 5.9-SNAPSHOT).
 5. Install the activemq-broker feature.
 6. Browse to http://localhost:8181/activemqweb and see the error page.
 The karaf log shows the stack trace below.
 btw two of the links on the error page are broken, linking to 
 http://localhost:8181/admin and /demo which are invalid even when the web 
 console does work.
 javax.el.ELException: java.lang.RuntimeException: java.io.IOException: Failed 
 to retrieve RMIServer stub: javax.naming.CommunicationException [Root 
 exception is java.rmi.UnmarshalException: error unmarshalling return; nested 
 exception is:java.lang.ClassNotFoundException: 
 javax.management.remote.rmi.RMIServerImpl_Stub (no security manager: RMI 
 class loader disabled)]
 at 
 javax.el.BeanELResolver.getValue(BeanELResolver.java:298)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 com.sun.el.parser.AstValue.getValue(AstValue.java:138)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:1001)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.apache.jsp.index_jsp._jspService(org.apache.jsp.index_jsp:51)[file:/home/amichai/apps/itrade/apache-karaf-2.3.3/data/pax-web-jsp/activemqweb/:]
 at 
 org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 javax.servlet.http.HttpServlet.service(HttpServlet.java:806)[69:org.apache.geronimo.specs.geronimo-servlet_2.5_spec:1.2]
 at 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:389)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 javax.servlet.http.HttpServlet.service(HttpServlet.java:806)[69:org.apache.geronimo.specs.geronimo-servlet_2.5_spec:1.2]
 at 
 org.ops4j.pax.web.jsp.JspServletWrapper$2.call(JspServletWrapper.java:144)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.ops4j.pax.web.jsp.JspServletWrapper$2.call(JspServletWrapper.java:139)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.ops4j.pax.web.jsp.JspServletWrapper.service(JspServletWrapper.java:136)[102:org.ops4j.pax.web.pax-web-jsp:1.1.14]
 at 
 org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652)[79:org.eclipse.jetty.servlet:7.6.8.v20121106]
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1329)[79:org.eclipse.jetty.servlet:7.6.8.v20121106]
 at 
 org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83)[107:org.apache.activemq.activemq-web-console:5.8.0]
 at 
 org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)[107:org.apache.activemq.activemq-web-console:5.8.0]
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300)[79:org.eclipse.jetty.servlet:7.6.8.v20121106]
 at 
 org.apache.activemq.web.SessionFilter.doFilter(SessionFilter.java:45)[107:org.apache.activemq.activemq-web-console:5.8.0]
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300)[79:org.eclipse.jetty.servlet:7.6.8.v20121106]
 at 
 org.apache.activemq.web.filter.ApplicationContextFilter.doFilter(ApplicationContextFilter.java:102)[107:org.apache.activemq.activemq-web-console:5.8.0]
 at 
 

[jira] [Updated] (AMQ-4767) Extend ActiveMQ Camel component to support INDIVIDUAL_MESSAGE ack mode

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4767:
-

Fix Version/s: 5.10.0

Yeah sounds like a nice extension to activemq-camel. So I assume we would need 
to add some Camel UoW done that will call message.acknowledge() to ack the 
message when Camel is done routing the message.

 Extend ActiveMQ Camel component to support INDIVIDUAL_MESSAGE ack mode
 --

 Key: AMQ-4767
 URL: https://issues.apache.org/jira/browse/AMQ-4767
 Project: ActiveMQ
  Issue Type: New Feature
  Components: activemq-camel
Affects Versions: 5.8.0
 Environment: All
Reporter: Matt Pavlovich
 Fix For: 5.10.0


 It would be really helpful to have a per-message acknowledgement that did not 
 acknowledge all previous messages.. this would be an ActiveMQ-only 
 acknowledgement mode.
 Really handy for Camel to do things like 
  from: activemq:queue:My.Queue?concurrentConsumers=5amp; 
 acknowledgementModeName=INDIVIDUAL_MESSAGE
  to: jetty:http://somewebendpoint/
 and have quasi-transacted behavior



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


[jira] [Created] (AMQ-4835) JournalPersistenceAdapter: Persistence Adaptor Task iterates forever

2013-10-30 Thread Jiri Patera (JIRA)
Jiri Patera created AMQ-4835:


 Summary: JournalPersistenceAdapter: Persistence Adaptor Task 
iterates forever
 Key: AMQ-4835
 URL: https://issues.apache.org/jira/browse/AMQ-4835
 Project: ActiveMQ
  Issue Type: Bug
  Components: Message Store
Affects Versions: 5.7.0
 Environment: JDK 1.6.0_45
Reporter: Jiri Patera


This erroneous behavior happens after a simple asynchronous message 
send/receive test has passed and is about to exit. It happens only in case the 
Journal usage is enabled via the following configuration property:

{code}
jms-engine.useJournal=true
{code}

The test shutdown process than takes about 5-10 minutes to complete. The test 
result is then passed. 

The thread waits here:

{code}
org.apache.activemq.thread.PooledTaskRunner.shutdown(long):101
{code}

And will be notified when all the 1000 for-cycle iterations pass here:

{code}
org.apache.activemq.thread.PooledTaskRunner.runTask():128
{code}

And a log:

{code}
13.10.15 12:04:36:951 DEBUG [main] [PooledConnectionFactory   ] Stopping 
the PooledConnectionFactory, number of connections in cache: 0
13.10.15 12:04:36:952 DEBUG [ActiveMQ VMTransport: 
vm://JmsEngineActivemqBroker#1-1] [ManagementContext ] 
Unregistering MBean 
org.apache.activemq:BrokerName=JmsEngineActivemqBroker,Type=Producer,destinationType=Dynamic,clientId=ID_localhost-51012-1381831459465-2_1,producerId=ID_localhost-51012-1381831459465-3_1_1_1
13.10.15 12:04:36:955 DEBUG [ActiveMQ VMTransport: 
vm://JmsEngineActivemqBroker#1-1] [ManagementContext ] 
Unregistering MBean 
org.apache.activemq:BrokerName=JmsEngineActivemqBroker,Type=Producer,destinationType=Dynamic,clientId=ID_localhost-51012-1381831459465-2_1,producerId=ID_localhost-51012-1381831459465-3_1_3_1
13.10.15 12:04:36:955 DEBUG [ActiveMQ VMTransport: 
vm://JmsEngineActivemqBroker#1-1] [ManagementContext ] 
Unregistering MBean 
org.apache.activemq:BrokerName=JmsEngineActivemqBroker,Type=Subscription,persistentMode=Non-Durable,destinationType=Topic,destinationName=ActiveMQ.Advisory.TempQueue_ActiveMQ.Advisory.TempTopic,clientId=ID_localhost-51012-1381831459465-2_1,consumerId=ID_localhost-51012-1381831459465-3_1_-1_1
13.10.15 12:04:36:955 DEBUG [ActiveMQ VMTransport: 
vm://JmsEngineActivemqBroker#1-1] [AbstractRegion] 
JmsEngineActivemqBroker removing consumer: 
ID:localhost-51012-1381831459465-3:1:-1:1 for destination: 
ActiveMQ.Advisory.TempQueue,ActiveMQ.Advisory.TempTopic
13.10.15 12:04:36:956 DEBUG [ActiveMQ VMTransport: 
vm://JmsEngineActivemqBroker#1-1] [TransportConnection   ] remove 
connection id: ID:localhost-51012-1381831459465-3:1
13.10.15 12:04:36:963 DEBUG [ActiveMQ BrokerService[JmsEngineActivemqBroker] 
Task-1] [TransportConnection   ] Stopping connection: 
vm://JmsEngineActivemqBroker#0
13.10.15 12:04:36:964 DEBUG [ActiveMQ BrokerService[JmsEngineActivemqBroker] 
Task-1] [ThreadPoolUtils   ] Forcing shutdown of ExecutorService: 
java.util.concurrent.ThreadPoolExecutor@22f62eba
13.10.15 12:04:36:964 DEBUG [ActiveMQ BrokerService[JmsEngineActivemqBroker] 
Task-1] [TransportConnection   ] Stopped transport: 
vm://JmsEngineActivemqBroker#0
13.10.15 12:04:36:964 DEBUG [ActiveMQ BrokerService[JmsEngineActivemqBroker] 
Task-1] [TransportConnection   ] Connection Stopped: 
vm://JmsEngineActivemqBroker#0
13.10.15 12:04:36:965 DEBUG [main] [ThreadPoolUtils   ] Shutdown of 
ExecutorService: java.util.concurrent.ThreadPoolExecutor@30721965 is shutdown: 
true and terminated: false took: 0.000 seconds.
13.10.15 12:04:36:965 DEBUG [main] [ThreadPoolUtils   ] Shutdown of 
ExecutorService: java.util.concurrent.ThreadPoolExecutor@d0cc53e is shutdown: 
true and terminated: true took: 0.000 seconds.
13.10.15 12:04:36:965 DEBUG [main] [ThreadPoolUtils   ] Forcing 
shutdown of ExecutorService: java.util.concurrent.ThreadPoolExecutor@24d37b87
13.10.15 12:04:36:965 DEBUG [main] [VMTransportFactory] Shutting 
down VM connectors for broker: JmsEngineActivemqBroker
13.10.15 12:04:36:965 INFO  [main] [TransportConnector] Connector 
vm://JmsEngineActivemqBroker Stopped
13.10.15 12:04:36:966 INFO  [main] [BrokerService ] Apache 
ActiveMQ 5.7.0 (JmsEngineActivemqBroker, ID:localhost-51012-1381831459465-0:1) 
is shutting down
13.10.15 12:04:38:002 INFO  [main] [TransportConnector] Connector 
tcp://localhost:0 Stopped
13.10.15 12:04:38:021 DEBUG [main] [ManagementContext ] 
Unregistering MBean 
org.apache.activemq:BrokerName=JmsEngineActivemqBroker,Type=Topic,Destination=ActiveMQ.Advisory.Connection
13.10.15 12:04:38:022 DEBUG [main] [ManagementContext ] 
Unregistering MBean 
org.apache.activemq:BrokerName=JmsEngineActivemqBroker,Type=Queue,Destination=requestQueue
13.10.15 12:04:38:022 DEBUG 

[jira] [Assigned] (AMQ-4767) Extend ActiveMQ Camel component to support INDIVIDUAL_MESSAGE ack mode

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen reassigned AMQ-4767:


Assignee: Claus Ibsen

 Extend ActiveMQ Camel component to support INDIVIDUAL_MESSAGE ack mode
 --

 Key: AMQ-4767
 URL: https://issues.apache.org/jira/browse/AMQ-4767
 Project: ActiveMQ
  Issue Type: New Feature
  Components: activemq-camel
Affects Versions: 5.8.0
 Environment: All
Reporter: Matt Pavlovich
Assignee: Claus Ibsen
 Fix For: 5.10.0


 It would be really helpful to have a per-message acknowledgement that did not 
 acknowledge all previous messages.. this would be an ActiveMQ-only 
 acknowledgement mode.
 Really handy for Camel to do things like 
  from: activemq:queue:My.Queue?concurrentConsumers=5amp; 
 acknowledgementModeName=INDIVIDUAL_MESSAGE
  to: jetty:http://somewebendpoint/
 and have quasi-transacted behavior



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


[jira] [Resolved] (AMQ-4762) ActiveMQ in standalone mode - Have it output the urls for web consoles and JMX

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved AMQ-4762.
--

   Resolution: Fixed
Fix Version/s: (was: 5.10.0)
   5.9.0

If you enabled JMX then you see
 INFO | JMX consoles can connect to 
service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi

 ActiveMQ in standalone mode - Have it output the urls for web consoles and JMX
 --

 Key: AMQ-4762
 URL: https://issues.apache.org/jira/browse/AMQ-4762
 Project: ActiveMQ
  Issue Type: Wish
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 5.9.0


 When you start ActiveMQ in standalone mode, you can see something about Web 
 console type embedded etc. But you cannot see what the http url is for 
 accessing the console. It would be great if we could add a log to point 
 people to a http url to access. For example if 8161 port is used they can 
 access the welcome page at
 http://localhost:8161/
 And we should possible make the welcome page non secure, so they do not need 
 to login to see that page. As the links on that welcome page points to the 
 embedded consoles which is secure.



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


[jira] [Assigned] (AMQ-4762) ActiveMQ in standalone mode - Have it output the urls for web consoles and JMX

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen reassigned AMQ-4762:


Assignee: Claus Ibsen

 ActiveMQ in standalone mode - Have it output the urls for web consoles and JMX
 --

 Key: AMQ-4762
 URL: https://issues.apache.org/jira/browse/AMQ-4762
 Project: ActiveMQ
  Issue Type: Wish
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 5.9.0


 When you start ActiveMQ in standalone mode, you can see something about Web 
 console type embedded etc. But you cannot see what the http url is for 
 accessing the console. It would be great if we could add a log to point 
 people to a http url to access. For example if 8161 port is used they can 
 access the welcome page at
 http://localhost:8161/
 And we should possible make the welcome page non secure, so they do not need 
 to login to see that page. As the links on that welcome page points to the 
 embedded consoles which is secure.



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


[jira] [Updated] (AMQ-4746) Applet ClassLoader Problems

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4746:
-

 Priority: Minor  (was: Major)
Fix Version/s: 5.10.0
 Assignee: Claus Ibsen

 Applet ClassLoader Problems
 ---

 Key: AMQ-4746
 URL: https://issues.apache.org/jira/browse/AMQ-4746
 Project: ActiveMQ
  Issue Type: Bug
  Components: JMS client
Affects Versions: 5.7.0, 5.8.0
 Environment: Windows 7, Java 1.7 or 1.6, Applet
Reporter: Calvin Moody
Assignee: Claus Ibsen
Priority: Minor
  Labels: ClassLoader
 Fix For: 5.10.0

   Original Estimate: 24h
  Remaining Estimate: 24h

 Applets fail to deserailize messages in a timely manner after a network 
 failure triggers a reconnect using the FailoverTransport
 In ClassLoadingAwareObjectInputStream.java the  load() method makes a call to 
 Class.forName().
 For the primitive types (int, boolean, etc.) this would result in a call 
 similar to:
 Class.forName(int, false, loader); //Where loader is the 
 Applet2ClassLoader
 Since Applet2ClassLoader is a URLClassLoader and int.class is not in the 
 jar cache it pulled down from the server at the start of application, it is 
 going to try and go to the server to resolve this class.
 In the event of a network failure, this will result in the ClassLoader having 
 to wait for the socket timeout. (see stacktrace at link) Once this socket 
 timeout occurs, the load() method then attempts to lookup the class in the 
 primitive HashMap that is statically initialized. This returns the class for 
 the int and the deserialization continues on.
 At first it seemed like the messages were failing to be received but it 
 turned out they were just taking a very long time to be deserialized. This 
 problem can be avoided by changing the order in which 
 ClassLoadingAwareObjectInputStream tries to resolve the class. 
 Here is the change I made to the load() method: 
 http://activemq.2283324.n4.nabble.com/Applet-Class-Loader-Problems-td4671835.html
  



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


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

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved AMQ-4742.
--

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

I added a note about the 4gb limit on windows

https://cwiki.apache.org/confluence/display/ACTIVEMQ/Java+Service+Wrapper

 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] [Created] (AMQ-4836) Calling Connection.commit() on a Connection with setAutoCommit(true) throws SQLException

2013-10-30 Thread Jiri Patera (JIRA)
Jiri Patera created AMQ-4836:


 Summary: Calling Connection.commit() on a Connection with 
setAutoCommit(true) throws SQLException
 Key: AMQ-4836
 URL: https://issues.apache.org/jira/browse/AMQ-4836
 Project: ActiveMQ
  Issue Type: Bug
  Components: Message Store
Affects Versions: 5.7.0
 Environment: JDK 1.6.0_45, Firebird or HDB (SAP HANA DB) configured as 
a persistent storage
Reporter: Jiri Patera


This issue is similar to AMQ-577 (resolved by adding a MSSQL JDBC URL 
parameter) and AMQ-711 (resolved as cannot reproduce) issues.

The problem is that the JDBC API (the {{Connection}} class JavaDoc) states:

{code}
/**
 * Makes all changes made since the previous
 * commit/rollback permanent and releases any database locks
 * currently held by this codeConnection/code object. 
 * This method should be
 * used only when auto-commit mode has been disabled.
 *
 * @exception SQLException if a database access error occurs, 
 * this method is called while participating in a distributed transaction,
 * if this method is called on a closed conection or this
 *codeConnection/code object is in auto-commit mode
 * @see #setAutoCommit 
 */
void commit() throws SQLException;
{code}

However, some JDBC drivers do not throw the {{SQLException}} when the 
{{Connection.commit()}} method is called on a {{Connection}} instance with 
{{setAutoCommit(true)}}. Some others do (Firebird, SAP-HANA, MSSQL without the 
JDBC URL parameter {{relaxAutoCommit=true}}). With these databases the 
following exceptions can be thrown on the Broker start-up:

1) {{DefaultJDBCAdapter.doDropTables(DefaultJDBCAdapter.java:148)}}:

{code}
Caused by: com.sap.db.jdbc.exceptions.JDBCDriverException: SAP DBTech JDBC: 
Connection is currently in auto commit mode.
at 
com.sap.db.jdbc.exceptions.SQLExceptionSapDB.createException(SQLExceptionSapDB.java:334)
at 
com.sap.db.jdbc.exceptions.SQLExceptionSapDB.generateSQLException(SQLExceptionSapDB.java:113)
at com.sap.db.jdbc.ConnectionSapDB.commit(ConnectionSapDB.java:351)
at com.sap.db.jdbc.trace.Connection.commit(Connection.java:126)
at 
org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:334)
at 
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:211)
at 
org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doDropTables(DefaultJDBCAdapter.java:148)
at 
org.apache.activemq.store.jdbc.adapter.OptimizedDefaultJDBCAdapter.doDropTables(OptimizedDefaultJDBCAdapter.java:68)
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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke(AbstractTraceInterceptor.java:113)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at com.sun.proxy.$Proxy12.doDropTables(Unknown Source)
at 
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.deleteAllMessages(JDBCPersistenceAdapter.java:526)
... 64 more
{code}

2) {{DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:119)}}

{code}
Caused by: com.sap.db.jdbc.exceptions.JDBCDriverException: SAP DBTech JDBC: 
Connection is currently in auto commit mode.
at 
com.sap.db.jdbc.exceptions.SQLExceptionSapDB.createException(SQLExceptionSapDB.java:334)
at 
com.sap.db.jdbc.exceptions.SQLExceptionSapDB.generateSQLException(SQLExceptionSapDB.java:113)
at com.sap.db.jdbc.ConnectionSapDB.commit(ConnectionSapDB.java:351)
at com.sap.db.jdbc.trace.Connection.commit(Connection.java:126)
at 
org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:334)
at 
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:211)
at 
org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doCreateTables(DefaultJDBCAdapter.java:119)
at 
org.apache.activemq.store.jdbc.adapter.OptimizedDefaultJDBCAdapter.doCreateTables(OptimizedDefaultJDBCAdapter.java:62)
at 

[jira] [Resolved] (AMQ-4716) Bad authentication passed from Web Console to secured broker

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved AMQ-4716.
--

   Resolution: Cannot Reproduce
Fix Version/s: 5.9.0
 Assignee: Claus Ibsen

You can configure the AMQ username and password in conf/credentials.properties

Also the new web console from AMQ 5.9 onwards (hawtio) you can configure the 
AMQ credentials in its settings. And have other accounts for the web console 
login.

 Bad authentication passed from Web Console to secured broker
 

 Key: AMQ-4716
 URL: https://issues.apache.org/jira/browse/AMQ-4716
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.7.0, 5.8.0
Reporter: Laurent Paumier
Assignee: Claus Ibsen
Priority: Minor
 Fix For: 5.9.0


 Since the fix for AMQ-3924, the username/password for the Web Console 
 authenticated user are used for the connection to the broker. The 
 username/password properties set in the connectionFactory are not used 
 anymore.
 Current workaround requires configuring Web Console users as broker users...



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


[jira] [Updated] (AMQ-4699) Transacted producer does not throw ResourceAllocationException on error

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4699:
-

Fix Version/s: NEEDS_REVIEWED

 Transacted producer does not throw ResourceAllocationException on error
 ---

 Key: AMQ-4699
 URL: https://issues.apache.org/jira/browse/AMQ-4699
 Project: ActiveMQ
  Issue Type: Bug
  Components: JMS client
Affects Versions: 5.8.0
 Environment: ActiveMQ 5.8.0 server
 ActiveMQ 5.8.0 client on Java 7
Reporter: Joakim von Brandis
 Fix For: NEEDS_REVIEWED


 Using a transacted producer session, with sendFailIfNoSpace=true or 
 sendFailIfNoSpaceAfterTimeout=timeout, the producer gets no error on whether 
 send() or commit(). Thus, the producer may pour out messages in a transacted 
 session, which are silently discarded by ActiveMQ.
 A connection exception listener will receive ResourceAllocationException, but 
 since this happens in another thread than the sending client, there is no 
 guarantee that the client can be notified in time to avoid commit().
 Without using sendFailIfNoSpace(AfterTimeout), producer is blocked until 
 space is available, as expected.
 The client should receive error on send() when the resource exhaustion is 
 reported, and in any case a commit() should not complete without error if the 
 server has discarded any messages in the transaction.



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


[jira] [Assigned] (AMQ-4706) Failover transport - Add option to configure WARN logging internval for failover attempts still failing

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen reassigned AMQ-4706:


Assignee: Claus Ibsen

 Failover transport - Add option to configure WARN logging internval for 
 failover attempts still failing
 ---

 Key: AMQ-4706
 URL: https://issues.apache.org/jira/browse/AMQ-4706
 Project: ActiveMQ
  Issue Type: Improvement
  Components: activemq-camel
Affects Versions: 5.8.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 5.10.0


 The failover transport
 http://activemq.apache.org/failover-transport-reference.html
 If a client is constantly trying to failover and re-connect but can't do this 
 for a long time, then it would be nice if there was a WARN log once in a 
 while to indicate that.
 So if there is a new option people can turn on to log that, or have a 
 sensible default so its out of the box
 For example
 {code}
 reconnectWarnLogInterval=3
 {code}
 Which then logs every 30 sec if failover/reconnect is still failing. People 
 can then turn that off with 0, -1 or set a higher value if 30 sec is too 
 frequent.
 See also
 http://camel.465427.n5.nabble.com/bundle-stays-in-state-creating-tp5738312.html
 For people using ServiceMix it may cause their bundles to keep in grace mode, 
 and they cant understand why. So if there is at least some WARN log activity 
 then they would understand better.



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


[jira] [Updated] (AMQ-4311) Spooling pending messages in the large transaction to the disk

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4311:
-

Issue Type: New Feature  (was: Improvement)

 Spooling pending messages in the large transaction to the disk
 --

 Key: AMQ-4311
 URL: https://issues.apache.org/jira/browse/AMQ-4311
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker, Message Store
Affects Versions: 5.x
Reporter: SuoNayi
 Fix For: NEEDS_REVIEWED


 Currently MemoryTransactionStore is used to hold pending messages in a 
 transaction.
 More pending messages in a transaction more memory is consumed.
 Because the message size of pending messages is not counted in usage limit 
 before they are committed so PFC wont block producers as well and large 
 transaction will cause broker throws OOM at last.
 Spooling pending messages in the transaction to the disk is one of solution.



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


[jira] [Updated] (AMQ-4311) Spooling pending messages in the large transaction to the disk

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4311:
-

Fix Version/s: (was: Unscheduled)
   NEEDS_REVIEWED

 Spooling pending messages in the large transaction to the disk
 --

 Key: AMQ-4311
 URL: https://issues.apache.org/jira/browse/AMQ-4311
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker, Message Store
Affects Versions: 5.x
Reporter: SuoNayi
 Fix For: NEEDS_REVIEWED


 Currently MemoryTransactionStore is used to hold pending messages in a 
 transaction.
 More pending messages in a transaction more memory is consumed.
 Because the message size of pending messages is not counted in usage limit 
 before they are committed so PFC wont block producers as well and large 
 transaction will cause broker throws OOM at last.
 Spooling pending messages in the transaction to the disk is one of solution.



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


[jira] [Commented] (AMQ-4687) Rar losing messages when there is a XA trx timeout (jboss)

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808887#comment-13808887
 ] 

Claus Ibsen commented on AMQ-4687:
--

Have you tried with AMQ 5.9. There has been some improvements/fixes in the RAR 
and XA.

 Rar losing messages when there is a XA trx timeout (jboss) 
 ---

 Key: AMQ-4687
 URL: https://issues.apache.org/jira/browse/AMQ-4687
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.6.0
 Environment: Jboss 6.0.1, JDK 1.6, ActiveMQ 5.6
Reporter: Juan Manuel Lopez
Priority: Critical
 Fix For: 5.x


 ActiveMQ does a trx commit when there is a transaction timeout 
 (EJBTransactionRolledbackException). In this way we are losing messages when 
 there is any timeout.
 We have seen that the activemq connections are enlist in XA.
 The attribute transactionContext from ActiveMQSession class has the global 
 transaction reference (xid) before calling the MDB 
 (messageListener.onMessage(message)).
 When the timeout is reached and the RuntimeException is throwned, the 
 transactionContext losed the xid reference.
 Later, when ActiveMQSession call the method 
 transactionContext.isInXATransaction() the result is false because there is 
 no xid reference.
 This situation only happened when the MDB calls other EJB (Stateless) with 
 CMT - TransactionAttributeType.REQUIRES_NEW, and the exception is throwed 
 inside the Stateless.
 I've tried to reproduce this without calling the stateless ejb but it works 
 well.
 The ActiveMQSession class should retain the original transactionContext.
 I found these is the same problem jira 
 https://issues.apache.org/jira/browse/AMQ-4634 but is possible move this fix 
 into version ActiveMQ 5.6 ?
 Regards



--
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

2013-10-30 Thread Paul Lewis (JIRA)

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

Paul Lewis commented on AMQ-4742:
-

Hi Claus,

The original issue I raised was that we couldn't address more than 4GB of 
memory when using the 64-bit Linux wrapper, so at the very least, it would be 
worth putting the same note about the memory limit under the Linux wrapper 
section of the page you updated.

However, I guess I'm more interested in whether this will ever be fixed, or 
whether we will have to look at other queues in order to be able to address 
more than 4GB memory?

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] [Assigned] (AMQ-4685) LDAPLoginModule throws InvalidNameException when resolving LDAP aliases

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen reassigned AMQ-4685:


Assignee: Claus Ibsen

 LDAPLoginModule throws InvalidNameException when resolving LDAP aliases
 ---

 Key: AMQ-4685
 URL: https://issues.apache.org/jira/browse/AMQ-4685
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.x
 Environment: OS Independent
 OpenLDAP 2.4
Reporter: Igor Podolskiy
Assignee: Claus Ibsen
Priority: Minor
 Attachments: handle-ldap-aliases-v1.patch


 Some LDAP servers allow you to define aliases for objects. For example, 
 consider the following LDAP directory layout:
 {code}
 dc=example,dc=com
ou=ActiveMQ
   ou=Users
   ou=Roles
   ou=Destinations
ou=People
 {code}
 In this layout, accounts specific to ActiveMQ go under ou=Users,ou=ActiveMQ. 
 However, some accounts in ou=People should also be able to have access to the 
 ActiveMQ server. To avoid duplicating accounts, you can have the regular 
 account (objectClass=inetOrgPerson) in ou=People and create an LDAP alias 
 (objectClass=alias) for it in ou=People. The LDAP server then takes care 
 about the alias resolution.
 The JNDI LDAP client supports LDAP alias dereferencing as well. However, the 
 search results for resolved aliases are different. For regular entries, 
 SearchResult.getName() returns a relative DN and SearchResult.isRelative() 
 returns true; for dereferenced aliases, SearchResult.getName() returns a full 
 LDAP URI with the DN of the alias target (for example, 
 'ldap://localhost:389/uid=bob,ou=People,dc=example,dc=com') and 
 SearchResult.isRelative() returns false (as documented, for example, in [1]).
 The code in o.a.a.jaas.LDAPLoginModule does not make this distinction. It 
 assumes that all returned names are RDNs and passes them to 
 NameParser.parse() which in turn raises a NamingException because an LDAP URI 
 is obviously not an LDAP (R)DN.
 The attached patch resolved the problem at least for my configuration. If 
 isRelative() returns false, the name is parsed as an URI. Per definition of 
 LDAP URIs, the path component is the distinguished name, which is then taken.
 Of course, this does not take care of multiple layers of aliases, aliases for 
 containers and so on - I just found it over the course of setting up LDAP  
 authentication in my system, which happens only to alias user accounts. It 
 works for me with the patch and seems not to make things worse :) If needed, 
 maybe I can do some further tests and/or correct the patch.
 [1] http://docs.oracle.com/javase/jndi/tutorial/ldap/misc/aliases.html



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


[jira] [Resolved] (AMQ-4687) Rar losing messages when there is a XA trx timeout (jboss)

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved AMQ-4687.
--

Resolution: Duplicate

Duplicate of AMQ-4634

If you want to backport a fix on AMQ 5.6, then you need to do this yourself.
AMQ 5.6 is not active supported at Apache.

For long term support then you can check out some of the commercial support / 
vendors
http://activemq.apache.org/support.html

 Rar losing messages when there is a XA trx timeout (jboss) 
 ---

 Key: AMQ-4687
 URL: https://issues.apache.org/jira/browse/AMQ-4687
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.6.0
 Environment: Jboss 6.0.1, JDK 1.6, ActiveMQ 5.6
Reporter: Juan Manuel Lopez
Priority: Critical
 Fix For: 5.x


 ActiveMQ does a trx commit when there is a transaction timeout 
 (EJBTransactionRolledbackException). In this way we are losing messages when 
 there is any timeout.
 We have seen that the activemq connections are enlist in XA.
 The attribute transactionContext from ActiveMQSession class has the global 
 transaction reference (xid) before calling the MDB 
 (messageListener.onMessage(message)).
 When the timeout is reached and the RuntimeException is throwned, the 
 transactionContext losed the xid reference.
 Later, when ActiveMQSession call the method 
 transactionContext.isInXATransaction() the result is false because there is 
 no xid reference.
 This situation only happened when the MDB calls other EJB (Stateless) with 
 CMT - TransactionAttributeType.REQUIRES_NEW, and the exception is throwed 
 inside the Stateless.
 I've tried to reproduce this without calling the stateless ejb but it works 
 well.
 The ActiveMQSession class should retain the original transactionContext.
 I found these is the same problem jira 
 https://issues.apache.org/jira/browse/AMQ-4634 but is possible move this fix 
 into version ActiveMQ 5.6 ?
 Regards



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


[jira] [Commented] (AMQ-4684) LevelDB on NFS created .nfs files

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808891#comment-13808891
 ] 

Claus Ibsen commented on AMQ-4684:
--

Have you tried with the 5.9 release?

 LevelDB on NFS created .nfs files
 -

 Key: AMQ-4684
 URL: https://issues.apache.org/jira/browse/AMQ-4684
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-leveldb-store
Affects Versions: 5.8.0
 Environment: three linuc machines:
 - one NFS server
 - two activeMQ machines, both a mount on the NFS server for LevelDB
Reporter: Christiaan Willemsen
Priority: Minor

 We are currently testing levelDB on NFS for failover. We did this test with 
 only one ActiveMQ running.
 We filled one queue with 10.000 messages via the admin console, and then 
 purged the queue.
 After this, the LevelDB directory was filled with .nfsxx files. These 
 seem to be old version of the LevelDB log file. They are removed when you 
 stop the ActiceMQ process. You also appear to be able to remove the files 
 manually.
 From what we can deduce, these files mean that they were still open for io, 
 while they were removed from the filesystem. A local filesystem will cope 
 with this in the background, on a NFS share however that can't be done, so 
 these .nfs files are created.
 So it seems that the LevelDB store keeps the old logfiles open after they 
 were deleted.



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


[jira] [Updated] (AMQ-4685) LDAPLoginModule throws InvalidNameException when resolving LDAP aliases

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4685:
-

Fix Version/s: 5.10.0

 LDAPLoginModule throws InvalidNameException when resolving LDAP aliases
 ---

 Key: AMQ-4685
 URL: https://issues.apache.org/jira/browse/AMQ-4685
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.x
 Environment: OS Independent
 OpenLDAP 2.4
Reporter: Igor Podolskiy
Assignee: Claus Ibsen
Priority: Minor
 Fix For: 5.10.0

 Attachments: handle-ldap-aliases-v1.patch


 Some LDAP servers allow you to define aliases for objects. For example, 
 consider the following LDAP directory layout:
 {code}
 dc=example,dc=com
ou=ActiveMQ
   ou=Users
   ou=Roles
   ou=Destinations
ou=People
 {code}
 In this layout, accounts specific to ActiveMQ go under ou=Users,ou=ActiveMQ. 
 However, some accounts in ou=People should also be able to have access to the 
 ActiveMQ server. To avoid duplicating accounts, you can have the regular 
 account (objectClass=inetOrgPerson) in ou=People and create an LDAP alias 
 (objectClass=alias) for it in ou=People. The LDAP server then takes care 
 about the alias resolution.
 The JNDI LDAP client supports LDAP alias dereferencing as well. However, the 
 search results for resolved aliases are different. For regular entries, 
 SearchResult.getName() returns a relative DN and SearchResult.isRelative() 
 returns true; for dereferenced aliases, SearchResult.getName() returns a full 
 LDAP URI with the DN of the alias target (for example, 
 'ldap://localhost:389/uid=bob,ou=People,dc=example,dc=com') and 
 SearchResult.isRelative() returns false (as documented, for example, in [1]).
 The code in o.a.a.jaas.LDAPLoginModule does not make this distinction. It 
 assumes that all returned names are RDNs and passes them to 
 NameParser.parse() which in turn raises a NamingException because an LDAP URI 
 is obviously not an LDAP (R)DN.
 The attached patch resolved the problem at least for my configuration. If 
 isRelative() returns false, the name is parsed as an URI. Per definition of 
 LDAP URIs, the path component is the distinguished name, which is then taken.
 Of course, this does not take care of multiple layers of aliases, aliases for 
 containers and so on - I just found it over the course of setting up LDAP  
 authentication in my system, which happens only to alias user accounts. It 
 works for me with the patch and seems not to make things worse :) If needed, 
 maybe I can do some further tests and/or correct the patch.
 [1] http://docs.oracle.com/javase/jndi/tutorial/ldap/misc/aliases.html



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


[jira] [Resolved] (AMQ-4659) REST API MessageServlet does not accept JSON or plain text content types in request

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved AMQ-4659.
--

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

Thanks for reporting. Marking this as duplicate of AMQ-4668 where we have a 
patch to make this better.

 REST API MessageServlet does not accept JSON or plain text content types in 
 request
 ---

 Key: AMQ-4659
 URL: https://issues.apache.org/jira/browse/AMQ-4659
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker, Connector
Affects Versions: 5.8.0
 Environment: n/a
Reporter: Ed Valdez-Guillen
Assignee: Claus Ibsen
Priority: Minor
 Fix For: 5.10.0


 Currently, the MessageServlet that ships with ActiveMQ (used by the REST API) 
 ignores the body of HTTP POST requests if the content type is NOT text/xml. 
  This results in empty messages being sent to target destinations.
 For my particular needs, it would be nice if text/plain were allowed 
 because I'm hoping to use the REST API for posting text messages from a VXML 
 voice/web application.  However, the VXML platform I'm using only supports 
 text/plain content type (not XML or JSON) and the VXML standard itself does 
 not specify which content type(s) should be supported in this case.
 Anyway, I'm not sure if supporting the text/plain content type conflicts 
 with REST principles, but I believe at a minimum application/json should be 
 allowed along with text/xml in the POST request (not just the response).



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


[jira] [Updated] (AMQ-4668) REST API only accepts non-form content if content type of text/xml

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4668:
-

  Component/s: Transport
 Priority: Minor  (was: Major)
Fix Version/s: 5.10.0
 Assignee: Claus Ibsen
   Issue Type: Improvement  (was: Bug)

 REST API only accepts non-form content if content type of text/xml
 --

 Key: AMQ-4668
 URL: https://issues.apache.org/jira/browse/AMQ-4668
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker, Transport
Affects Versions: 5.8.0
Reporter: Chris Robison
Assignee: Claus Ibsen
Priority: Minor
 Fix For: 5.10.0

 Attachments: MessageServletSupport.java.patch


 If you don't format the POST content like body={content}, the servlet will 
 only read the body if the content type is text/xml. I'd like to submit JSON 
 so it is not working. I've included a patch to open it up a bit.



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


[jira] [Updated] (AMQ-4433) Socket parameters are not validated

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4433:
-

  Component/s: Transport
Fix Version/s: 5.10.0
 Assignee: Claus Ibsen
   Issue Type: Improvement  (was: Bug)

 Socket parameters are not validated
 ---

 Key: AMQ-4433
 URL: https://issues.apache.org/jira/browse/AMQ-4433
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Transport
Reporter: Christoffer Sawicki
Assignee: Claus Ibsen
Priority: Minor
 Fix For: 5.10.0

 Attachments: 0001-Validate-socket-parameters.patch, 
 0002-Validate-connector-parameters.patch, 
 0003-Validate-transport-parameters.patch


 Connect parameters are validated in every transport factory with a statement 
 like this:
 {noformat}
 if (!options.isEmpty()) {
   throw new IllegalArgumentException(Invalid connect parameters:  + 
 options);
 }
 {noformat}
 Socket parameters (i.e. connect parameters prefixed with {{socket.}}) are 
 however never validated.
 They are put away at
 {noformat}
 TcpTransportFactory.compositeConfigure(Transport, WireFormat, Map) line: 85   
 {noformat}
 and then set at
 {noformat}
 TcpTransport.initialiseSocket(Socket) line: 428
 {noformat}
 where there is no check that {{socketOptions}} is empty after the call.
 I've attached a patch (#1) that rectifies this.
 Bonus: I found similar issues in the transport classes. See patch #2 and #3.



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


[jira] [Updated] (AMQ-4644) informix Routine (empty_blob) can not be resolved

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4644:
-

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

 informix Routine (empty_blob) can not be resolved
 -

 Key: AMQ-4644
 URL: https://issues.apache.org/jira/browse/AMQ-4644
 Project: ActiveMQ
  Issue Type: Improvement
Affects Versions: 5.8.0
 Environment: Solaris
Reporter: Stefan
 Fix For: NEEDS_REVIEWED


 Using the following Setup:
 Solaris x64  / Informix: 11.70FC7DE
 broker configuration:
 amq:broker  
useJmx=true 
brokerName=jdbcBroker 
persistent=true 
xmlns=http://activemq.apache.org/schema/core;
   amq:destinations
 queue physicalName=jms/myque /
   /amq:destinations
 amq:persistenceAdapter
   amq:jdbcPersistenceAdapter 
adapter=#informixAdapter 
dataDirectory=${activemq.data} 
dataSource=#informix-ds 
lockKeepAlivePeriod=1 
createTablesOnStartup=true
amq:locker
   amq:database-locker lockAcquireSleepInterval=5000/
/amq:locker
/amq:jdbcPersistenceAdapter
   /amq:persistenceAdapter
 amq:transportConnectors
amq:transportConnector name=default uri=tcp://0.0.0.0:61616/
 /amq:transportConnectors
 /amq:broker
 bean id=informixAdapter 
   class=org.apache.activemq.store.jdbc.adapter.InformixJDBCAdapter/
 If a message is sent to the broker, I get the following error:
 Routine (empty_blob) can not be resolved.
 InformixJDBCAdapter extends BlobJDBCAdapter
 --
 In org.apache.activemq.store.jdbc.adapter.BlobJDBCAdapter, I saw the 
 following code that issues the error:
 @Override
 public void setStatements(Statements statements) {
 String addMessageStatement = INSERT INTO 
 + statements.getFullMessageTableName()
 + (ID, MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, 
 MSG, XID) VALUES (?, ?, ?, ?, ?, ?, empty_blob(), empty_blob());



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


[jira] [Updated] (AMQ-4642) regression: SpringSslContext no longer supports classpath:filename syntax for referencing files

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4642:
-

  Component/s: Broker
 Priority: Minor  (was: Major)
Fix Version/s: 5.10.0
 Assignee: Claus Ibsen

 regression: SpringSslContext no longer supports classpath:filename syntax for 
 referencing files
 ---

 Key: AMQ-4642
 URL: https://issues.apache.org/jira/browse/AMQ-4642
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.6.0, 5.7.0, 5.8.0
Reporter: Thomas Swindells
Assignee: Claus Ibsen
Priority: Minor
  Labels: easyfix
 Fix For: 5.10.0


 Previously keyStore and trustStore were Spring resources rather than strings. 
 This meant the spring standard classpath:location syntax could be used to 
 specify the file, eg:
   bean id=sslContext 
 class=org.apache.activemq.spring.SpringSslContext
   property name=keyStore value=classpath:key.ks /
   property name=keyStorePassword value=password /
   property name=trustStore value=classpath:trust.ts /
   property name=trustStorePassword value=password /
   /bean
 The change for AMQ-3268 means that this no longer works instead throwing the 
 exception:
 Caused by: org.springframework.beans.factory.BeanCreationException: Error 
 creating bean with name 'sslContext': Invocation of init method failed; 
 nested exception is java.net.MalformedURLException: unknown protocol: 
 classpath
   at 
 org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:133)
 Caused by: java.net.MalformedURLException: unknown protocol: classpath
 The reason is in org.apache.activemq.spring.Utils:
public static Resource resourceFromString(String uri) throws 
 MalformedURLException {
 Resource resource;
 File file = new File(uri);
 if (file.exists()) {
 resource = new FileSystemResource(uri);
 } else if (ResourceUtils.isUrl(uri)) {
 resource = new UrlResource(uri);
 } else {
 resource = new ClassPathResource(uri);
 }
 return resource;
 }
 The ResourceUtils.isUrl has explicit code to return true if the uri 
 startsWith classpath, however UrlResource doesn't handle this.
 A fix may be to change the line to be 
 resource = new UrlResource(ResourceUtils.getURL(uri));
 ResourceUtils will then handle the classpath url, resolve it and return a 
 valid url. An alternative fix would be for this code to do an explicit check 
 for classpath: itself and if it is found pass the substring into 
 ClassPathResource.



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


[jira] [Commented] (AMQ-4644) informix Routine (empty_blob) can not be resolved

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808896#comment-13808896
 ] 

Claus Ibsen commented on AMQ-4644:
--

Can you find the valid SQL That informix can use?

It is possible to define custom SQL configurations for different database 
vendors. So we can have an informix, but would need to valid SQL to use.



 informix Routine (empty_blob) can not be resolved
 -

 Key: AMQ-4644
 URL: https://issues.apache.org/jira/browse/AMQ-4644
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0
 Environment: Solaris
Reporter: Stefan
 Fix For: NEEDS_REVIEWED


 Using the following Setup:
 Solaris x64  / Informix: 11.70FC7DE
 broker configuration:
 amq:broker  
useJmx=true 
brokerName=jdbcBroker 
persistent=true 
xmlns=http://activemq.apache.org/schema/core;
   amq:destinations
 queue physicalName=jms/myque /
   /amq:destinations
 amq:persistenceAdapter
   amq:jdbcPersistenceAdapter 
adapter=#informixAdapter 
dataDirectory=${activemq.data} 
dataSource=#informix-ds 
lockKeepAlivePeriod=1 
createTablesOnStartup=true
amq:locker
   amq:database-locker lockAcquireSleepInterval=5000/
/amq:locker
/amq:jdbcPersistenceAdapter
   /amq:persistenceAdapter
 amq:transportConnectors
amq:transportConnector name=default uri=tcp://0.0.0.0:61616/
 /amq:transportConnectors
 /amq:broker
 bean id=informixAdapter 
   class=org.apache.activemq.store.jdbc.adapter.InformixJDBCAdapter/
 If a message is sent to the broker, I get the following error:
 Routine (empty_blob) can not be resolved.
 InformixJDBCAdapter extends BlobJDBCAdapter
 --
 In org.apache.activemq.store.jdbc.adapter.BlobJDBCAdapter, I saw the 
 following code that issues the error:
 @Override
 public void setStatements(Statements statements) {
 String addMessageStatement = INSERT INTO 
 + statements.getFullMessageTableName()
 + (ID, MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, 
 MSG, XID) VALUES (?, ?, ?, ?, ?, ?, empty_blob(), empty_blob());



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


[jira] [Updated] (AMQ-4639) Servlet does not work with tomcat or tomEE due to Jetty Continuations dependency

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4639:
-

Priority: Minor  (was: Major)

 Servlet does not work with tomcat or tomEE due to Jetty Continuations 
 dependency
 

 Key: AMQ-4639
 URL: https://issues.apache.org/jira/browse/AMQ-4639
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker, Documentation
Affects Versions: 5.8.0
 Environment: RHEL, TomEE+ 1.5.2
Reporter: Chris Owens
Priority: Minor
  Labels: documentation
 Fix For: NEEDS_REVIEWED


 The documentation here (http://activemq.apache.org/tomee.html) states 
 [...]with fully integrated ActiveMQ offering full JMS support to plain war 
 files, Servlets[...] 
 Attempts to run the JMS / AJAX servlet fail, as documented here: 
 http://activemq.2283324.n4.nabble.com/AjaxServlet-on-Tomcat-td3601798.html.
 TomEE team suggests raising a JIRA here 
 (http://openejb.979440.n4.nabble.com/AJAX-JMS-Servlet-in-Tomee-td4664142.html)
 1) Is there a known workaround?
 2) The documentation should be changed to warn potential users that 
 Tomcat/TomEE do not support the JMS Servlet. 



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


[jira] [Updated] (AMQ-4639) Servlet does not work with tomcat or tomEE due to Jetty Continuations dependency

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4639:
-

Fix Version/s: NEEDS_REVIEWED

This would require upgrading to servlet 3.0 as minimum version.

 Servlet does not work with tomcat or tomEE due to Jetty Continuations 
 dependency
 

 Key: AMQ-4639
 URL: https://issues.apache.org/jira/browse/AMQ-4639
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker, Documentation
Affects Versions: 5.8.0
 Environment: RHEL, TomEE+ 1.5.2
Reporter: Chris Owens
  Labels: documentation
 Fix For: NEEDS_REVIEWED


 The documentation here (http://activemq.apache.org/tomee.html) states 
 [...]with fully integrated ActiveMQ offering full JMS support to plain war 
 files, Servlets[...] 
 Attempts to run the JMS / AJAX servlet fail, as documented here: 
 http://activemq.2283324.n4.nabble.com/AjaxServlet-on-Tomcat-td3601798.html.
 TomEE team suggests raising a JIRA here 
 (http://openejb.979440.n4.nabble.com/AJAX-JMS-Servlet-in-Tomee-td4664142.html)
 1) Is there a known workaround?
 2) The documentation should be changed to warn potential users that 
 Tomcat/TomEE do not support the JMS Servlet. 



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


[jira] [Updated] (AMQ-3460) Messages get stuck in the queue for some client sessions, Dispatched Queue grows but Dequeues doesn't move

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-3460:
-

Fix Version/s: AGING_TO_DIE

 Messages get stuck in the queue for some client sessions, Dispatched Queue 
 grows but Dequeues doesn't move
 --

 Key: AMQ-3460
 URL: https://issues.apache.org/jira/browse/AMQ-3460
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.3.1
 Environment: java version 1.5.0_15
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
 Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_15-b04, mixed mode)
Reporter: Timur Evdokimov
Priority: Critical
 Fix For: AGING_TO_DIE

 Attachments: acmq01.png, acmq02.png


 We experience the following problem.
 There's 1 sender thread and 20 listener threads operating on the same queue.
 No other queues are involved.
 Message traffic goes generally OK via the queue, however Number of pending 
 messages goes up one by one.
 Looking at the active customers list, the following appears (see attached 
 screenshot).
 For all sessions but two, the messages are dispatched properly.
 For these two affected sessions, the Dispatched Queue value gots stuck at 
 certain moment and doesn't deliver anymore.
 Eventually, more sessions got affected, and maybe after some hours, the stuck 
 messages got delivered.
 What we tried - adding useCache=false into policyEntry queue= ...  
 tag. Didn't have any effect.



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


[jira] [Updated] (AMQ-4567) JMX operations on broker bypass authorization plugin

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4567:
-

Fix Version/s: 5.9.0
 Assignee: Dejan Bosanac
   Issue Type: New Feature  (was: Bug)

  JMX operations on broker bypass authorization plugin
 -

 Key: AMQ-4567
 URL: https://issues.apache.org/jira/browse/AMQ-4567
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 5.8.0
Reporter: Torsten Mielke
Assignee: Dejan Bosanac
  Labels: authorization
 Fix For: 5.9.0


 When securing the broker using authentication and authorization, any JMX 
 operations on the broker completely bypass the authorization plugin.
 So anyone can modify the broker bypassing the security checks. Also, because 
 of this its not possible to define a read only user for the web console.



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


[jira] [Commented] (AMQ-4567) JMX operations on broker bypass authorization plugin

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808899#comment-13808899
 ] 

Claus Ibsen commented on AMQ-4567:
--

Dejan is there more work on this? Seems like your solutions is securing the JMX 
operations in acceptable way.

  JMX operations on broker bypass authorization plugin
 -

 Key: AMQ-4567
 URL: https://issues.apache.org/jira/browse/AMQ-4567
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.8.0
Reporter: Torsten Mielke
  Labels: authorization
 Fix For: 5.9.0


 When securing the broker using authentication and authorization, any JMX 
 operations on the broker completely bypass the authorization plugin.
 So anyone can modify the broker bypassing the security checks. Also, because 
 of this its not possible to define a read only user for the web console.



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


[jira] [Updated] (AMQ-4601) Redelivery counter does not behave properly when closing consumer

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4601:
-

Fix Version/s: NEEDS_REVIEWED

 Redelivery counter does not behave properly when closing consumer
 -

 Key: AMQ-4601
 URL: https://issues.apache.org/jira/browse/AMQ-4601
 Project: ActiveMQ
  Issue Type: Bug
  Components: JMS client
Affects Versions: 5.8.0
Reporter: Alberto Aresca
 Fix For: NEEDS_REVIEWED

 Attachments: activemq-redelivery-issue.zip


 Attached a test case that does the following: 
 1. Registers 4 consumers. 
 2. Sends a message. 
 3. When the first message is received, it does the following:
 3.1. Unregister the listeners for the consumers. 
 3.2. Close the consumers. 
 3.3. Rollback the transaction. 
 4. Consume the message from a new consumer
 After running the test called TestActiveMqRedeliveryIssue you will see in the 
 logs (among others things): 
 delivery count 1 
 delivery count 5 
 The first one corresponds to the first message and the second one to the 
 message that is consumed from the queue after the stop() procedure was 
 called. 
 As you can see, the count increased by 4, which is the number of consumers. 
 The expected behaviour would be to have the redelivery counter set to 1 when 
 the message is consumed the second time



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


[jira] [Resolved] (AMQ-4152) Problem with activemq-blueprint

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved AMQ-4152.
--

   Resolution: Fixed
Fix Version/s: 5.9.0
 Assignee: Claus Ibsen

AMQ 5.9 can install in Karaf

 Problem with activemq-blueprint
 ---

 Key: AMQ-4152
 URL: https://issues.apache.org/jira/browse/AMQ-4152
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.7.0
Reporter: Alexander Osadchiy
Assignee: Claus Ibsen
 Fix For: 5.9.0

 Attachments: karaf.log


 When I try to install ActiveMQ with blueprint support to the Karaf container:
 {noformat}
 features:install activemq-blueprint
 activemq:create-broker
 {noformat}
 I get an exception:
 {noformat}
 2012-11-01 11:10:14,950 | WARN  | raf-2.2.9/deploy | fileinstall  
 | 6 - org.apache.felix.fileinstall - 3.2.4 | Error while starting 
 bundle: spring:file:/mnt/data/apache-karaf-2.2.9/deploy/localhost-broker.xml
 org.osgi.framework.BundleException: Unresolved constraint in bundle 
 localhost-broker.xml [78]: Unable to resolve 78.0: missing requirement [78.0] 
 package; (package=org.apache.activemq.hooks)
   at 
 org.apache.felix.framework.Felix.resolveBundle(Felix.java:3564)[org.apache.felix.framework-3.2.2.jar:]
   at 
 org.apache.felix.framework.Felix.startBundle(Felix.java:1797)[org.apache.felix.framework-3.2.2.jar:]
   at 
 org.apache.felix.framework.BundleImpl.start(BundleImpl.java:927)[org.apache.felix.framework-3.2.2.jar:]
   at 
 org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1244)[6:org.apache.felix.fileinstall:3.2.4]
   at 
 org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1216)[6:org.apache.felix.fileinstall:3.2.4]
   at 
 org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:505)[6:org.apache.felix.fileinstall:3.2.4]
   at 
 org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)[6:org.apache.felix.fileinstall:3.2.4]
 {noformat}
 Log file is attached



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


[jira] [Updated] (AMQ-4611) Network Failure Issue in Embedded Broker using setStaticBridge=true

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4611:
-

 Priority: Major  (was: Blocker)
Fix Version/s: NEEDS_REVIEWED

 Network Failure Issue in Embedded Broker using setStaticBridge=true
 ---

 Key: AMQ-4611
 URL: https://issues.apache.org/jira/browse/AMQ-4611
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.8.0
 Environment: Production
Reporter: Murtaza
  Labels: AMQ_EMBEDDED_BROKER_WITH_STATIC_BRIDGE
 Fix For: NEEDS_REVIEWED


 Hi,
 I have an embedded broker connecting to my remote server broker using network 
 connector and setStaticBridge=true and static list of destinations. When 
 producer produces the message connecting to my local embedded broker, it 
 successfully forwards to remote broker and stick it to pending messages. 
 Issue comes during network failure when embedded broker is unable to 
 communicate to remote broker and producer keep on producing messages. 
 Producer messages will be stored in KahaDB as a part of persistence setting. 
 When network comes up, I am not able to see old messages produced by producer 
 in the pending message of the remote broker and it doesn't forward any new 
 messages produced by the producer to remote broker thereafter. Only temporary 
 solution is to restart embedded broker. Please help in this urgent issue. My 
 code are as below -
 1. Embedded Broker
 public final class EmbeddedBroker {
 public static Destination destination;
 public static String subject = TOOL.DEFAULT;
 public static boolean topic;
 public static boolean transacted;
 private EmbeddedBroker() {
 }
 public static void main(String[] args) throws Exception {
 BrokerService broker = new BrokerService();
 broker.setUseJmx(true);
 broker.setBrokerName(storeforward);
 broker.addConnector(tcp://localhost:61616);
 broker.setPersistent(true);
 NetworkConnector connector1 = 
 broker.addNetworkConnector(static:failover:+tcp://172.16.102.153:61616);
 connector1.setDuplex(true);
 connector1.setStaticBridge(true);
 ActiveMQConnectionFactory connectionFactory = new 
 ActiveMQConnectionFactory(null, null, failover:tcp://172.16.102.153:61616);
 Connection connection = connectionFactory.createConnection();
 System.out.println(test);
 connection.start();
 Session session = connection.createSession(transacted, 
 Session.AUTO_ACKNOWLEDGE);
 if (topic) {
 destination = session.createTopic(subject);
 } else {
 destination = session.createQueue(subject);
 }
 
 List lst = new ArrayList();
 lst.add(destination);
 connector1.setBridgeTempDestinations(true);
 connector1.setAdvisoryForFailedForward(true);
 connector1.setStaticallyIncludedDestinations(lst);
 
 broker.start();
 // now lets wait forever to avoid the JVM terminating immediately
 Object lock = new Object();
 synchronized (lock) {
 lock.wait();
 }
 }
 }
 2. Producer
 public class ProducerTool extends Thread {
 private Destination destination;
 private int messageCount = 10;
 private long sleepTime;
 private boolean verbose = true;
 private int messageSize = 255;
 private static int parallelThreads = 1;
 private long timeToLive;
 /*private String user = ActiveMQConnection.DEFAULT_USER;
 private String password = ActiveMQConnection.DEFAULT_PASSWORD;
 */
 private String user = null;
 private String password = null;
 
 private String url = failover:tcp://172.16.102.153:61616;
 private String subject = TOOL.DEFAULT;
 private boolean topic;
 private boolean transacted;
 private boolean persistent = true;
 private static Object lockResults = new Object();
 public static void main(String[] args) throws Exception {
 
 ArrayListProducerTool threads = new ArrayList();
 ProducerTool producerTool = new ProducerTool();
 String[] unknown = CommandLineSupport.setOptions(producerTool, args);
 if (unknown.length  0) {
 System.out.println(Unknown options:  + 
 Arrays.toString(unknown));
 System.exit(-1);
 }
 producerTool.showParameters();
 for (int threadCount = 1; threadCount = parallelThreads; 
 threadCount++) {
 producerTool = new ProducerTool();
 CommandLineSupport.setOptions(producerTool, args);
 producerTool.start();
 threads.add(producerTool);
 }
 while (true) {
 IteratorProducerTool itr = 

[jira] [Resolved] (AMQ-4580) ActiveMQ systemUsage configuration.

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved AMQ-4580.
--

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

 ActiveMQ systemUsage configuration.
 -

 Key: AMQ-4580
 URL: https://issues.apache.org/jira/browse/AMQ-4580
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Reporter: krishna
Assignee: Claus Ibsen
Priority: Trivial
 Fix For: 5.10.0


 Hi , 
 I am using Activemq 5.8.0 
 If I do not mention anything about the systemUsage it is taking the default 
 limit values for memoryUsage, storeUsage, tempUsage. 
 And my requirement is I just want to specify the memoryUsage as below in 
 aactivemq.xml 
 systemUsage
 systemUsage
 memoryUsage
 memoryUsage limit=50 MB/
 /memoryUsage
 /systemUsage
   /systemUsage
 but at this point of time when I started activemq I got an error as follow: 
 ERROR | Store limit is 0 mb, whilst the max journal file size for the store 
 is: 32 mb, the store will not accept any data when used. 
 ERROR | Temporary Store limit is 0 mb, whilst the max journal file size for 
 the temporary store is: 32 mb, the temp store will not accept any data when 
 used. 
 As it is not possible to specify only the memoryUsage limit and other two 
 can get the default values, because as the defaults are provided when there 
 is no explicit systemUsage element and via xbean the default creation method 
 does not set a limit so it needs to be explicitly set.
 I guess it would make for a nice simple enhancement if it take default for 
 remaining.
 Thank, 
 Krishna.



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


[jira] [Commented] (AMQ-4580) ActiveMQ systemUsage configuration.

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808904#comment-13808904
 ] 

Claus Ibsen commented on AMQ-4580:
--

Hmm this would need for all options to somehow have a default value associated. 
Sounds a bit dangerous as users dont know what the default values would be then.

 ActiveMQ systemUsage configuration.
 -

 Key: AMQ-4580
 URL: https://issues.apache.org/jira/browse/AMQ-4580
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Reporter: krishna
Priority: Trivial
 Fix For: 5.10.0


 Hi , 
 I am using Activemq 5.8.0 
 If I do not mention anything about the systemUsage it is taking the default 
 limit values for memoryUsage, storeUsage, tempUsage. 
 And my requirement is I just want to specify the memoryUsage as below in 
 aactivemq.xml 
 systemUsage
 systemUsage
 memoryUsage
 memoryUsage limit=50 MB/
 /memoryUsage
 /systemUsage
   /systemUsage
 but at this point of time when I started activemq I got an error as follow: 
 ERROR | Store limit is 0 mb, whilst the max journal file size for the store 
 is: 32 mb, the store will not accept any data when used. 
 ERROR | Temporary Store limit is 0 mb, whilst the max journal file size for 
 the temporary store is: 32 mb, the temp store will not accept any data when 
 used. 
 As it is not possible to specify only the memoryUsage limit and other two 
 can get the default values, because as the defaults are provided when there 
 is no explicit systemUsage element and via xbean the default creation method 
 does not set a limit so it needs to be explicitly set.
 I guess it would make for a nice simple enhancement if it take default for 
 remaining.
 Thank, 
 Krishna.



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


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

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen commented on AMQ-3621:
--

Les this sounds good. Let us know when you think you have all the needed logic 
implemented. Then if you would like to donate the work to ASF, we can get that 
into the AMQ distribution so people have this out of the box.

 Integrate Apache Shiro with ActiveMQ as security solution
 ---

 Key: AMQ-3621
 URL: https://issues.apache.org/jira/browse/AMQ-3621
 Project: ActiveMQ
  Issue Type: Improvement
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] [Updated] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as security solution

2013-10-30 Thread 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:
-

Issue Type: New Feature  (was: Improvement)

 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] [Updated] (AMQ-4547) Activemq-osgi doesn't expose javax.jms.ConnectionFactory in osgi registry

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4547:
-

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

 Activemq-osgi doesn't expose javax.jms.ConnectionFactory in osgi registry
 -

 Key: AMQ-4547
 URL: https://issues.apache.org/jira/browse/AMQ-4547
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 5.8.0
Reporter: filippo balicchia
 Fix For: NEEDS_REVIEWED

 Attachments: pathActiveMq.txt


 Please see the attach for the fix 
 This is a premature solution. At the moment this works for me I'll try it 
 deeply soon
 Anyway,
 suggestions, feedback are wellcome for me



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


[jira] [Commented] (AMQ-4551) WebClients should be able to send persistent messages

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808913#comment-13808913
 ] 

Claus Ibsen commented on AMQ-4551:
--

Patches is welcome

 WebClients should be able to send persistent messages
 -

 Key: AMQ-4551
 URL: https://issues.apache.org/jira/browse/AMQ-4551
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker, Transport
Affects Versions: 5.8.0
 Environment: linux
Reporter: Bhanu

 Hi guys,
 I am not able to send persistent messages from amq.js to the broker. The 
 message intercepted and forwarded by the AjaxServlet and super classes set 
 the persistence mode to false. Can we send persistent messages to ActiveMQ 
 broker from browsers?
 Thanks,
 Bhanu



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


[jira] [Updated] (AMQ-4551) WebClients should be able to send persistent messages

2013-10-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated AMQ-4551:
-

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

 WebClients should be able to send persistent messages
 -

 Key: AMQ-4551
 URL: https://issues.apache.org/jira/browse/AMQ-4551
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker, Transport
Affects Versions: 5.8.0
 Environment: linux
Reporter: Bhanu
Priority: Minor

 Hi guys,
 I am not able to send persistent messages from amq.js to the broker. The 
 message intercepted and forwarded by the AjaxServlet and super classes set 
 the persistence mode to false. Can we send persistent messages to ActiveMQ 
 broker from browsers?
 Thanks,
 Bhanu



--
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.

2013-10-30 Thread 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)


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

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (AMQ-4742) 64-bit Java wrapper ignores wrapper.java.maxmemory values over 4096mb

2013-10-30 Thread Paul Lewis (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Resolved] (AMQ-2826) Look at the possibility of incorporating a cassandra persistence adapter from http://github.com/ticktock/qsandra

2013-10-30 Thread 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] [Updated] (AMQ-4471) Inconsistent messages with the WebSocket/Stomp Demo

2013-10-30 Thread 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

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 {
   
 protected MessageDrivenContext beanCtx;
 public void setMessageDrivenContext(MessageDrivenContext ctx)
 throws EJBException {
 // Set the bean context.
 beanCtx = ctx;
 }
 public void ejbCreate() 

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

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-2748) Jboss Adapter Configuration : connection-factory datasource does not overload ra.xml

2013-10-30 Thread 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}
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE connection-factories
 PUBLIC -//JBoss//DTD JBOSS JCA Config 1.5//EN
 http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd;
 connection-factories
tx-connection-factory
   jndi-nameactivemq/QueueConnectionFactory/jndi-name
   xa-transaction/
   track-connection-by-tx/
   rar-nameactivemq-rar-5.3.2.rar/rar-name
   
 connection-definitionjavax.jms.QueueConnectionFactory/connection-definition
   ServerUrltcp://foo.bar.org:61616/ServerUrl
   !--
   UserNamesa/UserName
   Password/Password
   --
   min-pool-size1/min-pool-size
   max-pool-size20/max-pool-size
   blocking-timeout-millis3/blocking-timeout-millis
   idle-timeout-minutes3/idle-timeout-minutes
/tx-connection-factory
  ...
  ...
 /connection-factories
 {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}
 resourceadapter
 
 resourceadapter-classorg.apache.activemq.ra.ActiveMQResourceAdapter/resourceadapter-class
 config-property
 description
   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'.
 /description
 config-property-nameServerUrl/config-property-name
 config-property-typejava.lang.String/config-property-type
 config-property-valuetcp://localhost:61616/config-property-value
 {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

2013-10-30 Thread 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}
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE connection-factories
 PUBLIC -//JBoss//DTD JBOSS JCA Config 1.5//EN
 http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd;
 connection-factories
tx-connection-factory
   jndi-nameactivemq/QueueConnectionFactory/jndi-name
   xa-transaction/
   track-connection-by-tx/
   rar-nameactivemq-rar-5.3.2.rar/rar-name
   
 connection-definitionjavax.jms.QueueConnectionFactory/connection-definition
   ServerUrltcp://foo.bar.org:61616/ServerUrl
   !--
   UserNamesa/UserName
   Password/Password
   --
   min-pool-size1/min-pool-size
   max-pool-size20/max-pool-size
   blocking-timeout-millis3/blocking-timeout-millis
   idle-timeout-minutes3/idle-timeout-minutes
/tx-connection-factory
  ...
  ...
 /connection-factories
 {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}
 resourceadapter
 
 resourceadapter-classorg.apache.activemq.ra.ActiveMQResourceAdapter/resourceadapter-class
 config-property
 description
   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'.
 /description
 config-property-nameServerUrl/config-property-name
 config-property-typejava.lang.String/config-property-type
 config-property-valuetcp://localhost:61616/config-property-value
 {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-2748) Jboss Adapter Configuration : connection-factory datasource does not overload ra.xml

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE connection-factories
 PUBLIC -//JBoss//DTD JBOSS JCA Config 1.5//EN
 http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd;
 connection-factories
tx-connection-factory
   jndi-nameactivemq/QueueConnectionFactory/jndi-name
   xa-transaction/
   track-connection-by-tx/
   rar-nameactivemq-rar-5.3.2.rar/rar-name
   
 connection-definitionjavax.jms.QueueConnectionFactory/connection-definition
   ServerUrltcp://foo.bar.org:61616/ServerUrl
   !--
   UserNamesa/UserName
   Password/Password
   --
   min-pool-size1/min-pool-size
   max-pool-size20/max-pool-size
   blocking-timeout-millis3/blocking-timeout-millis
   idle-timeout-minutes3/idle-timeout-minutes
/tx-connection-factory
  ...
  ...
 /connection-factories
 {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}
 resourceadapter
 
 resourceadapter-classorg.apache.activemq.ra.ActiveMQResourceAdapter/resourceadapter-class
 config-property
 description
   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'.
 /description
 config-property-nameServerUrl/config-property-name
 config-property-typejava.lang.String/config-property-type
 config-property-valuetcp://localhost:61616/config-property-value
 {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-4109) Negative queue counters

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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() {
   public void run() {
   try {
   

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

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2013-10-30 Thread 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] [Resolved] (AMQ-4425) Tomcat support in ActiveMQ

2013-10-30 Thread 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-4399) jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2013-10-30 Thread 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] [Commented] (AMQ-4425) Tomcat support in ActiveMQ

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Assigned] (AMQ-4367) ActiveMQXAConnectionFactory does not respect redelivery policy

2013-10-30 Thread 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] [Updated] (AMQ-4367) ActiveMQXAConnectionFactory does not respect redelivery policy

2013-10-30 Thread 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

2013-10-30 Thread 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] [Commented] (AMQ-4471) Inconsistent messages with the WebSocket/Stomp Demo

2013-10-30 Thread JIRA

[ 
https://issues.apache.org/jira/browse/AMQ-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (AMQ-4476) ActiveMQ WebSphere 7 JMS Provider - MBD - message consumed even though transaction marked for rollback

2013-10-30 Thread JIRA

[ 
https://issues.apache.org/jira/browse/AMQ-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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/q01cin, \
  1, 5, 1, 
 attributes)
 {code}
 MDB code:
 {code}
 public class MQQueueListener implements MessageListener, MessageDrivenBean {
   
 protected 

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

2013-10-30 Thread JIRA

[ 
https://issues.apache.org/jira/browse/AMQ-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
scriptalert('hallo');/script
{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-4399) jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery

2013-10-30 Thread Gary Tully (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-4399) jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Updated] (AMQ-4399) jdbcPersistenceAdapter takes a long time to shutdown, causing journal recovery

2013-10-30 Thread 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

2013-10-30 Thread 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] [Created] (AMQ-4837) LevelDB corrupted in AMQ cluster

2013-10-30 Thread 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:
persistenceAdapter
replicatedLevelDB
directory=${activemq.data}/leveldb
replicas=3
bind=tcp://0.0.0.0:0
zkAddress=zkserver:2181
zkPath=/activemq/leveldb-stores
/
/persistenceAdapter

=
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 

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

2013-10-30 Thread 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:
   persistenceAdapter
   replicatedLevelDB
   directory=${activemq.data}/leveldb
   replicas=3
   bind=tcp://0.0.0.0:0
   zkAddress=zkserver:2181
   zkPath=/activemq/leveldb-stores
   /
   /persistenceAdapter
 =
 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 
 

amq 5.9 Persistent queue bug

2013-10-30 Thread 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 memoryUsage limit=1024 mb / 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.


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

2013-10-30 Thread 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.


destinationPolicy 
  policyMap 
policyEntries 
  policyEntry queue= producerFlowControl=true
memoryLimit=1mb 
deadLetterStrategy 
  individualDeadLetterStrategy queuePrefix=DLQ.
useQueueForQueueMessages=true processExpired=false / 
/deadLetterStrategy 
pendingQueuePolicy 
vmQueueCursor / 
/pendingQueuePolicy 
  /policyEntry 
/policyEntries 
  /policyMap 
/destinationPolicy

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.


[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

2013-10-30 Thread 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 

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

2013-10-30 Thread 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] [Resolved] (AMQNET-417) DTC Recovery should be done once for each application start

2013-10-30 Thread 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] [Commented] (AMQ-4354) Persist JMX statistics so they survive a restart

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Updated] (AMQ-4354) Persist JMX statistics so they survive a restart

2013-10-30 Thread 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-4313) Queue.isOptimizeStorage() returns true when it should be returning false.

2013-10-30 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Assigned] (AMQ-4325) camel doen't honor credentials set on activemqcomponent bean via spring

2013-10-30 Thread 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.
 bean id=activemq
   class=org.apache.activemq.camel.component.ActiveMQComponent 
 factory-method=activeMQComponent
 constructor-arg index=0 value=${grabber.broker.url} /
 property name=useMessageIDAsCorrelationID value=true/
 property name=userName value=system/
 property name=password value=manager/
 /bean
 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] [Updated] (AMQ-4325) camel doen't honor credentials set on activemqcomponent bean via spring

2013-10-30 Thread 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.
 bean id=activemq
   class=org.apache.activemq.camel.component.ActiveMQComponent 
 factory-method=activeMQComponent
 constructor-arg index=0 value=${grabber.broker.url} /
 property name=useMessageIDAsCorrelationID value=true/
 property name=userName value=system/
 property name=password value=manager/
 /bean
 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] [Resolved] (AMQ-3090) Improve/refine the Send (Message) form of the AMQ Web Console

2013-10-30 Thread 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] [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.

2013-10-30 Thread 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.server.session.SessionHandler.doScope(SessionHandler.java:189)
   at 
 

  1   2   >