[jira] [Updated] (AMQ-5020) Memory leak due to race condition in VMTransportServer/VMTransport classes for spoke broker when hub is down.

2014-02-05 Thread Yuriy Sidelnikov (JIRA)

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

Yuriy Sidelnikov updated AMQ-5020:
--

Attachment: (was: patch.txt)

 Memory leak due to race condition in VMTransportServer/VMTransport classes 
 for spoke broker when hub is down.
 -

 Key: AMQ-5020
 URL: https://issues.apache.org/jira/browse/AMQ-5020
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.9.0
Reporter: Yuriy Sidelnikov
 Attachments: patch.txt


 When spoke is not connected for some reason to a hub(for example, the hub is 
 down) it is trying to reconnect to the hub with increasing timeout between 
 attempts. In attempt to reconnect VMTransportServer class creates linked pair 
 of VMTransport objects(client and server) and started them asynchronously to 
 be used in bridge between local and remote brokers. If hub is still down TCP 
 transport raise exception and then clean up process is trying to destroy this 
 pair of VMtransport objects.
 However if due to race condition VMtransport objects have not been fully 
 initialized yet it is impossible to destroy them properly.
 This excerpt describe how VMtransport  tries to shutdown a peer:
  try {
 peer.transportListener.onCommand(new ShutdownInfo()); 

 } catch (Exception ignore) {
 }
 // let any requests pending a response see an exception
 try {
 peer.transportListener.onException(new 
 TransportDisposedIOException(peer ( + this + ) stopped.));
 } catch (Exception ignore) {
 }
 In some cases(high load, slow servers, etc.)  due to race condition 
 peer.transportListener is not initialized yet on a moment of stopping so it 
 leads to NPE (which will be just ignored) and corresponded VMTransport is not 
 destroyed. 
 The issue can be fixed by attached patch.  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (AMQ-5020) Memory leak due to race condition in VMTransportServer/VMTransport classes for spoke broker when hub is down.

2014-02-05 Thread Yuriy Sidelnikov (JIRA)

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

Yuriy Sidelnikov updated AMQ-5020:
--

Attachment: patch.txt

 Memory leak due to race condition in VMTransportServer/VMTransport classes 
 for spoke broker when hub is down.
 -

 Key: AMQ-5020
 URL: https://issues.apache.org/jira/browse/AMQ-5020
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.9.0
Reporter: Yuriy Sidelnikov
 Attachments: patch.txt


 When spoke is not connected for some reason to a hub(for example, the hub is 
 down) it is trying to reconnect to the hub with increasing timeout between 
 attempts. In attempt to reconnect VMTransportServer class creates linked pair 
 of VMTransport objects(client and server) and started them asynchronously to 
 be used in bridge between local and remote brokers. If hub is still down TCP 
 transport raise exception and then clean up process is trying to destroy this 
 pair of VMtransport objects.
 However if due to race condition VMtransport objects have not been fully 
 initialized yet it is impossible to destroy them properly.
 This excerpt describe how VMtransport  tries to shutdown a peer:
  try {
 peer.transportListener.onCommand(new ShutdownInfo()); 

 } catch (Exception ignore) {
 }
 // let any requests pending a response see an exception
 try {
 peer.transportListener.onException(new 
 TransportDisposedIOException(peer ( + this + ) stopped.));
 } catch (Exception ignore) {
 }
 In some cases(high load, slow servers, etc.)  due to race condition 
 peer.transportListener is not initialized yet on a moment of stopping so it 
 leads to NPE (which will be just ignored) and corresponded VMTransport is not 
 destroyed. 
 The issue can be fixed by attached patch.  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (AMQNET-470) Allow Setting Callback after sending command asynchronously via Transport.

2014-02-05 Thread Shani Elharrar (JIRA)
Shani Elharrar created AMQNET-470:
-

 Summary: Allow Setting Callback after sending command 
asynchronously via Transport.
 Key: AMQNET-470
 URL: https://issues.apache.org/jira/browse/AMQNET-470
 Project: ActiveMQ .Net
  Issue Type: New Feature
  Components: NMS
Reporter: Shani Elharrar
Assignee: Jim Gomes


Hi.

I have a system that processes a lot of messages (~3000 per second) 
asynchronously. I'm trying to move to ActiveMQ as the primary message broker. 

My configuration is that I consume messages from ActiveMQ queue (Using 
individual Acks), I do some processing, And then send them to another queue (In 
the ActiveMQ). Transactions aren't so Important to me since I can handle 
message duplicates in case of crash. But I do want to Ack the messages only 
after I send them to the ActiveMQ. 

So I want to have a Callback after sending the message Asynchronously to 
ActiveMQ.

I managed to edit NMS code to support this, What i've done is :
* Added Callbackable interface with one property (setter  getter) which is a 
delegate equivalent to Action (void, empty arguments).
* Modified Command and IActiveMQMessage to extend that interface
* Modified CommandBase to implement the interface (Trivial setter/getter)
* Modified TCPTransport.Oneway method to check if the callback isn't null and 
if not - invoke it (After it marshals the message).

