[jira] [Resolved] (AMQ-5186) AMQP producers aren't removed
[ https://issues.apache.org/jira/browse/AMQ-5186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dejan Bosanac resolved AMQ-5186. Resolution: Fixed Fixed on trunk with commit ff64b14bc78466df96d16b1d04e862a7ddef3204 AMQP producers aren't removed - Key: AMQ-5186 URL: https://issues.apache.org/jira/browse/AMQ-5186 Project: ActiveMQ Issue Type: Bug Components: AMQP Affects Versions: 5.9.0 Reporter: Dejan Bosanac Assignee: Dejan Bosanac Fix For: 5.10.0 Consumers are only closed when the whole session is removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
Build failed in Jenkins: ActiveMQ-Trunk-Deploy #942
See https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/942/ -- Failed to access build log java.io.IOException: remote file operation failed: /home/jenkins/jenkins-slave/workspace/ActiveMQ-Trunk-Deploy at hudson.remoting.Channel@1bd13118:ubuntu6 at hudson.FilePath.act(FilePath.java:916) at hudson.FilePath.act(FilePath.java:893) at hudson.FilePath.toURI(FilePath.java:1042) at hudson.tasks.MailSender.createFailureMail(MailSender.java:278) at hudson.tasks.MailSender.getMail(MailSender.java:153) at hudson.tasks.MailSender.execute(MailSender.java:101) at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.cleanUp(MavenModuleSetBuild.java:1058) at hudson.model.Run.execute(Run.java:1752) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: hudson.remoting.ChannelClosedException: channel is already closed at hudson.remoting.Channel.send(Channel.java:541) at hudson.remoting.Request.call(Request.java:129) at hudson.remoting.Channel.call(Channel.java:739) at hudson.FilePath.act(FilePath.java:909) ... 10 more Caused by: java.io.IOException at hudson.remoting.Channel.close(Channel.java:1027) at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:110) at hudson.remoting.PingThread.ping(PingThread.java:120) at hudson.remoting.PingThread.run(PingThread.java:81) Caused by: java.util.concurrent.TimeoutException: Ping started on 1400194937838 hasn't completed at 1400195177839 ... 2 more
[jira] [Created] (AMQ-5177) ActiveMQ Web Console URL log message hard coded to localhost
Jason Sherman created AMQ-5177:
--
Summary: ActiveMQ Web Console URL log message hard coded to
localhost
Key: AMQ-5177
URL: https://issues.apache.org/jira/browse/AMQ-5177
Project: ActiveMQ
Issue Type: Bug
Environment: Apache ActiveMQ 5.9.1
OSX
Reporter: Jason Sherman
Priority: Minor
Fix For: 5.9.1
The following message is logged even if the Jetty Server Host is set to use a
specific IP:
{code}
INFO | ActiveMQ WebConsole available at http://localhost:8161/
{code}
Looking at org/apache/activemq/web/WebConsoleStarter.java, the URL is hard
coded to localhost:
{code}
// for embedded console log what port it uses
if (embedded.equals(webconsoleType)) {
// show the url for the web consoles / main page so people can spot
it
String port = System.getProperty(jetty.port);
if (port != null) {
LOG.info(ActiveMQ WebConsole available at
http://localhost:{}/;, port);
}
}
{code}
The log message doesn't account for users setting the Jetty host property.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-5188) AMQ broker throws OutOfMemoryError even when global flow-control memoryUsage limit is imposed
[ https://issues.apache.org/jira/browse/AMQ-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Samson updated AMQ-5188: Attachment: AMQ_heap2.png AMQ_heap1.png activemq.xml QpidProducerAMQOutOfMemory.java qpid-producer.tar Attached sample code to reproduce the OutOfMemory along with my AMQ configuration. Also notice heap snapshot pictures showing the leak.in the Queue messagesWaitingForSpace map. AMQ broker throws OutOfMemoryError even when global flow-control memoryUsage limit is imposed - Key: AMQ-5188 URL: https://issues.apache.org/jira/browse/AMQ-5188 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: AMQ 5.8.0 broker running on 64-bit Linux AMQP Qpid (.26) JMS producers running on 64-bin Linux Reporter: Michael Samson Attachments: AMQ_heap1.png, AMQ_heap2.png, QpidProducerAMQOutOfMemory.java, activemq.xml, qpid-producer.tar * 5.8.0 broker was configured with persistence=false and a global memoryUsage limit=700 mb/ * 5.8.0 broker JVM memory was set to default of 1G * No active consumers * 10 Qpid (version .26) AMQP producers sent messages to 10 broker queues until flow control was reached * Over time the AMQP connections/producers were closed and recreated and they reattempted to send messages. As this cycle continues, eventually ActiveMQ threw OutOfMemoryErrors. I grabbed a heap dump and ActiveMQTextMessages consumed 874M of the heap. Taking a closer look, it appears that each org.apache.activemq.broker.region.Queue's messagesWaitingForSpace map grows unbounded and causes the OutOfMemory. I will attach a sample maven program that reproduces the problem along with my activemq configuration, heap screenshots, etc. Are their any workarounds to this issue? It is a potential use case for our customers if their queue consumers die for an extended period of time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5160) Wildcard subscriptions bypass Authentication / Authorization
[ https://issues.apache.org/jira/browse/AMQ-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994133#comment-13994133 ] Surf commented on AMQ-5160: --- Hey [~dhirajsb] Thanks a lot. It is working on WS and MQTT both. One another weird behaviour( Can't find the reason and might not be related to this JIRA!) Steps to recreate : 1. Download files that i uploaded 2. Connect to broker with two_user 3. Take another client and connect to broker with one_admin and subscribe to # 4. Publish in two_user You will see message leaked to admin. Now if you connect to one_admin first then it wont happen !! Wildcard subscriptions bypass Authentication / Authorization Key: AMQ-5160 URL: https://issues.apache.org/jira/browse/AMQ-5160 Project: ActiveMQ Issue Type: Bug Components: MQTT Affects Versions: 5.9.1 Reporter: Surf Priority: Critical Labels: authentication, authorization, mqtt, security Fix For: 5.10.0 Attachments: activemq.xml, groups.properties, login.config, patch.txt, users.properties I am using MQTT on AMQ 5.9.1 After latest MQTT hardening from [~dhirajsb] , there is an issue of MQTT retained messages. Simple case: Set Authentication / Authorization for two different TOPICS. Send retained message to one topic. Try to subscribe # with other second user. It will show retained messages published by TOPIC 1. here i have attached test configurations. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: AMQP 1.0 connection property names
On 05/14/2014 09:48 PM, Rob Godfrey wrote: On 14 May 2014 02:23, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 13 May 2014 17:31, Gordon Sim g...@redhat.com wrote: [...] For indicating the use of proton I'd suggest we define a qpid-proton-version property or some such (and then a qpid-messaging-version / qpid-jms-version / whatever) - i.e. each layer of library might add it's own connection properties to indicate its presence / version. I like that. [...] How about process_name and process_id then? As above - those work for me... If we're getting close to agreeing on these, we should probably cross post to the amqp comments list. Ok, I'll submit a request for these two.
[jira] [Commented] (AMQ-5188) AMQ broker throws OutOfMemoryError even when global flow-control memoryUsage limit is imposed
[ https://issues.apache.org/jira/browse/AMQ-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999834#comment-13999834 ] Timothy Bish commented on AMQ-5188: --- You should run your tests against a 5.10-SNAPSHOT as there are a number of fixes since 5.8 that could resolve this. AMQ broker throws OutOfMemoryError even when global flow-control memoryUsage limit is imposed - Key: AMQ-5188 URL: https://issues.apache.org/jira/browse/AMQ-5188 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: AMQ 5.8.0 broker running on 64-bit Linux AMQP Qpid (.26) JMS producers running on 64-bin Linux Reporter: Michael Samson Attachments: AMQ_heap1.png, AMQ_heap2.png, QpidProducerAMQOutOfMemory.java, activemq.xml, qpid-producer.tar * 5.8.0 broker was configured with persistence=false and a global memoryUsage limit=700 mb/ * 5.8.0 broker JVM memory was set to default of 1G * No active consumers * 10 Qpid (version .26) AMQP producers sent messages to 10 broker queues until flow control was reached * Over time the AMQP connections/producers were closed and recreated and they reattempted to send messages. As this cycle continues, eventually ActiveMQ threw OutOfMemoryErrors. I grabbed a heap dump and ActiveMQTextMessages consumed 874M of the heap. Taking a closer look, it appears that each org.apache.activemq.broker.region.Queue's messagesWaitingForSpace map grows unbounded and causes the OutOfMemory. I will attach a sample maven program that reproduces the problem along with my activemq configuration, heap screenshots, etc. Are their any workarounds to this issue? It is a use case for our customers if their queue consumers die for an extended period of time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQ-5189) Rollback on XASession when closing back to pool
Benjamin Graf created AMQ-5189: -- Summary: Rollback on XASession when closing back to pool Key: AMQ-5189 URL: https://issues.apache.org/jira/browse/AMQ-5189 Project: ActiveMQ Issue Type: Bug Components: activemq-pool Affects Versions: 5.7.0 Environment: Windows, UNIX Reporter: Benjamin Graf If you have a pool of XASession under load (heavy load might be necessary) I register sometimes following Exception Cannot rollback() inside an XASession in afterCompletion synchronisation. After some analysis and patching with logging I recognized that the session object is returned back to pool before setting the xa flag back to false. This leads to the effect that this session gets be used again by another thread while the earlier one switches the xa flag to false. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQCPP-543) message producer send never blocking when using producer flow control
[
https://issues.apache.org/jira/browse/AMQCPP-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Mamen updated AMQCPP-543:
---
Attachment: activemq-cpp_AMQCPP-543_v0.patch
Hi,
I compare with the java client, and uploaded a patch that I think does pretty
much what the java do.
The java assume the latest version of the protocol by default and when it
receives a wireFormatInfo command from the broker, saves the protocol version.
this is done in an AtomicInteger.
ActiveMQMessageProducer.java
{code}
// Enable producer window flow control if protocol 3 and the window
// size 0
if (session.connection.getProtocolVersion() = 3
this.info.getWindowSize() 0) {
producerWindow = new MemoryUsage(Producer Window: + producerId);
producerWindow.setExecutor(session.getConnectionExecutor());
producerWindow.setLimit(this.info.getWindowSize());
producerWindow.start();
}
{code}
Can you explain why the comment says protocol 3, but the code actually does
= 3? Perhaps you can also review the patch?
message producer send never blocking when using producer flow control
-
Key: AMQCPP-543
URL: https://issues.apache.org/jira/browse/AMQCPP-543
Project: ActiveMQ C++ Client
Issue Type: New Feature
Components: Openwire
Affects Versions: 3.8.2
Reporter: Christian Mamen
Assignee: Timothy Bish
Priority: Minor
Attachments: activemq-cpp_AMQCPP-543_v0.patch
For testing,
message producer is set to non-persisted mode, with the connection producer
window size to 1MB. (the broker enables the producer flow control and set the
memory limit to ~10MB with vm only storage)
I notice that when i don't have any message consumer, the broker notify me
that the memory limit is reached, that the producer will be throttled (as i
would expect), however the producer never blocks on a send, as if the window
size has no effect.
while digging into ActiveMQProducerKernel.cpp,
I notice the private member memoryUsage (auto_ptr) is never initialized. and
there's a TODO in the code ?
{code}
ActiveMQProducerKernel::ActiveMQProducerKernel(
[...]
// TODO - Check for need of MemoryUsage if there's a producer Windows size
//and the Protocol version is greater than 3.
}
{code}
I tried initializing the memoryUsage, and producer seem to block as expected
on a send, when the limit is reached.
{code}
ActiveMQProducerKernel::ActiveMQProducerKernel(
[...]
// TODO - Check for need of MemoryUsage if there's a producer Windows size
//and the Protocol version is greater than 3.
if (session-getConnection()-getProducerWindowSize()) {
this-memoryUsage.reset( new
MemoryUsage(session-getConnection()-getProducerWindowSize()) );
}
}
{code}
I'm not sure what is the proper fix,
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (AMQ-5190) deadlock between producer and consumer
Randy Prager created AMQ-5190:
-
Summary: deadlock between producer and consumer
Key: AMQ-5190
URL: https://issues.apache.org/jira/browse/AMQ-5190
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.5.0
Environment: Linux, Spring, Java 6
Reporter: Randy Prager
We observed a deadlock in the broker, see the 2 below.
# we use spring to configure the broker, producer and consumer
# producer and consumer share the same pooled connection factory
# we have producer flow control enabled
h2. Deadlock
{noformat}
incommingMessageListenerContainer-1 prio=10 tid=0x7f5a7d0d8800 nid=0xdae5
waiting for monitor entry [0x7f5a00cef000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:39)
- waiting to lock 0xc43cf2a8 (a java.lang.Object)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(ActiveMQConnection.java:1265)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1259)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1863)
at
org.apache.activemq.ActiveMQSession.sendAck(ActiveMQSession.java:2029)
at
org.apache.activemq.ActiveMQSession.sendAck(ActiveMQSession.java:2024)
at
org.apache.activemq.ActiveMQMessageConsumer.afterMessageIsConsumed(ActiveMQMessageConsumer.java:871)
- locked 0xc5f111e8 (a java.util.LinkedList)
at
org.apache.activemq.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:585)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:429)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:310)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1059)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1051)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:948)
at java.lang.Thread.run(Thread.java:662)
{noformat}
{noformat}
default-selector prio=10 tid=0x7f5a7cf35000 nid=0xdae8 waiting on
condition [0x7f5a009eb000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xc4354548 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:306)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:94)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
- locked 0xc43cf2a8 (a java.lang.Object)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(ActiveMQConnection.java:1265)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1259)
at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1744)
- locked 0xc6343788 (a java.lang.Object)
at
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:231)
at org.apache.activemq.pool.PooledProducer.send(PooledProducer.java:74)
- locked 0xc62e6548 (a
org.apache.activemq.ActiveMQMessageProducer)
at org.apache.activemq.pool.PooledProducer.send(PooledProducer.java:59)
at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:592)
at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:569)
at
org.springframework.jms.core.JmsTemplate$3.doInJms(JmsTemplate.java:536)
at
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:466)
at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:534)
{noformat}
h2. Producer Flow Control Thread
{noformat}
ActiveMQ Task-1 daemon prio=10 tid=0x7f5a7d06f800 nid=0xdae0 in
Object.wait()
[jira] [Commented] (AMQ-4927) clients can not receive mqtt retained message
[ https://issues.apache.org/jira/browse/AMQ-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000114#comment-14000114 ] Paddy commented on AMQ-4927: I'm using 5.9.1 and I still see this issue. It is not resolved. clients can not receive mqtt retained message - Key: AMQ-4927 URL: https://issues.apache.org/jira/browse/AMQ-4927 Project: ActiveMQ Issue Type: Bug Environment: activemq 5.9.0 Reporter: Frank Wen Assignee: Rob Davies Fix For: 5.9.1, 5.10.0 I use activemq 5.9.0 as mqtt server, and eclipse paho as the mqtt client package. But the client can not receive the retained message. If I use Apollo, it works fine. Is it a bug? or I miss some configuration? Someone else have the same problem, the discussion is here: http://activemq.2283324.n4.nabble.com/Retained-Flag-in-MQTT-td4668333.html -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: AMQP 1.0 connection property names
I don't object, but one thing that strikes me as a little odd with the original names was the use of both '.' and '_' as separators (qpid.client_pid vs qpid.client.pid). Now I don't know what conventions these names are supposed to follow, but my best guess would be that '.' should be used for separating namespaces and '_' for separating words in a compound phrase. In this case I can see it both ways, but if you think there might be other process related things in the future then it might be worth thinking of process as a namespace and going with process.name and process.id. --Rafael On Wed, May 14, 2014 at 12:54 PM, Gordon Sim g...@redhat.com wrote: On 05/13/2014 08:25 PM, Robbie Gemmell wrote: On 13 May 2014 17:59, Justin Ross jr...@apache.org wrote: On Tue, May 13, 2014 at 12:31 PM, Gordon Sim g...@redhat.com wrote: How about process_name and process_id then? I like those. I don't think brevity is important in this case, and those names are very clear to me. Works for me too. Ok, does anyone object to process_name and process_id? - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: AMQP 1.0 connection property names
On 14 May 2014 17:54, Gordon Sim g...@redhat.com wrote: On 05/14/2014 10:23 AM, Robbie Gemmell wrote: My interest is mostly around conveying the main component being doing the messaging (e.g. Qpid Messaging C++ Client, ActiveMQ Broker) rather than the application, but I can see that could be useful too in some cases. Yes, and I don't want to overcomplicate things. In some cases 'product' might be a little ambiguous is all. Making product be a map of name:version entries would certainly allow conveying more information, but could also make it harder to use the information for anything except blind display, as you would need a clearer idea in advance of what is going to be there to do much else with it given each 'aggregate product' could convey different things and may even end up giving different map key names to the same effective sub-component (e.g they might say proton-engine, or perhaps just proton). Agreed. That said, I imagine that kind of thing could be an issue anyway whether it was a map or just a simple value because it ultimately depends on if/how the information is populated in the first place. Related to that, would a separate version be needed, or could that be included in the product? The main case I can think of where you might want programmatic access to this is in choosing (hopefully temporary!) workarounds for different interop issues. The main reason I was looking to pick 'product' and 'version' was for the historical consistency (theyve been defined that way since at least 0-8), and then partly just based on how we currently use them in the Java broker by sending them to the client, and explicitly logging the clients product+version along with some other things for new connections. I have no real issue with combining their values.
[jira] [Created] (AMQ-5188) AMQ broker throws OutOfMemoryError even when global flow-control memoryUsage limit is imposed
Michael Samson created AMQ-5188: --- Summary: AMQ broker throws OutOfMemoryError even when global flow-control memoryUsage limit is imposed Key: AMQ-5188 URL: https://issues.apache.org/jira/browse/AMQ-5188 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: AMQ 5.8.0 broker running on 64-bit Linux AMQP Qpid (.26) JMS producers running on 64-bin Linux Reporter: Michael Samson Attachments: AMQ_heap1.png, AMQ_heap2.png, QpidProducerAMQOutOfMemory.java, activemq.xml, qpid-producer.tar * 5.8.0 broker was configured with persistence=false and a global memoryUsage limit=700 mb/ * 5.8.0 broker JVM memory was set to default of 1G * No active consumers * 10 Qpid (version .26) AMQP producers sent messages to 10 broker queues until flow control was reached * Over time the AMQP connections/producers were closed and recreated and they reattempted to send messages. As this cycle continues, eventually ActiveMQ threw OutOfMemoryErrors. I grabbed a heap dump and ActiveMQTextMessages consumed 874M of the heap. Taking a closer look, it appears that each org.apache.activemq.broker.region.Queue's messagesWaitingForSpace map grows unbounded and causes the OutOfMemory. I will attach a sample maven program that reproduces the problem along with my activemq configuration, heap screenshots, etc. Are their any workarounds to this issue? It is a potential use case for our customers if their queue consumers die for an extended period of time. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: AMQP 1.0 connection property names
On 14 May 2014 02:23, Robbie Gemmell robbie.gemm...@gmail.com wrote: Now that Gordons email has arrived for me, I'll reply to the rest of it :) On 13 May 2014 17:31, Gordon Sim g...@redhat.com wrote: On 05/13/2014 04:47 PM, Robbie Gemmell wrote: Sounds like a good idea to me. I have been meaning to do the same thing with some other properties like 'version' and 'product'. Yeah, my one question there was about distinguishing different 'layers'. E.g. proton engine version, v. qpid::messaging version, v. some application version. Maybe product should be a list or map? Or maybe the key should be the product name and the value the version? I don't have particularly strong feelings though I agree some standards here could be useful. My interest is mostly around conveying the main component being doing the messaging (e.g. Qpid Messaging C++ Client, ActiveMQ Broker) rather than the application, but I can see that could be useful too in some cases. Making product be a map of name:version entries would certainly allow conveying more information, but could also make it harder to use the information for anything except blind display, as you would need a clearer idea in advance of what is going to be there to do much else with it given each 'aggregate product' could convey different things and may even end up giving different map key names to the same effective sub-component (e.g they might say proton-engine, or perhaps just proton). So, I'd hope that any such information would be purely informational (for display) rather than any client/service embedding logic based on the client (library) in use. Where we need to indicate/detect behaviours relating to clients/brokers these should be defined in unambiguous behavioural connection properties. In terms of the purely informational process id, process name style attributes, I was initially going to suggest a map, but then really that is only just moving the issue down one level. I think process[-_ ]id and process[-_ ]name make sense as defined properties - have a well defined meaning in the context of the operating system on which the peer is running. For indicating the use of proton I'd suggest we define a qpid-proton-version property or some such (and then a qpid-messaging-version / qpid-jms-version / whatever) - i.e. each layer of library might add it's own connection properties to indicate its presence / version. That said, I imagine that kind of thing could be an issue anyway whether it was a map or just a simple value because it ultimately depends on if/how the information is populated in the first place. My only comment around the actual names is that 'process' doesnt immediately make me think 'name' and even seems a little like it could be describing the same thing as 'pid' if you didnt know both properties existed, which I have always thought about the older versions too. That isn't to say I necessarily have a good alternative suggestion, the only short one I could think of was 'pname' :) How about process_name and process_id then? As above - those work for me... If we're getting close to agreeing on these, we should probably cross post to the amqp comments list. -- Rob As per previous reply to Justin, those would be fine with me (as would pid and pname) Robbie
[jira] [Commented] (AMQCPP-543) message producer send never blocking when using producer flow control
[
https://issues.apache.org/jira/browse/AMQCPP-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999389#comment-13999389
]
Timothy Bish commented on AMQCPP-543:
-
You'd need to inspect the Java OpenWire client code to see how everything works
and then create tests that can validate your patch to ensure it works and there
are no breakages.
message producer send never blocking when using producer flow control
-
Key: AMQCPP-543
URL: https://issues.apache.org/jira/browse/AMQCPP-543
Project: ActiveMQ C++ Client
Issue Type: New Feature
Components: Openwire
Affects Versions: 3.8.2
Reporter: Christian Mamen
Assignee: Timothy Bish
Priority: Minor
For testing,
message producer is set to non-persisted mode, with the connection producer
window size to 1MB. (the broker enables the producer flow control and set the
memory limit to ~10MB with vm only storage)
I notice that when i don't have any message consumer, the broker notify me
that the memory limit is reached, that the producer will be throttled (as i
would expect), however the producer never blocks on a send, as if the window
size has no effect.
while digging into ActiveMQProducerKernel.cpp,
I notice the private member memoryUsage (auto_ptr) is never initialized. and
there's a TODO in the code ?
{code}
ActiveMQProducerKernel::ActiveMQProducerKernel(
[...]
// TODO - Check for need of MemoryUsage if there's a producer Windows size
//and the Protocol version is greater than 3.
}
{code}
I tried initializing the memoryUsage, and producer seem to block as expected
on a send, when the limit is reached.
{code}
ActiveMQProducerKernel::ActiveMQProducerKernel(
[...]
// TODO - Check for need of MemoryUsage if there's a producer Windows size
//and the Protocol version is greater than 3.
if (session-getConnection()-getProducerWindowSize()) {
this-memoryUsage.reset( new
MemoryUsage(session-getConnection()-getProducerWindowSize()) );
}
}
{code}
I'm not sure what is the proper fix,
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (AMQ-5161) NullPointerException during async startup
[
https://issues.apache.org/jira/browse/AMQ-5161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998577#comment-13998577
]
Nate M commented on AMQ-5161:
-
If I'm reading it correctly (for which there is a high probability that I'm
not), the current check to see if the broker has started in the
VMTransportFactory's lookupBroker method are bypassed during async startup,
because as Timothy mentioned, the broker is registered just as the broker
startup, and before initialization of key references, begins. Consequently, the
incoming VM transport will not wait for the specified period of time nor wait
until the broker is started to proceed with initiating the connection.
broker = registry.lookup(brokerName);
if (broker == null waitForStart 0) {
final long expiry = System.currentTimeMillis() + waitForStart;
while ((broker == null || !broker.isStarted()) expiry
System.currentTimeMillis()) {
It appears that perhaps 1) the broker registration in the registry should
somehow be postponed until the end of the async startup, 2) the required broker
references should be initialized before the async startup begins a version of
which is done in James' workaround, or 3) the broker.isStarted() check can
always be required in the lookupBroker method, not just when the broker can't
yet be found in the registry.
Incidentally, I saw a comment on an old ticket saying, Brokers agains start
synchronously by default, which is needed for vm transport embedded case
(https://issues.apache.org/jira/browse/AMQ-3696).
NullPointerException during async startup
-
Key: AMQ-5161
URL: https://issues.apache.org/jira/browse/AMQ-5161
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.1
Reporter: james
Attachments: QueueService2Test.java
I'm using an embedded broker with asynchronous startup enabled. My setup
worked using 5.9.0. When i upgraded to 5.9.1, i started getting this
exception on startup:
{noformat}
javax.jms.JMSException: java.lang.NullPointerException
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1408)
at
org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1513)
at
org.apache.activemq.ActiveMQConnection.setClientID(ActiveMQConnection.java:417)
at ...internal system startup stack trace...
Caused by: java.lang.NullPointerException
at
org.apache.activemq.broker.jmx.ManagedRegionBroker.addConnection(ManagedRegionBroker.java:232)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:91)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:97)
at
org.apache.activemq.broker.TransportConnection.processAddConnection(TransportConnection.java:759)
at org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:139)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:291)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:145)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
at
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
at
org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:247)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (AMQ-5186) AMQP producers aren't removed
Dejan Bosanac created AMQ-5186: -- Summary: AMQP producers aren't removed Key: AMQ-5186 URL: https://issues.apache.org/jira/browse/AMQ-5186 Project: ActiveMQ Issue Type: Bug Components: AMQP Affects Versions: 5.9.0 Reporter: Dejan Bosanac Assignee: Dejan Bosanac Fix For: 5.10.0 Consumers are only closed when the whole session is removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
AMQP 1.0 connection property names
Having discussed the issue with members of the Apache Qpid and Apache ActiveMQ communities, I would like to request the addition of two specific connection properties to the registry at http://www.amqp.org/specification/1.0/connection-properties: (1) process_name, which can be used to convey the name of the process associated with the connection and, (2) process_id, which can be used to convey the pid of that same process. These provide useful tools to those managing systems involving AMQP. The intention of course is not to mandate their use but to encourage anyone who does want to send this information to use the same mechanism for greater interoperability and improved experience to all. Thanks, --Gordon Sim.
[jira] [Comment Edited] (AMQ-5161) NullPointerException during async startup
[
https://issues.apache.org/jira/browse/AMQ-5161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998577#comment-13998577
]
Nate M edited comment on AMQ-5161 at 5/15/14 8:30 AM:
--
If I'm reading it correctly (for which there is a high probability that I'm
not), the current check to see if the broker has started in the
VMTransportFactory's lookupBroker method are bypassed during async startup,
because as Timothy mentioned, the broker is registered just as the broker
startup, and before initialization of key references, begins. Consequently, the
incoming VM transport will not wait for the specified period of time nor wait
until the broker is started to proceed with initiating the connection.
{code}
broker = registry.lookup(brokerName);
if (broker == null waitForStart 0) {
final long expiry = System.currentTimeMillis() + waitForStart;
while ((broker == null || !broker.isStarted()) expiry
System.currentTimeMillis()) {
{code}
It appears that perhaps 1) the broker registration in the registry should
somehow be postponed until the end of the async startup, 2) the required broker
references should be initialized before the async startup begins a version of
which is done in James' workaround, or 3) the broker.isStarted() check can
always be required in the lookupBroker method, not just when the broker can't
yet be found in the registry.
Incidentally, I saw a comment on an old ticket saying, Brokers agains start
synchronously by default, which is needed for vm transport embedded case
(https://issues.apache.org/jira/browse/AMQ-3696).
was (Author: ndmar):
If I'm reading it correctly (for which there is a high probability that I'm
not), the current check to see if the broker has started in the
VMTransportFactory's lookupBroker method are bypassed during async startup,
because as Timothy mentioned, the broker is registered just as the broker
startup, and before initialization of key references, begins. Consequently, the
incoming VM transport will not wait for the specified period of time nor wait
until the broker is started to proceed with initiating the connection.
{quote}
broker = registry.lookup(brokerName);
if (broker == null waitForStart 0) {
final long expiry = System.currentTimeMillis() + waitForStart;
while ((broker == null || !broker.isStarted()) expiry
System.currentTimeMillis()) {
{quote}
It appears that perhaps 1) the broker registration in the registry should
somehow be postponed until the end of the async startup, 2) the required broker
references should be initialized before the async startup begins a version of
which is done in James' workaround, or 3) the broker.isStarted() check can
always be required in the lookupBroker method, not just when the broker can't
yet be found in the registry.
Incidentally, I saw a comment on an old ticket saying, Brokers agains start
synchronously by default, which is needed for vm transport embedded case
(https://issues.apache.org/jira/browse/AMQ-3696).
NullPointerException during async startup
-
Key: AMQ-5161
URL: https://issues.apache.org/jira/browse/AMQ-5161
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.1
Reporter: james
Attachments: QueueService2Test.java
I'm using an embedded broker with asynchronous startup enabled. My setup
worked using 5.9.0. When i upgraded to 5.9.1, i started getting this
exception on startup:
{noformat}
javax.jms.JMSException: java.lang.NullPointerException
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1408)
at
org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1513)
at
org.apache.activemq.ActiveMQConnection.setClientID(ActiveMQConnection.java:417)
at ...internal system startup stack trace...
Caused by: java.lang.NullPointerException
at
org.apache.activemq.broker.jmx.ManagedRegionBroker.addConnection(ManagedRegionBroker.java:232)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:91)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:97)
at
Re: AMQP 1.0 connection property names
On 14 May 2014 21:48, Rob Godfrey rob.j.godf...@gmail.com wrote: On 14 May 2014 02:23, Robbie Gemmell robbie.gemm...@gmail.com wrote: Now that Gordons email has arrived for me, I'll reply to the rest of it :) On 13 May 2014 17:31, Gordon Sim g...@redhat.com wrote: On 05/13/2014 04:47 PM, Robbie Gemmell wrote: Sounds like a good idea to me. I have been meaning to do the same thing with some other properties like 'version' and 'product'. Yeah, my one question there was about distinguishing different 'layers'. E.g. proton engine version, v. qpid::messaging version, v. some application version. Maybe product should be a list or map? Or maybe the key should be the product name and the value the version? I don't have particularly strong feelings though I agree some standards here could be useful. My interest is mostly around conveying the main component being doing the messaging (e.g. Qpid Messaging C++ Client, ActiveMQ Broker) rather than the application, but I can see that could be useful too in some cases. Making product be a map of name:version entries would certainly allow conveying more information, but could also make it harder to use the information for anything except blind display, as you would need a clearer idea in advance of what is going to be there to do much else with it given each 'aggregate product' could convey different things and may even end up giving different map key names to the same effective sub-component (e.g they might say proton-engine, or perhaps just proton). So, I'd hope that any such information would be purely informational (for display) rather than any client/service embedding logic based on the client (library) in use. Where we need to indicate/detect behaviours relating to clients/brokers these should be defined in unambiguous behavioural connection properties. Agreed. The main thing I'd like is that you can pick out certain general bits of info you might want to display on their own, like an overall product name and version, without having to display all the other properties because you couldn't easily separate them from the items of interest. In terms of the purely informational process id, process name style attributes, I was initially going to suggest a map, but then really that is only just moving the issue down one level. I think process[-_ ]id and process[-_ ]name make sense as defined properties - have a well defined meaning in the context of the operating system on which the peer is running. For indicating the use of proton I'd suggest we define a qpid-proton-version property or some such (and then a qpid-messaging-version / qpid-jms-version / whatever) - i.e. each layer of library might add it's own connection properties to indicate its presence / version. That said, I imagine that kind of thing could be an issue anyway whether it was a map or just a simple value because it ultimately depends on if/how the information is populated in the first place. My only comment around the actual names is that 'process' doesnt immediately make me think 'name' and even seems a little like it could be describing the same thing as 'pid' if you didnt know both properties existed, which I have always thought about the older versions too. That isn't to say I necessarily have a good alternative suggestion, the only short one I could think of was 'pname' :) How about process_name and process_id then? As above - those work for me... If we're getting close to agreeing on these, we should probably cross post to the amqp comments list. -- Rob As per previous reply to Justin, those would be fine with me (as would pid and pname) Robbie
[jira] [Comment Edited] (AMQ-5161) NullPointerException during async startup
[
https://issues.apache.org/jira/browse/AMQ-5161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998577#comment-13998577
]
Nate M edited comment on AMQ-5161 at 5/15/14 8:29 AM:
--
If I'm reading it correctly (for which there is a high probability that I'm
not), the current check to see if the broker has started in the
VMTransportFactory's lookupBroker method are bypassed during async startup,
because as Timothy mentioned, the broker is registered just as the broker
startup, and before initialization of key references, begins. Consequently, the
incoming VM transport will not wait for the specified period of time nor wait
until the broker is started to proceed with initiating the connection.
{quote}
broker = registry.lookup(brokerName);
if (broker == null waitForStart 0) {
final long expiry = System.currentTimeMillis() + waitForStart;
while ((broker == null || !broker.isStarted()) expiry
System.currentTimeMillis()) {
{quote}
It appears that perhaps 1) the broker registration in the registry should
somehow be postponed until the end of the async startup, 2) the required broker
references should be initialized before the async startup begins a version of
which is done in James' workaround, or 3) the broker.isStarted() check can
always be required in the lookupBroker method, not just when the broker can't
yet be found in the registry.
Incidentally, I saw a comment on an old ticket saying, Brokers agains start
synchronously by default, which is needed for vm transport embedded case
(https://issues.apache.org/jira/browse/AMQ-3696).
was (Author: ndmar):
If I'm reading it correctly (for which there is a high probability that I'm
not), the current check to see if the broker has started in the
VMTransportFactory's lookupBroker method are bypassed during async startup,
because as Timothy mentioned, the broker is registered just as the broker
startup, and before initialization of key references, begins. Consequently, the
incoming VM transport will not wait for the specified period of time nor wait
until the broker is started to proceed with initiating the connection.
broker = registry.lookup(brokerName);
if (broker == null waitForStart 0) {
final long expiry = System.currentTimeMillis() + waitForStart;
while ((broker == null || !broker.isStarted()) expiry
System.currentTimeMillis()) {
It appears that perhaps 1) the broker registration in the registry should
somehow be postponed until the end of the async startup, 2) the required broker
references should be initialized before the async startup begins a version of
which is done in James' workaround, or 3) the broker.isStarted() check can
always be required in the lookupBroker method, not just when the broker can't
yet be found in the registry.
Incidentally, I saw a comment on an old ticket saying, Brokers agains start
synchronously by default, which is needed for vm transport embedded case
(https://issues.apache.org/jira/browse/AMQ-3696).
NullPointerException during async startup
-
Key: AMQ-5161
URL: https://issues.apache.org/jira/browse/AMQ-5161
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.1
Reporter: james
Attachments: QueueService2Test.java
I'm using an embedded broker with asynchronous startup enabled. My setup
worked using 5.9.0. When i upgraded to 5.9.1, i started getting this
exception on startup:
{noformat}
javax.jms.JMSException: java.lang.NullPointerException
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1408)
at
org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1513)
at
org.apache.activemq.ActiveMQConnection.setClientID(ActiveMQConnection.java:417)
at ...internal system startup stack trace...
Caused by: java.lang.NullPointerException
at
org.apache.activemq.broker.jmx.ManagedRegionBroker.addConnection(ManagedRegionBroker.java:232)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:91)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:97)
at
[jira] [Updated] (AMQ-5188) AMQ broker throws OutOfMemoryError even when global flow-control memoryUsage limit is imposed
[ https://issues.apache.org/jira/browse/AMQ-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Samson updated AMQ-5188: Description: * 5.8.0 broker was configured with persistence=false and a global memoryUsage limit=700 mb/ * 5.8.0 broker JVM memory was set to default of 1G * No active consumers * 10 Qpid (version .26) AMQP producers sent messages to 10 broker queues until flow control was reached * Over time the AMQP connections/producers were closed and recreated and they reattempted to send messages. As this cycle continues, eventually ActiveMQ threw OutOfMemoryErrors. I grabbed a heap dump and ActiveMQTextMessages consumed 874M of the heap. Taking a closer look, it appears that each org.apache.activemq.broker.region.Queue's messagesWaitingForSpace map grows unbounded and causes the OutOfMemory. I will attach a sample maven program that reproduces the problem along with my activemq configuration, heap screenshots, etc. Are their any workarounds to this issue? It is a use case for our customers if their queue consumers die for an extended period of time. was: * 5.8.0 broker was configured with persistence=false and a global memoryUsage limit=700 mb/ * 5.8.0 broker JVM memory was set to default of 1G * No active consumers * 10 Qpid (version .26) AMQP producers sent messages to 10 broker queues until flow control was reached * Over time the AMQP connections/producers were closed and recreated and they reattempted to send messages. As this cycle continues, eventually ActiveMQ threw OutOfMemoryErrors. I grabbed a heap dump and ActiveMQTextMessages consumed 874M of the heap. Taking a closer look, it appears that each org.apache.activemq.broker.region.Queue's messagesWaitingForSpace map grows unbounded and causes the OutOfMemory. I will attach a sample maven program that reproduces the problem along with my activemq configuration, heap screenshots, etc. Are their any workarounds to this issue? It is a potential use case for our customers if their queue consumers die for an extended period of time. AMQ broker throws OutOfMemoryError even when global flow-control memoryUsage limit is imposed - Key: AMQ-5188 URL: https://issues.apache.org/jira/browse/AMQ-5188 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: AMQ 5.8.0 broker running on 64-bit Linux AMQP Qpid (.26) JMS producers running on 64-bin Linux Reporter: Michael Samson Attachments: AMQ_heap1.png, AMQ_heap2.png, QpidProducerAMQOutOfMemory.java, activemq.xml, qpid-producer.tar * 5.8.0 broker was configured with persistence=false and a global memoryUsage limit=700 mb/ * 5.8.0 broker JVM memory was set to default of 1G * No active consumers * 10 Qpid (version .26) AMQP producers sent messages to 10 broker queues until flow control was reached * Over time the AMQP connections/producers were closed and recreated and they reattempted to send messages. As this cycle continues, eventually ActiveMQ threw OutOfMemoryErrors. I grabbed a heap dump and ActiveMQTextMessages consumed 874M of the heap. Taking a closer look, it appears that each org.apache.activemq.broker.region.Queue's messagesWaitingForSpace map grows unbounded and causes the OutOfMemory. I will attach a sample maven program that reproduces the problem along with my activemq configuration, heap screenshots, etc. Are their any workarounds to this issue? It is a use case for our customers if their queue consumers die for an extended period of time. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: AMQP 1.0 connection property names
Now that Gordons email has arrived for me, I'll reply to the rest of it :) On 13 May 2014 17:31, Gordon Sim g...@redhat.com wrote: On 05/13/2014 04:47 PM, Robbie Gemmell wrote: Sounds like a good idea to me. I have been meaning to do the same thing with some other properties like 'version' and 'product'. Yeah, my one question there was about distinguishing different 'layers'. E.g. proton engine version, v. qpid::messaging version, v. some application version. Maybe product should be a list or map? Or maybe the key should be the product name and the value the version? I don't have particularly strong feelings though I agree some standards here could be useful. My interest is mostly around conveying the main component being doing the messaging (e.g. Qpid Messaging C++ Client, ActiveMQ Broker) rather than the application, but I can see that could be useful too in some cases. Making product be a map of name:version entries would certainly allow conveying more information, but could also make it harder to use the information for anything except blind display, as you would need a clearer idea in advance of what is going to be there to do much else with it given each 'aggregate product' could convey different things and may even end up giving different map key names to the same effective sub-component (e.g they might say proton-engine, or perhaps just proton). That said, I imagine that kind of thing could be an issue anyway whether it was a map or just a simple value because it ultimately depends on if/how the information is populated in the first place. My only comment around the actual names is that 'process' doesnt immediately make me think 'name' and even seems a little like it could be describing the same thing as 'pid' if you didnt know both properties existed, which I have always thought about the older versions too. That isn't to say I necessarily have a good alternative suggestion, the only short one I could think of was 'pname' :) How about process_name and process_id then? As per previous reply to Justin, those would be fine with me (as would pid and pname) Robbie
[jira] [Commented] (AMQ-5160) Wildcard subscriptions bypass Authentication / Authorization
[ https://issues.apache.org/jira/browse/AMQ-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000356#comment-14000356 ] Dhiraj Bokde commented on AMQ-5160: --- Hi [~surfnerd], I've added more commits to PR-22 to fix durable subscriptions. The retained message test is also more elaborate. Hopefully this will be last change. Please let us know whether PR-22 works in your tests so it can be merged into Apache trunk. Thanks, Dhiraj. Wildcard subscriptions bypass Authentication / Authorization Key: AMQ-5160 URL: https://issues.apache.org/jira/browse/AMQ-5160 Project: ActiveMQ Issue Type: Bug Components: MQTT Affects Versions: 5.9.1 Reporter: Surf Priority: Critical Labels: authentication, authorization, mqtt, security Fix For: 5.10.0 Attachments: activemq.xml, groups.properties, login.config, patch.txt, users.properties I am using MQTT on AMQ 5.9.1 After latest MQTT hardening from [~dhirajsb] , there is an issue of MQTT retained messages. Simple case: Set Authentication / Authorization for two different TOPICS. Send retained message to one topic. Try to subscribe # with other second user. It will show retained messages published by TOPIC 1. here i have attached test configurations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-5188) AMQ broker throws OutOfMemoryError even when global flow-control memoryUsage limit is imposed
[ https://issues.apache.org/jira/browse/AMQ-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Samson updated AMQ-5188: Description: * 5.8.0 broker was configured with persistence=false and a global memoryUsage limit=700 mb/ * 5.8.0 broker JVM memory was set to default of 1G * No active consumers * 10 Qpid (version .26) AMQP producers sent messages to 10 broker queues until flow control was reached * Over time the AMQP connections/producers were closed and recreated and they reattempted to send messages. As this cycle continues, eventually ActiveMQ threw OutOfMemoryErrors. I grabbed a heap dump and ActiveMQTextMessages consumed 874M of the heap. Taking a closer look, it appears that each org.apache.activemq.broker.region.Queue's messagesWaitingForSpace map grows unbounded and causes the OutOfMemory. I will attach a sample maven program that reproduces the problem along with my activemq configuration, heap screenshots, etc. Are their any workarounds to this issue? It is a potential use case for our customers if their queue consumers die for an extended period of time. was: * 5.8.0 broker was configured with persistence=false and a global memoryUsage limit=700 mb/ * 5.8.0 broker JVM memory was set to default of 1G * No active consumers * 10 Qpid (version .26) AMQP producers sent messages to 10 broker queues until flow control was reached * Over time the AMQP connections/producers were closed and recreated and they reattempted to send messages. As this cycle continues, eventually ActiveMQ threw OutOfMemoryErrors. I grabbed a heap dump and ActiveMQTextMessages consumed 874M of the heap. Taking a closer look, it appears that each org.apache.activemq.broker.region.Queue's messagesWaitingForSpace map grows unbounded and causes the OutOfMemory. I will attach a sample maven program that reproduces the problem along with my activemq configuration, heap screenshots, etc. Are their any workarounds to this issue? It is a potential use case for our customers if their queue consumers die for an extended period of time. AMQ broker throws OutOfMemoryError even when global flow-control memoryUsage limit is imposed - Key: AMQ-5188 URL: https://issues.apache.org/jira/browse/AMQ-5188 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: AMQ 5.8.0 broker running on 64-bit Linux AMQP Qpid (.26) JMS producers running on 64-bin Linux Reporter: Michael Samson Attachments: AMQ_heap1.png, AMQ_heap2.png, QpidProducerAMQOutOfMemory.java, activemq.xml, qpid-producer.tar * 5.8.0 broker was configured with persistence=false and a global memoryUsage limit=700 mb/ * 5.8.0 broker JVM memory was set to default of 1G * No active consumers * 10 Qpid (version .26) AMQP producers sent messages to 10 broker queues until flow control was reached * Over time the AMQP connections/producers were closed and recreated and they reattempted to send messages. As this cycle continues, eventually ActiveMQ threw OutOfMemoryErrors. I grabbed a heap dump and ActiveMQTextMessages consumed 874M of the heap. Taking a closer look, it appears that each org.apache.activemq.broker.region.Queue's messagesWaitingForSpace map grows unbounded and causes the OutOfMemory. I will attach a sample maven program that reproduces the problem along with my activemq configuration, heap screenshots, etc. Are their any workarounds to this issue? It is a potential use case for our customers if their queue consumers die for an extended period of time. -- This message was sent by Atlassian JIRA (v6.2#6252)
