[jira] [Updated] (AMQ-5865) Enable "getRemoteAddress()" method in WebSocket Requests
[
https://issues.apache.org/jira/browse/AMQ-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Kemper updated AMQ-5865:
--
see also
http://activemq.2283324.n4.nabble.com/Enable-quot-getRemoteAddress-quot-method-in-WebSocket-Requests-tt4698179.html
> Enable "getRemoteAddress()" method in WebSocket Requests
>
>
> Key: AMQ-5865
> URL: https://issues.apache.org/jira/browse/AMQ-5865
> Project: ActiveMQ
> Issue Type: Bug
> Components: MQTT, stomp
>Affects Versions: 5.11.0, 5.11.1
> Environment: all
>Reporter: Christian Kemper
>Priority: Trivial
> Labels: easyfix, easytest, features, javascript, patch
> Fix For: 5.11.2, 5.12.0, 6.0.0
>
> Attachments: CustomStompSocket.java, CustomWebSocketServlet.java
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The method (getRemoteAddress()) in class
> "org.apache.activemq.transport.ws.AbstractStompSocket" does not return the
> correct address; it returns always ""StompSocket_" + hashCode();"
> We need the correct address (e.g. "wss://127.0.0.1:63114") for our use case.
> The implementation whould be very simple.
> In class "org.apache.activemq.transport.ws.jetty8.WSServlet" (and also in
> jetty9 package) pass the address during creation of class StompSocket in the
> same package:
> String scheme = request.getScheme();
> if ("http".equalsIgnoreCase(scheme)) {
> scheme = "ws";
> } else if ("https".equalsIgnoreCase(scheme)) {
> scheme = "wss";
> }
> WebSocket socket = new CustomStompSocket(scheme + "://" +
> request.getRemoteAddr() + ":" + request.getRemotePort());
> It meight be that MQTT is also affected; a fix should be done by the same way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5865) Enable "getRemoteAddress()" method in WebSocket Requests
[
https://issues.apache.org/jira/browse/AMQ-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14602418#comment-14602418
]
Christian Kemper commented on AMQ-5865:
---
Attached sample files for my fix (STOMP over wss).
Should be easy to change the real implementation with this samples ;-)
> Enable "getRemoteAddress()" method in WebSocket Requests
>
>
> Key: AMQ-5865
> URL: https://issues.apache.org/jira/browse/AMQ-5865
> Project: ActiveMQ
> Issue Type: Bug
> Components: MQTT, stomp
>Affects Versions: 5.11.0, 5.11.1
> Environment: all
>Reporter: Christian Kemper
>Priority: Trivial
> Labels: easyfix, easytest, features, javascript, patch
> Fix For: 5.11.2, 5.12.0, 6.0.0
>
> Attachments: CustomStompSocket.java, CustomWebSocketServlet.java
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The method (getRemoteAddress()) in class
> "org.apache.activemq.transport.ws.AbstractStompSocket" does not return the
> correct address; it returns always ""StompSocket_" + hashCode();"
> We need the correct address (e.g. "wss://127.0.0.1:63114") for our use case.
> The implementation whould be very simple.
> In class "org.apache.activemq.transport.ws.jetty8.WSServlet" (and also in
> jetty9 package) pass the address during creation of class StompSocket in the
> same package:
> String scheme = request.getScheme();
> if ("http".equalsIgnoreCase(scheme)) {
> scheme = "ws";
> } else if ("https".equalsIgnoreCase(scheme)) {
> scheme = "wss";
> }
> WebSocket socket = new CustomStompSocket(scheme + "://" +
> request.getRemoteAddr() + ":" + request.getRemotePort());
> It meight be that MQTT is also affected; a fix should be done by the same way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5865) Enable "getRemoteAddress()" method in WebSocket Requests
[
https://issues.apache.org/jira/browse/AMQ-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Kemper updated AMQ-5865:
--
Attachment: CustomStompSocket.java
> Enable "getRemoteAddress()" method in WebSocket Requests
>
>
> Key: AMQ-5865
> URL: https://issues.apache.org/jira/browse/AMQ-5865
> Project: ActiveMQ
> Issue Type: Bug
> Components: MQTT, stomp
>Affects Versions: 5.11.0, 5.11.1
> Environment: all
>Reporter: Christian Kemper
>Priority: Trivial
> Labels: easyfix, easytest, features, javascript, patch
> Fix For: 5.11.2, 5.12.0, 6.0.0
>
> Attachments: CustomStompSocket.java, CustomWebSocketServlet.java
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The method (getRemoteAddress()) in class
> "org.apache.activemq.transport.ws.AbstractStompSocket" does not return the
> correct address; it returns always ""StompSocket_" + hashCode();"
> We need the correct address (e.g. "wss://127.0.0.1:63114") for our use case.
> The implementation whould be very simple.
> In class "org.apache.activemq.transport.ws.jetty8.WSServlet" (and also in
> jetty9 package) pass the address during creation of class StompSocket in the
> same package:
> String scheme = request.getScheme();
> if ("http".equalsIgnoreCase(scheme)) {
> scheme = "ws";
> } else if ("https".equalsIgnoreCase(scheme)) {
> scheme = "wss";
> }
> WebSocket socket = new CustomStompSocket(scheme + "://" +
> request.getRemoteAddr() + ":" + request.getRemotePort());
> It meight be that MQTT is also affected; a fix should be done by the same way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5865) Enable "getRemoteAddress()" method in WebSocket Requests
[
https://issues.apache.org/jira/browse/AMQ-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Kemper updated AMQ-5865:
--
Attachment: CustomWebSocketServlet.java
> Enable "getRemoteAddress()" method in WebSocket Requests
>
>
> Key: AMQ-5865
> URL: https://issues.apache.org/jira/browse/AMQ-5865
> Project: ActiveMQ
> Issue Type: Bug
> Components: MQTT, stomp
>Affects Versions: 5.11.0, 5.11.1
> Environment: all
>Reporter: Christian Kemper
>Priority: Trivial
> Labels: easyfix, easytest, features, javascript, patch
> Fix For: 5.11.2, 5.12.0, 6.0.0
>
> Attachments: CustomStompSocket.java, CustomWebSocketServlet.java
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The method (getRemoteAddress()) in class
> "org.apache.activemq.transport.ws.AbstractStompSocket" does not return the
> correct address; it returns always ""StompSocket_" + hashCode();"
> We need the correct address (e.g. "wss://127.0.0.1:63114") for our use case.
> The implementation whould be very simple.
> In class "org.apache.activemq.transport.ws.jetty8.WSServlet" (and also in
> jetty9 package) pass the address during creation of class StompSocket in the
> same package:
> String scheme = request.getScheme();
> if ("http".equalsIgnoreCase(scheme)) {
> scheme = "ws";
> } else if ("https".equalsIgnoreCase(scheme)) {
> scheme = "wss";
> }
> WebSocket socket = new CustomStompSocket(scheme + "://" +
> request.getRemoteAddr() + ":" + request.getRemotePort());
> It meight be that MQTT is also affected; a fix should be done by the same way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-5865) Enable "getRemoteAddress()" method in WebSocket Requests
Christian Kemper created AMQ-5865:
-
Summary: Enable "getRemoteAddress()" method in WebSocket Requests
Key: AMQ-5865
URL: https://issues.apache.org/jira/browse/AMQ-5865
Project: ActiveMQ
Issue Type: Bug
Components: MQTT, stomp
Affects Versions: 5.11.1, 5.11.0
Environment: all
Reporter: Christian Kemper
Priority: Trivial
Fix For: 5.11.2, 5.12.0, 6.0.0
The method (getRemoteAddress()) in class
"org.apache.activemq.transport.ws.AbstractStompSocket" does not return the
correct address; it returns always ""StompSocket_" + hashCode();"
We need the correct address (e.g. "wss://127.0.0.1:63114") for our use case.
The implementation whould be very simple.
In class "org.apache.activemq.transport.ws.jetty8.WSServlet" (and also in
jetty9 package) pass the address during creation of class StompSocket in the
same package:
String scheme = request.getScheme();
if ("http".equalsIgnoreCase(scheme)) {
scheme = "ws";
} else if ("https".equalsIgnoreCase(scheme)) {
scheme = "wss";
}
WebSocket socket = new CustomStompSocket(scheme + "://" +
request.getRemoteAddr() + ":" + request.getRemotePort());
It meight be that MQTT is also affected; a fix should be done by the same way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-46) AMQP interop: Active broker does not respect the "drain" flag.
[
https://issues.apache.org/jira/browse/ARTEMIS-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601978#comment-14601978
]
Justin Bertram commented on ARTEMIS-46:
---
Any idea on how to reproduce this with Proton? Ideally I'd like to have a test
that reproduces this in Artemis itself (i.e. in Java).
> AMQP interop: Active broker does not respect the "drain" flag.
> --
>
> Key: ARTEMIS-46
> URL: https://issues.apache.org/jira/browse/ARTEMIS-46
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Alan Conway
> Fix For: 1.0.1
>
>
> The drain flag on the AMQP flow performative allows a client to request
> confirmation that it has received the last available message that it has
> credit to receive.
> To reproduce using the qpid-send, qpid-receive clients from
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/. Create a JMS queue 'foo' on
> the active broker then run:
> $ qpid-send -a jms.queue.foo -b localhost:5455 --content-string XXX
> --connection-options='{protocol:amqp1.0}'
> $ qpid-receive -a jms.queue.foo -b localhost:5455
> --connection-options='{protocol:amqp1.0}' --log-enable trace+:Protocol
> qpid-receive hangs, the last line of output is:
> 2014-11-24 15:15:46 [Protocol] trace [58e8ee08-0f33-426b-b77a-450f7c3d976c]:
> 0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=1,
> link-credit=1, drain=true]
> This shows that qpid-receive sent a flow with drain=true but never received a
> response.
> Why is this important? Without the drain flag it is impossible for a client
> to implement the simple behavior "get the next message" correctly. The flow
> response tells the client immediately "there are no more messages available
> for you". Without it the client can only use a timeout which is unreliable
> (if too short the client may give up while the message is in flight) and
> inefficient (if too long the client will wait needlessly for messages that
> the broker knows are not presently available)
> The spec 2.6.7 is a little ambiguous about whether this is a SHOULD or a MUST
> behavior but without it it is impossible to implement the use cases described
> in the following section.
> AMQP 1.0 specification 2.7.6
> drain
> The drain flag indicates how the sender SHOULD behave when insufficient
> messages are available to consume the current link-credit. If set, the sender
> will (after sending all available messages) advance the delivery-count as
> much as possible, consuming all link-credit, and send the flow state to the
> receiver. Only the receiver can independently modify this field. The sender's
> value is always the last known value indicated by the receiver.
> If the link-credit is less than or equal to zero, i.e., the delivery-count is
> the same as or greater than the delivery-limit, a sender MUST NOT send more
> messages. If the link-credit is reduced by the receiver when transfers are
> in-flight, the receiver MAY either handle the excess messages normally or
> detach the link with a transfer-limit-exceeded error code.
> Figure 2.40: Flow Control
> +--++--+
> | Sender |---transfer>| Receiver |
> +--++--+
> \/ +--++--+
> |
> |
> |
> if link-credit <= 0 then pause
>
> If the sender's drain flag is set and there are no available messages, the
> sender MUST advance its delivery-count until link-credit is zero, and send
> its updated flow state to the receiver.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-144) Importing Consumer/Producer/Browser from ActiveMQ
[ https://issues.apache.org/jira/browse/ARTEMIS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601747#comment-14601747 ] ASF GitHub Bot commented on ARTEMIS-144: Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/50 > Importing Consumer/Producer/Browser from ActiveMQ > - > > Key: ARTEMIS-144 > URL: https://issues.apache.org/jira/browse/ARTEMIS-144 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.0.1 > > > As I was working through the examples, I realized that ActiveMQ has a tool on > its console for sending / receiving and validating installations. What users > are well used to. > This will import that tool to the CLI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5851) Unmatched acknowledge: MessageAck {commandId = 77, responseRequired = false, ackType = 2, ...Could not find Message-ID XXX in dispatched-list (start of ack)
[
https://issues.apache.org/jira/browse/AMQ-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601708#comment-14601708
]
Christopher L. Shannon commented on AMQ-5851:
-
I created a pull request to address this issue and to update the expired ack to
only expire the messages in dispatched relating to the ack, and not all expired
messages. I added a unit test that simulates the issue with how it would be
run in an application container. The test passes with my patch but fails
without it. Take a look and let me know what you think.
> Unmatched acknowledge: MessageAck {commandId = 77, responseRequired = false,
> ackType = 2, ...Could not find Message-ID XXX in dispatched-list (start of
> ack)
>
>
> Key: AMQ-5851
> URL: https://issues.apache.org/jira/browse/AMQ-5851
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
>Affects Versions: 5.10.0, 5.11.0, 5.11.1
>Reporter: Grijesh Saini
> Labels: ttl
> Attachments: AcknowledgeIssue.zip
>
>
> When lot of messages got expired because of JMS client Time to Live (TTL)
> property then below error will appear and consumer will freeze
> {code:xml}
> Connection to broker failed: Unmatched acknowledge: MessageAck {commandId =
> 77, responseRequired = false, ackType = 2, consumerId =XXX firstMessageId =
> ID:XXX
> lastMessageId = ID:XXX
> , destination = queue://abc, transactionId = null, messageCount = 1,
> poisonCause = null}; Could not find Message-ID in dispatched-list (start of
> ack)
> at
> org.apache.activemq.broker.region.PrefetchSubscription.assertAckMatchesDispatched(PrefetchSubscription.java:477)
> [activemq-broker-5.11.1.jar:5.11.1
> at
> org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:212)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:441)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:484)
> [activemq-broker-5.11.1.jar:5.11.1]
> at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:87)
> [activemq-broker-5.11.1.jar:5.11.1]
> at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:87)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:277)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:97)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:550)
> [activemq-broker-5.11.1.jar:5.11.1]
> at org.apache.activemq.command.MessageAck.visit(MessageAck.java:245)
> [activemq-client-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:334)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:188)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> [activemq-client-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
> [activemq-client-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)
> [activemq-client-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
> [activemq-client-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)
> [activemq-client-5.11.1.jar:5.11.1]
> at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
> [activemq-client-5.11.1.jar:5.11.1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
> {code}
> Steps to reproduce :
> 1. Enable TTL property for JMS client
> 2. Keep TTL value very low say 5 sec
> 3. Send lot of messages so some message will get expired
> 4. Make sure that some message should expired when they are in MDB means
> running inside MDB
> Then we will see above error in the logs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5851) Unmatched acknowledge: MessageAck {commandId = 77, responseRequired = false, ackType = 2, ...Could not find Message-ID XXX in dispatched-list (start of ack)
[
https://issues.apache.org/jira/browse/AMQ-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601700#comment-14601700
]
ASF GitHub Bot commented on AMQ-5851:
-
GitHub user cshannon opened a pull request:
https://github.com/apache/activemq/pull/123
https://issues.apache.org/jira/browse/AMQ-5851
This commit resolves an issue where unmatched acknowledgement
messages could be received when running a MDB consumer and
sending messages with a short TTL. The expiration logic when
receiveing an expired Message Ack will now only expire messages
in dispatch relating to the received ack, not all expired messages
in the dispatch list.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/cshannon/activemq AMQ-5851
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq/pull/123.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #123
commit 1bce29ac6f55394fa9ebf2ee347dcde415bac7e0
Author: Christopher L. Shannon (cshannon)
Date: 2015-06-25T18:22:32Z
https://issues.apache.org/jira/browse/AMQ-5851
This commit resolves an issue where unmatched acknowledgement
messages could be received when running a MDB consumer and
sending messages with a short TTL. The expiration logic when
receiveing an expired Message Ack will now only expire messages
in dispatch relating to the received ack, not all expired messages
in the dispatch list.
> Unmatched acknowledge: MessageAck {commandId = 77, responseRequired = false,
> ackType = 2, ...Could not find Message-ID XXX in dispatched-list (start of
> ack)
>
>
> Key: AMQ-5851
> URL: https://issues.apache.org/jira/browse/AMQ-5851
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
>Affects Versions: 5.10.0, 5.11.0, 5.11.1
>Reporter: Grijesh Saini
> Labels: ttl
> Attachments: AcknowledgeIssue.zip
>
>
> When lot of messages got expired because of JMS client Time to Live (TTL)
> property then below error will appear and consumer will freeze
> {code:xml}
> Connection to broker failed: Unmatched acknowledge: MessageAck {commandId =
> 77, responseRequired = false, ackType = 2, consumerId =XXX firstMessageId =
> ID:XXX
> lastMessageId = ID:XXX
> , destination = queue://abc, transactionId = null, messageCount = 1,
> poisonCause = null}; Could not find Message-ID in dispatched-list (start of
> ack)
> at
> org.apache.activemq.broker.region.PrefetchSubscription.assertAckMatchesDispatched(PrefetchSubscription.java:477)
> [activemq-broker-5.11.1.jar:5.11.1
> at
> org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:212)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:441)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:484)
> [activemq-broker-5.11.1.jar:5.11.1]
> at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:87)
> [activemq-broker-5.11.1.jar:5.11.1]
> at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:87)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:277)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:97)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:550)
> [activemq-broker-5.11.1.jar:5.11.1]
> at org.apache.activemq.command.MessageAck.visit(MessageAck.java:245)
> [activemq-client-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:334)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:188)
> [activemq-broker-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> [activemq-client-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
> [activemq-client-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)
> [activemq-client-5.11.1.jar:5.11.1]
> at
> org.apache.activemq.transport.TransportSupport.doConsume(Transport
[jira] [Closed] (ARTEMIS-144) Importing Consumer/Producer/Browser from ActiveMQ
[ https://issues.apache.org/jira/browse/ARTEMIS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-144. --- Resolution: Fixed > Importing Consumer/Producer/Browser from ActiveMQ > - > > Key: ARTEMIS-144 > URL: https://issues.apache.org/jira/browse/ARTEMIS-144 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.0.1 > > > As I was working through the examples, I realized that ActiveMQ has a tool on > its console for sending / receiving and validating installations. What users > are well used to. > This will import that tool to the CLI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-144) Importing Consumer/Producer/Browser from ActiveMQ
[ https://issues.apache.org/jira/browse/ARTEMIS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601505#comment-14601505 ] ASF GitHub Bot commented on ARTEMIS-144: GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/50 [ARTEMIS-144] adding Browse and a few other improvements You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/50.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #50 commit b5601bfd931fafd408f123e8e779ef4c72fe132c Author: Clebert Suconic Date: 2015-06-25T14:22:58Z [ARTEMIS-144] adding Browse and a few other improvements > Importing Consumer/Producer/Browser from ActiveMQ > - > > Key: ARTEMIS-144 > URL: https://issues.apache.org/jira/browse/ARTEMIS-144 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.0.1 > > > As I was working through the examples, I realized that ActiveMQ has a tool on > its console for sending / receiving and validating installations. What users > are well used to. > This will import that tool to the CLI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-70) Implement resource limits
[ https://issues.apache.org/jira/browse/ARTEMIS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601344#comment-14601344 ] clebert suconic commented on ARTEMIS-70: If it's partially done the best would be to create a JIRA at the release where it was done. At least it shows at the proper release notes.. it can be linked to this one for reference. > Implement resource limits > - > > Key: ARTEMIS-70 > URL: https://issues.apache.org/jira/browse/ARTEMIS-70 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Michael Cressman >Assignee: Justin Bertram > Fix For: 1.1.0 > > > Implement various resource limits within the system: > - overall number of connections > - connections per user > - connections per IP address > - queues per user > - (possibly: number of sessions, number of subscriptions per user) > The "per user" limits can be a default maximum for everyone plus specific > limits for particular users. > Other things: > - limit the max queue size a user can create > - limit the names a user may call a queue that he creates -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-70) Implement resource limits
[ https://issues.apache.org/jira/browse/ARTEMIS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601340#comment-14601340 ] Justin Bertram commented on ARTEMIS-70: --- I implemented: * overall number of connections * connections per user * queues per user I have not implemented: * connections per IP address * max queue size a user can create * names a user may call a queue that he creates > Implement resource limits > - > > Key: ARTEMIS-70 > URL: https://issues.apache.org/jira/browse/ARTEMIS-70 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Michael Cressman >Assignee: Justin Bertram > Fix For: 1.1.0 > > > Implement various resource limits within the system: > - overall number of connections > - connections per user > - connections per IP address > - queues per user > - (possibly: number of sessions, number of subscriptions per user) > The "per user" limits can be a default maximum for everyone plus specific > limits for particular users. > Other things: > - limit the max queue size a user can create > - limit the names a user may call a queue that he creates -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5864) KahaDB recovery with persisteRedeliveryFlag=true can lead to stuck message
Gary Tully created AMQ-5864:
---
Summary: KahaDB recovery with persisteRedeliveryFlag=true can lead
to stuck message
Key: AMQ-5864
URL: https://issues.apache.org/jira/browse/AMQ-5864
Project: ActiveMQ
Issue Type: Bug
Components: KahaDB
Affects Versions: 5.11.0
Reporter: Gary Tully
Assignee: Gary Tully
Fix For: 5.12.0
I send a message to queue "in" and then kill -9 the broker. After the restart,
sometimes the message is lost and I can see following in broker log:
Duplicate message add attempt rejected. Destination: QUEUE://in, Message id:
ID:abe-ThinkPad-T430s-55936-1434452370587-1:1:1:1:1
Without the {code}{code} I'm unable
to reproduce this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQCPP-572) activemq-cmstemplate-stressor.vcproj missing
[ https://issues.apache.org/jira/browse/AMQCPP-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne Johnson updated AMQCPP-572: - Summary: activemq-cmstemplate-stressor.vcproj missing (was: activemq-cmstemplate-stressor.vcproj) > activemq-cmstemplate-stressor.vcproj missing > > > Key: AMQCPP-572 > URL: https://issues.apache.org/jira/browse/AMQCPP-572 > Project: ActiveMQ C++ Client > Issue Type: Bug > Components: Build Support >Affects Versions: 3.8.4 > Environment: Building activemq-cpp-library on Visual Studio 2013 >Reporter: Wayne Johnson >Assignee: Timothy Bish > Labels: VisualStudio > > Unpacked a new copy of activemq-cpp-library-3.8.4-src.zip to build on > VisualStudio 2013. During the upgrade of the project files it (VisualStudio > 2013 upgrade) reported: > activemq-cmstemplate-stressor.vcproj: File > 'C:\Users\C9915437\environment\libraries\apache\activemq-cpp\activemq-cpp-library-3.8.4\vs2008-build\activemq-cmstemplate-stressor.vcproj' > was not found. > SVN appears to be missing (or the solution is erroneously referencing) the > project as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQCPP-572) activemq-cmstemplate-stressor.vcproj
Wayne Johnson created AMQCPP-572: Summary: activemq-cmstemplate-stressor.vcproj Key: AMQCPP-572 URL: https://issues.apache.org/jira/browse/AMQCPP-572 Project: ActiveMQ C++ Client Issue Type: Bug Components: Build Support Affects Versions: 3.8.4 Environment: Building activemq-cpp-library on Visual Studio 2013 Reporter: Wayne Johnson Assignee: Timothy Bish Unpacked a new copy of activemq-cpp-library-3.8.4-src.zip to build on VisualStudio 2013. During the upgrade of the project files it (VisualStudio 2013 upgrade) reported: activemq-cmstemplate-stressor.vcproj: File 'C:\Users\C9915437\environment\libraries\apache\activemq-cpp\activemq-cpp-library-3.8.4\vs2008-build\activemq-cmstemplate-stressor.vcproj' was not found. SVN appears to be missing (or the solution is erroneously referencing) the project as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5340) QueueBrowser with expired messages hangs until woken by expired messages background job
[
https://issues.apache.org/jira/browse/AMQ-5340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601121#comment-14601121
]
Christopher L. Shannon commented on AMQ-5340:
-
[~gtully],
I agree, not checking expiry for browsers makes sense. This almost works but
it appears there is something else that would need to be changed too...The
problem is when running the test case against this change, the last run breaks.
The {{enumeration.hasMoreElements()}} returns true but the only thing pending
is the NULL control message so then {{enumeration.nextElement()}} returns null.
It's detecting that no new messages were added in the iterate() method in
Queue and calling brwoser.decrementQueueRef() which sends the NULL control
message. I haven't looked at it yet to figure out why it's doing that.
> QueueBrowser with expired messages hangs until woken by expired messages
> background job
> ---
>
> Key: AMQ-5340
> URL: https://issues.apache.org/jira/browse/AMQ-5340
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Vermeulen
>Priority: Critical
> Labels: QueueBrowser
> Attachments: AMQ5340BrowsingPerformanceBug.java,
> AMQ5340BrowsingPerformanceBugCorrected.java, AMQ5340BrowsingWithSpring.java
>
>
> I would expect browsing a queue with only a few messages to not take a long
> time. Indeed it normally takes only a few ms. in my application. But
> sometimes the ActiveMQQueueBrowser hangs for up to 30 seconds at method
> before returning!
> When the issue occurs, the loop in hasMoreElements() calls waitForMessage()
> multiple times which times out after 2s at semaphore.wait(2000) without
> receiving any message from the broker. I found that when the broker's
> background job that checks for expired messages runs, the browser happens to
> be woken even if there are no expired messages. So setting the
> expireMessagesPeriod to a low value (e.g. 200ms) is a good workaround for
> this issue, but this is quite brittle because it uses internal broker
> implementation that may not even be related to the issue!
> To reproduce:
> - (this is what I do in my application) create a queue, send a few message
> with an expiration time of 10 seconds and repeatedly browse it until it is
> empty. If I browse the queue after these 10 seconds have passed, the issue
> occurs!
> - I can always reproduce the issue by running AMQ580BrowsingBug from the
> related bug report AMQ-4595: this browsing test seems to always hang. I
> slightly adjusted the test so you can easily change the expired messages
> period and see the runtime differ when changing this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-5863) Composite Send with useCache=false leaves messages pending till restart
[ https://issues.apache.org/jira/browse/AMQ-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-5863. - Resolution: Fixed fix and test in http://git-wip-us.apache.org/repos/asf/activemq/commit/b6fea831 sequence id is cleared *before* store > Composite Send with useCache=false leaves messages pending till restart > --- > > Key: AMQ-5863 > URL: https://issues.apache.org/jira/browse/AMQ-5863 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB, Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Fix For: 5.12.0 > > > With a composite send, the message id is shared across destinations so the > effect of the first store is visible to subsequent stores. This results in > the message store considering the second send to be async in error. The > relevant state in the message id needs to be reset prior to attempting a send. > It is sensible to copy the sequence Id state when a message id is copied so > that acks can take advantage of the presence of the sequence id without > reference to the store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5863) Composite Send with useCache=false leaves messages pending till restart
[ https://issues.apache.org/jira/browse/AMQ-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601056#comment-14601056 ] Gary Tully commented on AMQ-5863: - The fix reworks the fix for https://issues.apache.org/jira/browse/AMQ-5585 a resend and composite send share the same issue with reuse of the messageId sequence state > Composite Send with useCache=false leaves messages pending till restart > --- > > Key: AMQ-5863 > URL: https://issues.apache.org/jira/browse/AMQ-5863 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB, Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Fix For: 5.12.0 > > > With a composite send, the message id is shared across destinations so the > effect of the first store is visible to subsequent stores. This results in > the message store considering the second send to be async in error. The > relevant state in the message id needs to be reset prior to attempting a send. > It is sensible to copy the sequence Id state when a message id is copied so > that acks can take advantage of the presence of the sequence id without > reference to the store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5863) Composite Send with useCache=false leaves messages pending till restart
Gary Tully created AMQ-5863: --- Summary: Composite Send with useCache=false leaves messages pending till restart Key: AMQ-5863 URL: https://issues.apache.org/jira/browse/AMQ-5863 Project: ActiveMQ Issue Type: Bug Components: KahaDB, Message Store Affects Versions: 5.11.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 5.12.0 With a composite send, the message id is shared across destinations so the effect of the first store is visible to subsequent stores. This results in the message store considering the second send to be async in error. The relevant state in the message id needs to be reset prior to attempting a send. It is sensible to copy the sequence Id state when a message id is copied so that acks can take advantage of the presence of the sequence id without reference to the store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5340) QueueBrowser with expired messages hangs until woken by expired messages background job
[
https://issues.apache.org/jira/browse/AMQ-5340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600956#comment-14600956
]
Gary Tully commented on AMQ-5340:
-
[~christopher.l.shannon] - it does not make sense to me that a queue browser
would check expiry, it should get a snapshot of messages from its creation time.
maybe the simplest thing is to make the expiry check from
org.apache.activemq.broker.region.PrefetchSubscription#dispatchPending
conditional on not being a browser:
{code} if (!isBrowser() && node!=QueueMessageReference.NULL_MESSAGE &&
node.isExpired()) {{code}
> QueueBrowser with expired messages hangs until woken by expired messages
> background job
> ---
>
> Key: AMQ-5340
> URL: https://issues.apache.org/jira/browse/AMQ-5340
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Vermeulen
>Priority: Critical
> Labels: QueueBrowser
> Attachments: AMQ5340BrowsingPerformanceBug.java,
> AMQ5340BrowsingPerformanceBugCorrected.java, AMQ5340BrowsingWithSpring.java
>
>
> I would expect browsing a queue with only a few messages to not take a long
> time. Indeed it normally takes only a few ms. in my application. But
> sometimes the ActiveMQQueueBrowser hangs for up to 30 seconds at method
> before returning!
> When the issue occurs, the loop in hasMoreElements() calls waitForMessage()
> multiple times which times out after 2s at semaphore.wait(2000) without
> receiving any message from the broker. I found that when the broker's
> background job that checks for expired messages runs, the browser happens to
> be woken even if there are no expired messages. So setting the
> expireMessagesPeriod to a low value (e.g. 200ms) is a good workaround for
> this issue, but this is quite brittle because it uses internal broker
> implementation that may not even be related to the issue!
> To reproduce:
> - (this is what I do in my application) create a queue, send a few message
> with an expiration time of 10 seconds and repeatedly browse it until it is
> empty. If I browse the queue after these 10 seconds have passed, the issue
> occurs!
> - I can always reproduce the issue by running AMQ580BrowsingBug from the
> related bug report AMQ-4595: this browsing test seems to always hang. I
> slightly adjusted the test so you can easily change the expired messages
> period and see the runtime differ when changing this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