And it worked flawlessly.

First of all, I need you to vote in/against the feature, And if it's accepted - 
I'm willing to create a patch for this.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (AMQ-5025) activemq-admin help is misleading

2014-02-05 Thread Damien B (JIRA)
Damien B created AMQ-5025:
-

 Summary: activemq-admin help is misleading
 Key: AMQ-5025
 URL: https://issues.apache.org/jira/browse/AMQ-5025
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 5.8.0
Reporter: Damien B


When run without arguments, activemq-admin displays this:
[...]
JMX system property options:
-Dactivemq.jmx.url=jmx service uri (default is: 
'service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi')
-Dactivemq.jmx.user=user name
-Dactivemq.jmx.password=password

Which leads to think that you can pass somehow those arguments on the command 
line.

But either
./activemq-admin bstat 
-Dactivemq.jmx.url=service:jmx:rmi:///jndi/rmi://localhost:/jmxrmi
or
./activemq-admin 
-Dactivemq.jmx.url=service:jmx:rmi:///jndi/rmi://localhost:/jmxrmi bstat 

are accepted by the script, and lead to the seame result:
Connecting to JMX URL: service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi

because activemq-admin does not forward those arguments to Main.class:
JVM args: -Dactivemq.classpath=/master/conf; -Dactivemq.home=/master 
-Dactivemq.base=/master -Dactivemq.conf=/master/conf 
-Dactivemq.data=/master/data -Djava.io.tmpdir=/master/tmp

Those arguments should either be forwarded, or there should be a prominent 
warning that the help doesn't apply to the activemq-admin script.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


Topic messages enqueued X but dequeued is less than the X

2014-02-05 Thread devMQ
Having a simple topic created for 1 consumer subscription, sending X no. of
messages from producer but only (X-y) no. of messages are getting consumed
in the onMessage(). The admin console attached below:
http://activemq.2283324.n4.nabble.com/file/n4677450/ActiveMQ.snapshot.png 

Have tried to acknowledge using explicitly client ack also played around the
setting in the activemq.xml file too: some changes done 

 pendingMessageLimitStrategy
constantPendingMessageLimitStrategy limit=50/
  /pendingMessageLimitStrategy


systemUsage
systemUsage
memoryUsage
memoryUsage limit=64 mb/
/memoryUsage
storeUsage
storeUsage limit=100 gb/
/storeUsage
tempUsage
tempUsage limit=10 gb/
/tempUsage
/systemUsage
/systemUsage

 transportConnectors


transportConnector name=stomp
uri=tcp://localhost:61616?maximumConnections=1000amp;wireformat.maxFrameSize=104857600/
transportConnector name=amqp
uri=amqp://localhost:5672?maximumConnections=1000amp;wireformat.maxFrameSize=104857600/
/transportConnectors

Not sure where the message are getting lost! Some runs give the desired
result - no. of messages  enqueued = no. of messages dequeued. And have the
processing done right in the onMessage().

Any suggestions / thoughts here is appreciated here. (Hope i have
articulated well to understand the issue i am facing)..


Thanks in Advance :)
Maurya






--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Topic-messages-enqueued-X-but-dequeued-is-less-than-the-X-tp4677450.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


[jira] [Updated] (AMQ-4998) Old Web Admin console does not manage - new parameter messageTTL consumerTTL connections.jsp and connections Panel display error messages

2014-02-05 Thread Guilhem RAMBAL (JIRA)

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

Guilhem RAMBAL updated AMQ-4998:


Attachment: connections.patch

This is the patch file

 Old Web Admin console does not manage  - new parameter  messageTTL 
 consumerTTL connections.jsp and connections Panel display error messages
 ---

 Key: AMQ-4998
 URL: https://issues.apache.org/jira/browse/AMQ-4998
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.0
 Environment: CentOS release 6.4 (Final)
 java version 1.6.0_45
 Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
 Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)
Reporter: Guilhem RAMBAL
Priority: Critical
 Attachments: connections.patch


 2014-01-29 13:03:31,358 | WARN  | /admin/connections.jsp | 
 org.eclipse.jetty.servlet.ServletHandler | qtp1721309039-46
 javax.el.PropertyNotFoundException: The class 'com.sun.proxy.$Proxy7' does 
 not have the property 'networkTTL'.
 at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:579)
 at javax.el.BeanELResolver.getValue(BeanELResolver.java:281)
 at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
 at com.sun.el.parser.AstValue.getValue(AstValue.java:138)
 at 
 com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)
 at 
 org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:1001)
 at 
 org.apache.jsp.connections_jsp._jspx_meth_c_forEach_1(org.apache.jsp.connections_jsp:213)
 at 
 org.apache.jsp.connections_jsp._jspService(org.apache.jsp.connections_jsp:95)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
 at 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:389)
 at 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
 at 
 org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652)
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1320)
 at 
 org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
 at 
 org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
 at 
 org.apache.activemq.web.SessionFilter.doFilter(SessionFilter.java:45)
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
 at 
 org.apache.activemq.web.filter.ApplicationContextFilter.doFilter(ApplicationContextFilter.java:102)
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
 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:1291)
 at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:443)
 at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
 at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:521)
 at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
 This template seems to work :
 table id=connections class=sortable autostripe
 thead
 tr
 thName/th
 thMessage TTL/th
 thConsumer TTL/th
 thDynamic Only/th
 thConduit Subscriptions/th
 thBridge Temps/th
 thDecrease Priorities/th
 thDispatch Async/th
 /tr
 /thead
 tbody
 c:forEach items=${requestContext.brokerQuery.networkConnectors} var=nc
 tr
 td${nc.name}/td
 td${nc.messageTTL}/td
 td${nc.consumerTTL}/td
 td${nc.dynamicOnly}/td
 td${nc.conduitSubscriptions}/td
 td${nc.bridgeTempDestinations}/td
 td${nc.decreaseNetworkConsumerPriority}/td
 td${nc.dispatchAsync}/td
 /tr



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (AMQNET-470) Allow Setting Callback after sending command asynchronously via Transport.

2014-02-05 Thread Timothy Bish (JIRA)

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

Timothy Bish updated AMQNET-470:


Priority: Minor  (was: Major)

 Allow Setting Callback after sending command asynchronously via Transport.
 --

 Key: AMQNET-470
 URL: https://issues.apache.org/jira/browse/AMQNET-470
 Project: ActiveMQ .Net
  Issue Type: New Feature
  Components: NMS
Reporter: Shani Elharrar
Assignee: Jim Gomes
Priority: Minor
  Labels: easyfix, features, newbie
   Original Estimate: 2h
  Remaining Estimate: 2h

 Hi.
 I have a system that processes a lot of messages (~3000 per second) 
 asynchronously. I'm trying to move to ActiveMQ as the primary message broker. 
 My configuration is that I consume messages from ActiveMQ queue (Using 
 individual Acks), I do some processing, And then send them to another queue 
 (In the ActiveMQ). Transactions aren't so Important to me since I can handle 
 message duplicates in case of crash. But I do want to Ack the messages only 
 after I send them to the ActiveMQ. 
 So I want to have a Callback after sending the message Asynchronously to 
 ActiveMQ.
 I managed to edit NMS code to support this, What i've done is :
 * Added Callbackable interface with one property (setter  getter) which is 
 a delegate equivalent to Action (void, empty arguments).
 * Modified Command and IActiveMQMessage to extend that interface
 * Modified CommandBase to implement the interface (Trivial setter/getter)
 * Modified TCPTransport.Oneway method to check if the callback isn't null and 
 if not - invoke it (After it marshals the message).
 And it worked flawlessly.
 First of all, I need you to vote in/against the feature, And if it's accepted 
 - I'm willing to create a patch for this.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (AMQNET-470) Allow Setting Callback after sending command asynchronously via Transport.

2014-02-05 Thread Timothy Bish (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQNET-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892160#comment-13892160
 ] 

Timothy Bish commented on AMQNET-470:
-

This doesn't really seem like the best idea.  Can you elaborate on the use case 
a bit.  The send method for a persistent message returns only after receiving 
an ack from the broker, where a send for a non-persistent message returns 
immediately.  You can force sync sends always via configuration or async sends 
always as well.  

 Allow Setting Callback after sending command asynchronously via Transport.
 --

 Key: AMQNET-470
 URL: https://issues.apache.org/jira/browse/AMQNET-470
 Project: ActiveMQ .Net
  Issue Type: New Feature
  Components: NMS
Reporter: Shani Elharrar
Assignee: Jim Gomes
  Labels: easyfix, features, newbie
   Original Estimate: 2h
  Remaining Estimate: 2h

 Hi.
 I have a system that processes a lot of messages (~3000 per second) 
 asynchronously. I'm trying to move to ActiveMQ as the primary message broker. 
 My configuration is that I consume messages from ActiveMQ queue (Using 
 individual Acks), I do some processing, And then send them to another queue 
 (In the ActiveMQ). Transactions aren't so Important to me since I can handle 
 message duplicates in case of crash. But I do want to Ack the messages only 
 after I send them to the ActiveMQ. 
 So I want to have a Callback after sending the message Asynchronously to 
 ActiveMQ.
 I managed to edit NMS code to support this, What i've done is :
 * Added Callbackable interface with one property (setter  getter) which is 
 a delegate equivalent to Action (void, empty arguments).
 * Modified Command and IActiveMQMessage to extend that interface
 * Modified CommandBase to implement the interface (Trivial setter/getter)
 * Modified TCPTransport.Oneway method to check if the callback isn't null and 
 if not - invoke it (After it marshals the message).
 And it worked flawlessly.
 First of all, I need you to vote in/against the feature, And if it's accepted 
 - I'm willing to create a patch for this.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (AMQ-5026) Replicated LevelDB Store getting EOF exception

2014-02-05 Thread kal patel (JIRA)
kal patel created AMQ-5026:
--

 Summary: Replicated LevelDB Store getting EOF exception
 Key: AMQ-5026
 URL: https://issues.apache.org/jira/browse/AMQ-5026
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-leveldb-store
Affects Versions: 5.10.0
Reporter: kal patel


3 brokers setup for ReplicatedLevelDB master/slave conf. 
running producer and slow consumer and doing failover by stopping master 
broker. 

After few failovers, the leveldb throws EOF exception while reading record from 
the store.  
using the latest source code from activemq 5.10 branch. 

The file that has the issue: 
[root@vmx0568 data]# ls -l /solidstate/ldbkp/1f4022e4.log 
-rw-r--r--. 1 root root 91500224 Jan 17 14:44 
/solidstate/ldbkp/1f4022e4.log 
[root@vmx0568 data]# 


Client | main 
2014-01-17 14:44:19,118 | INFO  | locator read: DataLocator(24b41aac, 2283) | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | Seq read: 260217 | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | locator read: DataLocator(24b423ee, 2283) | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | Seq read: 260218 | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | locator read: DataLocator(24b42d02, 2283) | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | Seq read: 260219 | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | locator read: DataLocator(24b43628, 2283) | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | Seq read: 260220 | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | locator read: DataLocator(24b43f6a, 2283) | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | Seq read: 260221 | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | locator read: DataLocator(24b4487e, 2283) | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | Seq read: 260222 | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,118 | INFO  | locator read: DataLocator(24b451a4, 2283) | 
org.apache.activemq.leveldb.LevelDBClient | main 
2014-01-17 14:44:19,124 | INFO  | No IOExceptionHandler registered, ignoring IO 
exception | org.apache.activemq.broker.BrokerService | LevelDB IOException 
handler. 
java.io.EOFException: File '/solidstate/ldbkp/1f4022e4.log' offset: 
91500234 
at 
org.apache.activemq.leveldb.RecordLog$LogReader.read(RecordLog.scala:299) 
at 
org.apache.activemq.leveldb.RecordLog$$anonfun$read$2.apply(RecordLog.scala:564)
 
at 
org.apache.activemq.leveldb.RecordLog$$anonfun$read$2.apply(RecordLog.scala:564)
 
at 
org.apache.activemq.leveldb.RecordLog.get_reader(RecordLog.scala:554) 
at org.apache.activemq.leveldb.RecordLog.read(RecordLog.scala:564) 
at 
org.apache.activemq.leveldb.LevelDBClient.getMessage(LevelDBClient.scala:1318) 
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1257)
 
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1252)
 
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1342)
 
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1341)
 
at 
org.apache.activemq.leveldb.LevelDBClient$RichDB.check$4(LevelDBClient.scala:323)
 
at 
org.apache.activemq.leveldb.LevelDBClient$RichDB.cursorRange(LevelDBClient.scala:325)
 
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply$mcV$sp(LevelDBClient.scala:1341)
 
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1341)
 
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1341)
 
at 
org.apache.activemq.leveldb.LevelDBClient.usingIndex(LevelDBClient.scala:1019) 
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$might_fail_using_index$1.apply(LevelDBClient.scala:1025)
 
at 
org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:549) 
at 
org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1025)
 
at 
org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1340)
 
at 
org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1252) 
at 
org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:713) 
at 

[jira] [Created] (AMQ-5027) Using maven-eclipse-plugin to generate eclipse projects fails for leveldb

2014-02-05 Thread Daniel Kulp (JIRA)
Daniel Kulp created AMQ-5027:


 Summary: Using maven-eclipse-plugin to generate eclipse projects 
fails for leveldb
 Key: AMQ-5027
 URL: https://issues.apache.org/jira/browse/AMQ-5027
 Project: ActiveMQ
  Issue Type: Bug
Reporter: Daniel Kulp
Assignee: Daniel Kulp



The scala stuff in activemq-leveldb-store causes problems if you generate an 
eclipse project using the maven-eclipse-plugin.   Couple things need to be done:

1) Add the scala nature so its created as a scala project instead of java

2) Add the scala dirs as source dirs so eclipse see's them as source and will 
compile them.

git pull request coming



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


activemq pull request: [AMQ-5027] Get mvn eclipse:eclipse work for the leve...

2014-02-05 Thread dkulp
GitHub user dkulp opened a pull request:

https://github.com/apache/activemq/pull/13

[AMQ-5027] Get mvn eclipse:eclipse work for the leveldb stuff



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dkulp/activemq leveldb-eclipse

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq/pull/13.patch


commit 43a88a9367e3680ed427f6bcbe03f87f3f7bac91
Author: Daniel Kulp dk...@apache.org
Date:   2014-02-05T16:41:22Z

Get mvn eclipse:eclipse work for the leveldb stuff





[CLOSED] ActiveMQ Console - moving toward a solution (starting with brainstorming)

2014-02-05 Thread artnaseef
I've chatted with a few folks and feel that now is a good time to focus
directly on the problems identified with the current webconsole.

So, I'm closing this thread at this time.  Thank you!



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-moving-toward-a-solution-starting-with-brainstorming-tp4677405p4677484.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


[HEADS-UP] ActiveMQ 5.10.0 release

2014-02-05 Thread Hadrian Zbarcea
I have enough cycles to cut a 5.10.0 this week off of the current trunk 
as Hiram suggested. Is there any issue/fix I should wait for?


Thanks,
Hadrian


On 02/03/2014 10:41 AM, Hiram Chirino wrote:

I think it's safest to to just call trunk 5.10 now since it is taking
away some functionality.  Would be nice to get some RCs going soon
since trunk is stable right now.

On Thu, Jan 30, 2014 at 3:38 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:

Hi,

I am still planning to release 5.9.1. We need to figure out if we want to
cut 5.9.1 off of the current trunk at a stable checkpoint, or branch it off
5.9.0 and just select the relevant patches. While the feedback on this list
is not conclusive (and I personally favor the 1st approach) I believe most
would favor the 2nd approach. Last week there were over 200 patches that
we'd have to look through and backport. The fastest we could get through
this the sooner we'll have the release, I hope before mid Feb.

Cheers,
Hadrian



On 01/30/2014 03:31 PM, kal123 wrote:

There were post for cutting 5.9.1 any update on timeline for this?



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









Re: [HEADS-UP] ActiveMQ 5.10.0 release

2014-02-05 Thread Daniel Kulp

On Feb 5, 2014, at 12:15 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:

 I have enough cycles to cut a 5.10.0 this week off of the current trunk as 
 Hiram suggested. Is there any issue/fix I should wait for?

Well, now that I’ve reopened many of the web-console related JIRA issues, we 
should go through the ones that do have patches attached and see if we can at 
least apply those patches.

Dan


 
 Thanks,
 Hadrian
 
 
 On 02/03/2014 10:41 AM, Hiram Chirino wrote:
 I think it's safest to to just call trunk 5.10 now since it is taking
 away some functionality.  Would be nice to get some RCs going soon
 since trunk is stable right now.
 
 On Thu, Jan 30, 2014 at 3:38 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
 Hi,
 
 I am still planning to release 5.9.1. We need to figure out if we want to
 cut 5.9.1 off of the current trunk at a stable checkpoint, or branch it off
 5.9.0 and just select the relevant patches. While the feedback on this list
 is not conclusive (and I personally favor the 1st approach) I believe most
 would favor the 2nd approach. Last week there were over 200 patches that
 we'd have to look through and backport. The fastest we could get through
 this the sooner we'll have the release, I hope before mid Feb.
 
 Cheers,
 Hadrian
 
 
 
 On 01/30/2014 03:31 PM, kal123 wrote:
 There were post for cutting 5.9.1 any update on timeline for this?
 
 
 
 --
 View this message in context:
 http://activemq.2283324.n4.nabble.com/activemq-5-9-1-tp4677074.html
 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
 
 
 
 

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com



[jira] [Created] (AMQ-5028) Remove jetty and jsp compiler jars from web-console.war

2014-02-05 Thread Daniel Kulp (JIRA)
Daniel Kulp created AMQ-5028:


 Summary: Remove jetty and jsp compiler jars from web-console.war
 Key: AMQ-5028
 URL: https://issues.apache.org/jira/browse/AMQ-5028
 Project: ActiveMQ
  Issue Type: Bug
  Components: webconsole
Reporter: Daniel Kulp
Assignee: Daniel Kulp



The container that runs the war (like Jetty or Tomcat) will compile the JSP's 
so there is no need for the eclipse core compiler.   Also, there isn't a need 
for the jetty jars.  It looks like there was an attempt to exclude those from 
packaging anyway via maven-war-plugin configs, but those configs aren't working.

patch:
{code}
diff --git a/activemq-web-console/pom.xml b/activemq-web-console/pom.xml
index e5f2e94..93b7fad 100755
--- a/activemq-web-console/pom.xml
?xml version=1.0 encoding=UTF-8?
!--
+++ b/activemq-web-console/pom.xml
@@ -190,6 +190,14 @@
   groupId${project.groupId}/groupId
   artifactIdactivemq-all/artifactId
   /exclusion
+  exclusion
+  groupIdorg.eclipse.jetty/groupId
+  artifactIdjetty-websocket/artifactId
+  /exclusion
+  exclusion
+  groupIdorg.eclipse.jetty/groupId
+  artifactIdjetty-continuation/artifactId
+  /exclusion
   /exclusions
 /dependency
 dependency
@@ -235,6 +243,7 @@
   groupIdorg.eclipse.jdt/groupId
   artifactIdcore/artifactId
   version3.1.1/version
+  scopetest/scope
 /dependency
 dependency
   groupIdorg.slf4j/groupId
@@ -259,16 +268,6 @@
   artifactIdstandard/artifactId
 /dependency
 
-!-- XStream marshalling --
-dependency
-  groupIdxpp3/groupId
-  artifactIdxpp3/artifactId
-/dependency
-dependency
-  groupIdcom.thoughtworks.xstream/groupId
-  artifactIdxstream/artifactId
-/dependency
-
 !-- used for testing --
 dependency
   groupIdjunit/groupId

{code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Issue Comment Deleted] (AMQ-4174) Deleting/moving a message from queue overview should redirect back to overview of the queue

2014-02-05 Thread Daniel Kulp (JIRA)

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

Daniel Kulp updated AMQ-4174:
-

Comment: was deleted

(was: Web console is to be replaced by HawtIO in the next release. )

 Deleting/moving a message from queue overview should redirect back to 
 overview of the queue
 ---

 Key: AMQ-4174
 URL: https://issues.apache.org/jira/browse/AMQ-4174
 Project: ActiveMQ
  Issue Type: Improvement
  Components: webconsole
Affects Versions: 5.7.0
Reporter: Torbjørn Skyberg Knutsen
Priority: Minor
 Attachments: AMQ4174.patch


 When one deletes a message from the overview of a queue, one is redirected to 
 the overview showing all queues. This makes deleting multiple messages 
 tedious work, since you have to find the queue to delete from for each 
 message that you want to delete. The same goes for moving a message, you get 
 thrown back to start instead of the queue overview, which would be nice in 
 cases where you want to move multiple messages in the same queue (which is 
 quite often, specially for dead-letter queues).
 Is it possible to change the redirect to the overview of the queue that was 
 moved/deleted from?



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Issue Comment Deleted] (AMQ-4499) Enhance the web console

2014-02-05 Thread Daniel Kulp (JIRA)

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

Daniel Kulp updated AMQ-4499:
-

Comment: was deleted

(was: The web console is going to be replaced by hawtio in the next release. )

 Enhance the web console
 ---

 Key: AMQ-4499
 URL: https://issues.apache.org/jira/browse/AMQ-4499
 Project: ActiveMQ
  Issue Type: Improvement
  Components: webconsole
Affects Versions: 5.8.0
Reporter: hengyunabc
Priority: Trivial
 Attachments: activemq-broker_patch.txt, 
 activemq-web-console_patch.txt, activemq-web_path.txt, connection2.png, 
 connectors2.png, queue2.png, topic2.png, topic_active_producers2.png


 1. https://issues.apache.org/jira/browse/AMQ-4393
 AMQ-4393 fix one error about the objectname of MBean, there are some other 
 objectnames of MBean are not correct.
 2. I found that the web console do not show the info of producers, I do not 
 know why, so I try to enhance the web console.

 3. I try to enable control the connector in the web console.
Considering such  scene: there are tow ports in a broker: inputPort and 
 outputPort.
When I want to upgrade the activemq totally, I can jsut stop the inputPort 
 ,and wait for the queue/topic to be consumered through the outputPort.
Then, stop the activemq, rm all old activemq files(include data files). 
 Finally, deploy the new activemq, a clear upgrade finish.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Issue Comment Deleted] (AMQ-4175) Adding a retry-button

2014-02-05 Thread Daniel Kulp (JIRA)

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

Daniel Kulp updated AMQ-4175:
-

Comment: was deleted

(was: Console to be replaced by hawtio in 5.9)

 Adding a retry-button
 -

 Key: AMQ-4175
 URL: https://issues.apache.org/jira/browse/AMQ-4175
 Project: ActiveMQ
  Issue Type: New Feature
  Components: webconsole
Reporter: Torbjørn Skyberg Knutsen
Priority: Minor
 Attachments: browse.jsp, message.jsp


 In the project I'm working on, we have set up to have one dead-letter queue 
 for each queue. In the web console of the AMQ 5.3.0 instance that was running 
 up until recently (we upgraded to 5.7.0), there was a link for retry in 
 both the overview of a queue and the overview of a message. What this did was 
 to move the message to its intended destination, for retrying failed messages 
 that wound up in a dead-letter queue.
 I could not see this feature in AMQ 5.7.0, and after a bit of investigation, 
 it turned out that this was added by the people who set up AMQ 5.3.0.
 In my opinion this is a really nice thing to have, specially if you have a 
 large number of queues. Going through the list of queues and finding the 
 correct one to move to for each failed message is a lot more work than just 
 clicking a retry-button.
 I'll attach my tweaked versions of browse.jsp and message.jsp, containing the 
 retry button. If you decide to take it in, it should be generalized a little 
 (right now the prefixes we set up to use for dead-letter queues and topics 
 are hard-coded). There are also a few minor tweaks, most notably one that 
 makes sure that the whole queue name is showing in the dropdown for selecting 
 a queue to move/copy to (having ~80 queues, most with the same prefix in 
 their name, gave only the four last letters of the queue name to identify it 
 by when it was shortened, impossible to work with..)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Issue Comment Deleted] (AMQ-3370) Bulk Move/Copy feature for web console

2014-02-05 Thread Daniel Kulp (JIRA)

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

Daniel Kulp updated AMQ-3370:
-

Comment: was deleted

(was: Web console to be replaced by hawtio in v5.9)

 Bulk Move/Copy feature for web console
 --

 Key: AMQ-3370
 URL: https://issues.apache.org/jira/browse/AMQ-3370
 Project: ActiveMQ
  Issue Type: Wish
  Components: webconsole
Reporter: Julien Moumné
Priority: Minor

 Provide the ability in browse.jsp to select multiple messages and apply one 
 of the following action : Move, Copy, Delete.
 This functionality would also include a Select All option which would 
 select all messages matched by the current browse filter.
 Mentioned in https://issues.apache.org/jira/browse/AMQ-1326



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


Re: [HEADS-UP] ActiveMQ 5.10.0 release

2014-02-05 Thread jb

Hi Hadrian,

I have some OSGi related enhancements and fixes to push, but nothing 
blocker for the release (the blockers haven been already pushed).


Regards
JB

On 2014-02-05 18:15, Hadrian Zbarcea wrote:

I have enough cycles to cut a 5.10.0 this week off of the current
trunk as Hiram suggested. Is there any issue/fix I should wait for?

Thanks,
Hadrian


On 02/03/2014 10:41 AM, Hiram Chirino wrote:

I think it's safest to to just call trunk 5.10 now since it is taking
away some functionality.  Would be nice to get some RCs going soon
since trunk is stable right now.

On Thu, Jan 30, 2014 at 3:38 PM, Hadrian Zbarcea hzbar...@gmail.com 
wrote:

Hi,

I am still planning to release 5.9.1. We need to figure out if we 
want to
cut 5.9.1 off of the current trunk at a stable checkpoint, or branch 
it off
5.9.0 and just select the relevant patches. While the feedback on 
this list
is not conclusive (and I personally favor the 1st approach) I believe 
most
would favor the 2nd approach. Last week there were over 200 patches 
that
we'd have to look through and backport. The fastest we could get 
through

this the sooner we'll have the release, I hope before mid Feb.

Cheers,
Hadrian



On 01/30/2014 03:31 PM, kal123 wrote:

There were post for cutting 5.9.1 any update on timeline for this?



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







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

2014-02-05 Thread JIRA

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

Jean-Baptiste Onofré reassigned AMQ-4828:
-

Assignee: Jean-Baptiste Onofré

 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
Assignee: Jean-Baptiste Onofré
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.5#6160)


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

2014-02-05 Thread JIRA

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

Jean-Baptiste Onofré commented on AMQ-4828:
---

I reproduced the issue on 5.9.0 outside Karaf (ActiveMQ as standalone).

As we agreed to remove hawt.io from the default console set, I gonna fix this 
issue in the old new web console ;)

 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
Assignee: Jean-Baptiste Onofré
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.5#6160)


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

2014-02-05 Thread JIRA

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

Jean-Baptiste Onofré updated AMQ-4828:
--

Fix Version/s: 5.10.0

 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
Assignee: Jean-Baptiste Onofré
Priority: Minor
  Labels: web-console
 Fix For: 5.10.0

 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.5#6160)


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

2014-02-05 Thread JIRA

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

Jean-Baptiste Onofré commented on AMQ-4828:
---

Actually, I think that the networkConnector proxy in the web console is not up 
to date. Even putting the NetworkTTL in the networkConnector/ configuration, 
it doesn't work.

I gonna fix that.

 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
Assignee: Jean-Baptiste Onofré
Priority: Minor
  Labels: web-console
 Fix For: 5.10.0

 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.5#6160)


activemq pull request: Couple of easy fixes for web console

2014-02-05 Thread dkulp
GitHub user dkulp opened a pull request:

https://github.com/apache/activemq/pull/14

Couple of easy fixes for web console



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dkulp/activemq easy-fixes

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq/pull/14.patch


commit 3321f99643edc5ebc4bd8f4b9eaea90744fc6d60
Author: Daniel Kulp dk...@apache.org
Date:   2014-02-05T20:19:44Z

[AMQ-4174] Redirect back to queue overview after delete/moving message
Patch from Robert Balent applied

commit 17d1489c62b6bc33b77bce38eeecdc357f9c61bf
Author: Daniel Kulp dk...@apache.org
Date:   2014-02-05T21:08:26Z

[AMQ-5029] embedded webconsole broker does not resolve activemq.data system 
property





[jira] [Created] (AMQ-5029) embedded webconsole broker does not resolve activemq.data system property

2014-02-05 Thread Daniel Kulp (JIRA)
Daniel Kulp created AMQ-5029:


 Summary: embedded webconsole broker does not resolve activemq.data 
system property
 Key: AMQ-5029
 URL: https://issues.apache.org/jira/browse/AMQ-5029
 Project: ActiveMQ
  Issue Type: Bug
  Components: webconsole
Affects Versions: 5.9.0
Reporter: Daniel Kulp
Assignee: Daniel Kulp



When using jetty:run in activemq-web-console or deploying the war into tomcat, 
the activemq.data system property is not resolved into a directory name for the 
kahadb.   Thus, a ${acitvemq.data} directory is created which is strange 
looking.   The property placeholder thing needs to be added to the spring 
config.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


Re: [HEADS-UP] ActiveMQ 5.10.0 release

2014-02-05 Thread Paul Gale
Hi,

If release 5.10.0 of ActiveMQ is going to be cut then you might as
well update the bundled Camel from 2.12.1 to 2.12.2, no? According to
the Camel site this dot release contains 145 fixes.

Thanks,
Paul

On Wed, Feb 5, 2014 at 3:32 PM,  j...@nanthrax.net wrote:
 Hi Hadrian,

 I have some OSGi related enhancements and fixes to push, but nothing blocker
 for the release (the blockers haven been already pushed).

 Regards
 JB


 On 2014-02-05 18:15, Hadrian Zbarcea wrote:

 I have enough cycles to cut a 5.10.0 this week off of the current
 trunk as Hiram suggested. Is there any issue/fix I should wait for?

 Thanks,
 Hadrian


 On 02/03/2014 10:41 AM, Hiram Chirino wrote:

 I think it's safest to to just call trunk 5.10 now since it is taking
 away some functionality.  Would be nice to get some RCs going soon
 since trunk is stable right now.

 On Thu, Jan 30, 2014 at 3:38 PM, Hadrian Zbarcea hzbar...@gmail.com
 wrote:

 Hi,

 I am still planning to release 5.9.1. We need to figure out if we want
 to
 cut 5.9.1 off of the current trunk at a stable checkpoint, or branch it
 off
 5.9.0 and just select the relevant patches. While the feedback on this
 list
 is not conclusive (and I personally favor the 1st approach) I believe
 most
 would favor the 2nd approach. Last week there were over 200 patches that
 we'd have to look through and backport. The fastest we could get through
 this the sooner we'll have the release, I hope before mid Feb.

 Cheers,
 Hadrian



 On 01/30/2014 03:31 PM, kal123 wrote:

 There were post for cutting 5.9.1 any update on timeline for this?



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







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

2014-02-05 Thread Arthur Naseef (JIRA)

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

Arthur Naseef reassigned AMQ-4813:
--

Assignee: Arthur Naseef

 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
Assignee: Arthur Naseef
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.5#6160)


activemq pull request: Couple of easy fixes for web console

2014-02-05 Thread dkulp
Github user dkulp closed the pull request at:

https://github.com/apache/activemq/pull/14



[jira] [Created] (AMQ-5030) Upgrade Camel to latest 2.12.x patch

2014-02-05 Thread Claus Ibsen (JIRA)
Claus Ibsen created AMQ-5030:


 Summary: Upgrade Camel to latest 2.12.x patch
 Key: AMQ-5030
 URL: https://issues.apache.org/jira/browse/AMQ-5030
 Project: ActiveMQ
  Issue Type: Task
  Components: activemq-camel
Reporter: Claus Ibsen
Priority: Blocker
 Fix For: 5.10.0


We need to upgrade to latest Camel 2.12.3 release to pickup some very important 
fixes.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


Re: [HEADS-UP] ActiveMQ 5.10.0 release

2014-02-05 Thread Claus Ibsen
On Thu, Feb 6, 2014 at 12:25 AM, Paul Gale paul.n.g...@gmail.com wrote:
 Hi,

 If release 5.10.0 of ActiveMQ is going to be cut then you might as
 well update the bundled Camel from 2.12.1 to 2.12.2, no? According to
 the Camel site this dot release contains 145 fixes.


Yes I have logged ticket for this
https://issues.apache.org/jira/browse/AMQ-5030

We need to release Camel first and then upgrade AMQ to include the
latest Camel release.
The Camel source code on 2.12 branch is ready for release, so if you
have free cycles then IMHO its better to start with Camel and then
afterwards AMQ.

 Thanks,
 Paul

 On Wed, Feb 5, 2014 at 3:32 PM,  j...@nanthrax.net wrote:
 Hi Hadrian,

 I have some OSGi related enhancements and fixes to push, but nothing blocker
 for the release (the blockers haven been already pushed).

 Regards
 JB


 On 2014-02-05 18:15, Hadrian Zbarcea wrote:

 I have enough cycles to cut a 5.10.0 this week off of the current
 trunk as Hiram suggested. Is there any issue/fix I should wait for?

 Thanks,
 Hadrian


 On 02/03/2014 10:41 AM, Hiram Chirino wrote:

 I think it's safest to to just call trunk 5.10 now since it is taking
 away some functionality.  Would be nice to get some RCs going soon
 since trunk is stable right now.

 On Thu, Jan 30, 2014 at 3:38 PM, Hadrian Zbarcea hzbar...@gmail.com
 wrote:

 Hi,

 I am still planning to release 5.9.1. We need to figure out if we want
 to
 cut 5.9.1 off of the current trunk at a stable checkpoint, or branch it
 off
 5.9.0 and just select the relevant patches. While the feedback on this
 list
 is not conclusive (and I personally favor the 1st approach) I believe
 most
 would favor the 2nd approach. Last week there were over 200 patches that
 we'd have to look through and backport. The fastest we could get through
 this the sooner we'll have the release, I hope before mid Feb.

 Cheers,
 Hadrian



 On 01/30/2014 03:31 PM, kal123 wrote:

 There were post for cutting 5.9.1 any update on timeline for this?



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








-- 
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Make your Camel applications look hawt, try: http://hawt.io