[jira] [Commented] (AMQ-5260) Cross talk over duplex network connection can lead to blocking (alternative take)

2014-07-16 Thread matteo rulli (JIRA) 

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

matteo rulli commented on AMQ-5260:
---

I upgraded AMQ to 5.10.0 (thus rolling back all my awkward and tenantive 
patches) and I detected the very same deadlock:

{noformat}
Name: ActiveMQ NIO Worker 4006
State: BLOCKED on java.net.URI@5602eaf4 owned by: ActiveMQ Transport: 
tcp:///10.0.1.219:61616@58001
Total blocked: 1  Total waited: 3

Stack trace: 
 
org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteConsumerAdvisory(DemandForwardingBridgeSupport.java:763)
org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:614)
org.apache.activemq.network.DemandForwardingBridgeSupport$3.onCommand(DemandForwardingBridgeSupport.java:224)
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
org.apache.activemq.transport.nio.NIOTransport.serviceRead(NIOTransport.java:138)
org.apache.activemq.transport.nio.NIOTransport$1.onSelect(NIOTransport.java:69)
org.apache.activemq.transport.nio.SelectorSelection.onSelect(SelectorSelection.java:94)
org.apache.activemq.transport.nio.SelectorWorker$1.run(SelectorWorker.java:119)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
{noformat}

{noformat}
Name: ActiveMQ Transport: tcp:///10.0.1.219:61616@58001
State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@598f6549 
owned by: ActiveMQ BrokerService[master2] Task-3288
Total blocked: 734  Total waited: 692

Stack trace: 
 sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(Unknown Source)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
 Source)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Unknown 
Source)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(Unknown Source)
java.util.concurrent.locks.ReentrantLock.lock(Unknown Source)
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:66)
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1370)
org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:889)
org.apache.activemq.broker.TransportConnection.dispatchSync(TransportConnection.java:849)
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:150)
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
org.apache.activemq.transport.vm.VMTransport.doDispatch(VMTransport.java:138)
org.apache.activemq.transport.vm.VMTransport.dispatch(VMTransport.java:130)
   - locked java.util.concurrent.atomic.AtomicBoolean@56b2aa50
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:107)
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:81)
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:86)
org.apache.activemq.network.DemandForwardingBridgeSupport.addSubscription(DemandForwardingBridgeSupport.java:905)
org.apache.activemq.network.DemandForwardingBridgeSupport.addConsumerInfo(DemandForwardingBridgeSupport.java:1178)
org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteConsumerAdvisory(DemandForwardingBridgeSupport.java:763)
   - locked java.net.URI@5602eaf4
org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:614)
org.apache.activemq.network.DemandForwardingBridgeSupport$3.onCommand(DemandForwardingBridgeSupport.java:224)
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
org.apache.activemq.transport.failover.FailoverTransport$3.onCommand(FailoverTransport.java:208)
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)
org.apache.activemq.transport.TransportSupport.doConsume(Transport

[jira] [Updated] (AMQ-5260) Cross talk over duplex network connection can lead to blocking (alternative take)

2014-07-16 Thread matteo rulli (JIRA) 

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

matteo rulli updated AMQ-5260:
--

Affects Version/s: 5.10.0

> Cross talk over duplex network connection can lead to blocking (alternative 
> take)
> -
>
> Key: AMQ-5260
> URL: https://issues.apache.org/jira/browse/AMQ-5260
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.9.0, 5.10.0
>Reporter: matteo rulli
> Attachments: AMQ_5260.patch, AMQ_5260_2.patch, AMQ_5260_3.patch, 
> deadlock.jpg, debug.jpg
>
>
> Pretty the same description with respect to AMQ-4328. 
> 
> !deadlock.jpg!
> h2. Stacktraces:
> Stacktrace no.1:
> {noformat}
> Name: ActiveMQ NIO Worker 12
> State: BLOCKED on java.net.URI@1bae2b28 owned by: ActiveMQ Transport: 
> tcp:///10.0.1.219:61616@57789
> Total blocked: 2  Total waited: 67
> Stack trace: 
>  
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteConsumerAdvisory(DemandForwardingBridgeSupport.java:714)
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:581)
> org.apache.activemq.network.DemandForwardingBridgeSupport$3.onCommand(DemandForwardingBridgeSupport.java:191)
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
> org.apache.activemq.transport.nio.NIOTransport.serviceRead(NIOTransport.java:138)
> org.apache.activemq.transport.nio.NIOTransport$1.onSelect(NIOTransport.java:69)
> org.apache.activemq.transport.nio.SelectorSelection.onSelect(SelectorSelection.java:94)
> org.apache.activemq.transport.nio.SelectorWorker$1.run(SelectorWorker.java:119)
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> java.lang.Thread.run(Unknown Source)
> {noformat}
> 
> stack trace no.2
> {noformat}
> Name: ActiveMQ Transport: tcp:///10.0.1.219:61616@57789
> State: WAITING on 
> java.util.concurrent.locks.ReentrantLock$NonfairSync@3cdbfa3e owned by: 
> ActiveMQ BrokerService[master2] Task-4
> Total blocked: 19  Total waited: 3
> Stack trace: 
>  sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(Unknown Source)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
>  Source)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Unknown 
> Source)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(Unknown Source)
> java.util.concurrent.locks.ReentrantLock.lock(Unknown Source)
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:66)
> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1339)
> org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:858)
> org.apache.activemq.broker.TransportConnection.dispatchSync(TransportConnection.java:818)
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:151)
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> org.apache.activemq.transport.vm.VMTransport.doDispatch(VMTransport.java:138)
> org.apache.activemq.transport.vm.VMTransport.dispatch(VMTransport.java:127)
>- locked java.util.concurrent.atomic.AtomicBoolean@689389da
> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:104)
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:81)
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:86)
> org.apache.activemq.network.DemandForwardingBridgeSupport.addSubscription(DemandForwardingBridgeSupport.java:856)
> org.apache.activemq.network.DemandForwardingBridgeSupport.addConsumerInfo(DemandForwardingBridgeSupport.java:1128)
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteConsumerAdvisory(DemandForwardingBridgeSupport.java:714)
>- locked java.net.URI@1bae2b28
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:581)
> org.apache.activem

Re: {VOTE] Release Apache.NMS.ActiveMQ 1.6.3

2014-07-16 Thread Claus Ibsen 
+1

On Thu, Jul 17, 2014 at 12:34 AM, Timothy Bish  wrote:
> Hello
>
> This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.6.3
>
> This is a bug fix only release focusing on some issues with Consumers in
> local transacted sessions and an update to the ZLib library to fix some
> error when uncompressing messages of a certain size.
>
> The binaries and source bundles for the Release Candidate can be found here:
> http://people.apache.org/~tabish/nms-1.6.0
>
> The Wiki Page for this release is here:
> http://activemq.apache.org/nms/apachenmsactivemq-v163.html
>
> The list of issues resolved is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201&version=12325840
>
> Please cast your votes (the vote will be open for 72 hrs):
>
> [ ] +1 Release the source as Apache NMS.ActiveMQ v1.6.3
> [ ] -1 Veto the release (provide specific comments)
>
> Here's my +1
>
> Regards
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.b...@redhat.com | www.redhat.com
> skype: tabish121 | twitter: @tabish121
> blog: http://timbish.blogspot.com/
>



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

[jira] [Updated] (AMQ-5278) Proton JMS transformer causes corrupted payload with redelivered messages

2014-07-16 Thread Timothy Bish (JIRA) 

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

Timothy Bish updated AMQ-5278:
--

Fix Version/s: 5.11.0

> Proton JMS transformer causes corrupted payload with redelivered messages
> -
>
> Key: AMQ-5278
> URL: https://issues.apache.org/jira/browse/AMQ-5278
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Jesse Fugitt
>  Labels: amqp
> Fix For: 5.11.0
>
> Attachments: AMQ5278Test.java
>
>
> When using AMQP with transformer=jms, redelivered messages have a corrupted 
> payload (payload of all zeros).  Creating this JIRA to link to the already 
> opened Proton JIRA (624) and to provide a unit test for ActiveMQ.
> See https://issues.apache.org/jira/browse/PROTON-624 for details.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQ-5278) Proton JMS transformer causes corrupted payload with redelivered messages

2014-07-16 Thread Timothy Bish (JIRA) 

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

Timothy Bish commented on AMQ-5278:
---

The proton issue was resolved today, targeted for v0.8.  We'll upgrade to that 
release once it's out. 

> Proton JMS transformer causes corrupted payload with redelivered messages
> -
>
> Key: AMQ-5278
> URL: https://issues.apache.org/jira/browse/AMQ-5278
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Jesse Fugitt
>  Labels: amqp
> Fix For: 5.11.0
>
> Attachments: AMQ5278Test.java
>
>
> When using AMQP with transformer=jms, redelivered messages have a corrupted 
> payload (payload of all zeros).  Creating this JIRA to link to the already 
> opened Proton JIRA (624) and to provide a unit test for ActiveMQ.
> See https://issues.apache.org/jira/browse/PROTON-624 for details.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

{VOTE] Release Apache.NMS.ActiveMQ 1.6.3

2014-07-16 Thread Timothy Bish 

Hello

This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.6.3

This is a bug fix only release focusing on some issues with Consumers in 
local transacted sessions and an update to the ZLib library to fix some 
error when uncompressing messages of a certain size.


The binaries and source bundles for the Release Candidate can be found here:
http://people.apache.org/~tabish/nms-1.6.0

The Wiki Page for this release is here:
http://activemq.apache.org/nms/apachenmsactivemq-v163.html

The list of issues resolved is here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201&version=12325840

Please cast your votes (the vote will be open for 72 hrs):

[ ] +1 Release the source as Apache NMS.ActiveMQ v1.6.3
[ ] -1 Veto the release (provide specific comments)

Here's my +1

Regards

--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.b...@redhat.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [VOTE] Release ActiveMQ-CPP v3.8.3

2014-07-16 Thread Hadrian Zbarcea 
+1
Hadrian

On Tue, Jul 15, 2014 at 3:13 PM, Hiram Chirino 
wrote:

> +1
>
> On Mon, Jul 14, 2014 at 10:02 AM, Timothy Bish 
> wrote:
> > Vote open for ActiveMQ-CPP v3.8.3
> >
> > Its been awhile since we did a bugfix release for ActiveMQ-CPP so I think
> > its time to roll out another one.  This release addresses some crash
> issues
> > and improves overall stability.
> >
> > The source bundles for this release can be found here:
> > 
> >
> > The Wiki page for the release is here:
> > 
> >
> > The list of issues fixed in this release is available here:
> > <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311207&styleName=Html&version=12325744
> >
> >
> > Please cast your votes:
> >
> > [ ] +1 Release the source as Apache ActiveMQ-CPP 3.8.3
> > [ ] -1 Veto the release (provide specific comments)
> >
> > Here is my +1
> >
> > --
> > Tim Bish
> > Sr Software Engineer | RedHat Inc.
> > tim.b...@redhat.com | www.redhat.com
> > skype: tabish121 | twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
>

[jira] [Resolved] (AMQNET-484) A consumer in a Transacted Session with no pending Acks can be eagerly closed.

2014-07-16 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQNET-484.
-

Resolution: Fixed

Fixed on trunk and the 1.6.x branch

> A consumer in a Transacted Session with no pending Acks can be eagerly closed.
> --
>
> Key: AMQNET-484
> URL: https://issues.apache.org/jira/browse/AMQNET-484
> Project: ActiveMQ .Net
>  Issue Type: Improvement
>  Components: ActiveMQ
>Affects Versions: 1.6.0, 1.6.1, 1.6.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 1.6.3, 1.7.0
>
>
> For MessageConsumer instances that created from Transacted Sessions and are 
> closed without ever dispatching any messages we can eagerly close then 
> instead of delaying their close until the session is committed.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (AMQNET-484) A consumer in a Transacted Session with no pending Acks can be eagerly closed.

2014-07-16 Thread Timothy Bish (JIRA) 
Timothy Bish created AMQNET-484:
---

 Summary: A consumer in a Transacted Session with no pending Acks 
can be eagerly closed.
 Key: AMQNET-484
 URL: https://issues.apache.org/jira/browse/AMQNET-484
 Project: ActiveMQ .Net
  Issue Type: Improvement
  Components: ActiveMQ
Affects Versions: 1.6.2, 1.6.0, 1.6.1
Reporter: Timothy Bish
Assignee: Timothy Bish
Priority: Minor
 Fix For: 1.6.3, 1.7.0


For MessageConsumer instances that created from Transacted Sessions and are 
closed without ever dispatching any messages we can eagerly close then instead 
of delaying their close until the session is committed.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQNET-484) A consumer in a Transacted Session with no pending Acks can be eagerly closed.

2014-07-16 Thread Timothy Bish (JIRA) 

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

Timothy Bish commented on AMQNET-484:
-

Same as this issue, the consumer could be closed eagerly which would release 
any prefetched messages back to the broker for dispatch to another consumer. 

> A consumer in a Transacted Session with no pending Acks can be eagerly closed.
> --
>
> Key: AMQNET-484
> URL: https://issues.apache.org/jira/browse/AMQNET-484
> Project: ActiveMQ .Net
>  Issue Type: Improvement
>  Components: ActiveMQ
>Affects Versions: 1.6.0, 1.6.1, 1.6.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 1.6.3, 1.7.0
>
>
> For MessageConsumer instances that created from Transacted Sessions and are 
> closed without ever dispatching any messages we can eagerly close then 
> instead of delaying their close until the session is committed.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (AMQNET-483) MessageConsumer close when inside transaction is not idempotent.

2014-07-16 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQNET-483.
-

Resolution: Fixed

Fixed on trunk and the 1.6.x fixes branch

> MessageConsumer close when inside transaction is not idempotent.
> 
>
> Key: AMQNET-483
> URL: https://issues.apache.org/jira/browse/AMQNET-483
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Affects Versions: 1.6.0, 1.6.1, 1.6.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 1.6.3, 1.7.0
>
>
> When a consumer is closed and it's session is transacted it registers a 
> synchronization on the Session TransactionContext to complete the close after 
> the transaction has been committed or rolled back.  The synchronization can 
> be added multiple times is close is called in succession but the 
> synchronization doesn't check if the consumer has been closed when invoked so 
> the transaction completion can result in several attempts to remove the same 
> consumer.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (AMQNET-483) MessageConsumer close when inside transaction is not idempotent.

2014-07-16 Thread Timothy Bish (JIRA) 

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

Timothy Bish reassigned AMQNET-483:
---

Assignee: Timothy Bish  (was: Jim Gomes)

> MessageConsumer close when inside transaction is not idempotent.
> 
>
> Key: AMQNET-483
> URL: https://issues.apache.org/jira/browse/AMQNET-483
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Affects Versions: 1.6.0, 1.6.1, 1.6.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 1.6.3, 1.7.0
>
>
> When a consumer is closed and it's session is transacted it registers a 
> synchronization on the Session TransactionContext to complete the close after 
> the transaction has been committed or rolled back.  The synchronization can 
> be added multiple times is close is called in succession but the 
> synchronization doesn't check if the consumer has been closed when invoked so 
> the transaction completion can result in several attempts to remove the same 
> consumer.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (AMQNET-483) MessageConsumer close when inside transaction is not idempotent.

2014-07-16 Thread Timothy Bish (JIRA) 
Timothy Bish created AMQNET-483:
---

 Summary: MessageConsumer close when inside transaction is not 
idempotent.
 Key: AMQNET-483
 URL: https://issues.apache.org/jira/browse/AMQNET-483
 Project: ActiveMQ .Net
  Issue Type: Bug
  Components: ActiveMQ
Affects Versions: 1.6.2, 1.6.0, 1.6.1
Reporter: Timothy Bish
Assignee: Jim Gomes
 Fix For: 1.6.3, 1.7.0


When a consumer is closed and it's session is transacted it registers a 
synchronization on the Session TransactionContext to complete the close after 
the transaction has been committed or rolled back.  The synchronization can be 
added multiple times is close is called in succession but the synchronization 
doesn't check if the consumer has been closed when invoked so the transaction 
completion can result in several attempts to remove the same consumer.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (AMQNET-482) Consumers and Producers that fail to register at the broker shouldn't send a remove request.

2014-07-16 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQNET-482.
-

Resolution: Fixed

Fixed on trunk and the 1.6.x branch

> Consumers and Producers that fail to register at the broker shouldn't send a 
> remove request.
> 
>
> Key: AMQNET-482
> URL: https://issues.apache.org/jira/browse/AMQNET-482
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Affects Versions: 1.5.6, 1.6.0, 1.6.1, 1.6.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 1.6.3, 1.7.0
>
>
> In Sessions.cs when an exception is received during the creation of a 
> MessageConsumer or MessageProducer ends up calling the close() method on the 
> freshly created producer or consumer which results in a call to send a 
> RemoveInfo to the broker for the failed resource.  The Broker will log a 
> message in this case indicating it can't remove a resource that hasn't been 
> created.  We shouldn't be calling closed here since the resource was never 
> fully opened.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (AMQNET-482) Consumers and Producers that fail to register at the broker shouldn't send a remove request.

2014-07-16 Thread Timothy Bish (JIRA) 
Timothy Bish created AMQNET-482:
---

 Summary: Consumers and Producers that fail to register at the 
broker shouldn't send a remove request.
 Key: AMQNET-482
 URL: https://issues.apache.org/jira/browse/AMQNET-482
 Project: ActiveMQ .Net
  Issue Type: Bug
  Components: ActiveMQ
Affects Versions: 1.6.2, 1.6.0, 1.5.6, 1.6.1
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 1.6.3, 1.7.0


In Sessions.cs when an exception is received during the creation of a 
MessageConsumer or MessageProducer ends up calling the close() method on the 
freshly created producer or consumer which results in a call to send a 
RemoveInfo to the broker for the failed resource.  The Broker will log a 
message in this case indicating it can't remove a resource that hasn't been 
created.  We shouldn't be calling closed here since the resource was never 
fully opened.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (AMQ-5278) Proton JMS transformer causes corrupted payload with redelivered messages

2014-07-16 Thread Jesse Fugitt (JIRA) 
Jesse Fugitt created AMQ-5278:
-

 Summary: Proton JMS transformer causes corrupted payload with 
redelivered messages
 Key: AMQ-5278
 URL: https://issues.apache.org/jira/browse/AMQ-5278
 Project: ActiveMQ
  Issue Type: Bug
  Components: AMQP
Affects Versions: 5.10.0
Reporter: Jesse Fugitt


When using AMQP with transformer=jms, redelivered messages have a corrupted 
payload (payload of all zeros).  Creating this JIRA to link to the already 
opened Proton JIRA (624) and to provide a unit test for ActiveMQ.

See https://issues.apache.org/jira/browse/PROTON-624 for details.




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (AMQ-5278) Proton JMS transformer causes corrupted payload with redelivered messages

2014-07-16 Thread Jesse Fugitt (JIRA) 

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

Jesse Fugitt updated AMQ-5278:
--

Attachment: AMQ5278Test.java

Attached unit test.

> Proton JMS transformer causes corrupted payload with redelivered messages
> -
>
> Key: AMQ-5278
> URL: https://issues.apache.org/jira/browse/AMQ-5278
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Jesse Fugitt
>  Labels: amqp
> Attachments: AMQ5278Test.java
>
>
> When using AMQP with transformer=jms, redelivered messages have a corrupted 
> payload (payload of all zeros).  Creating this JIRA to link to the already 
> opened Proton JIRA (624) and to provide a unit test for ActiveMQ.
> See https://issues.apache.org/jira/browse/PROTON-624 for details.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[GitHub] activemq pull request: Fix typo

2014-07-16 Thread asfgit 
Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq pull request: Fix typo

2014-07-16 Thread woodenToaster 
GitHub user woodenToaster opened a pull request:

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

Fix typo



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

$ git pull https://github.com/woodenToaster/activemq trunk

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

https://github.com/apache/activemq/pull/35.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 #35


commit 385334bf087d95a2e6bed34af24cf891e1e19be6
Author: woodenToaster 
Date:   2014-07-16T14:28:38Z

Fix typo




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Advisory messages for remote broker clients?

2014-07-16 Thread nauman73 
Hi ceposta

I think I found the solution. Adding the "forceSendOriginalMessage=true"
option on the "to" endpoint seems to do the trick.

Regards
Nauman



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Advisory-messages-for-remote-broker-clients-tp4683016p4683312.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: Advisory messages for remote broker clients?

2014-07-16 Thread nauman73 
Hi ceposta

I am having little problem with routing of advisory messages to opposite
broker. While the advisory message does appear to get routed to opposite
broker, the format of the advisory message is not the same as the original
message. The route declaration is as follows. I have followed the example
given at "Consuming Advisory Messages" section of 
http://camel.apache.org/activemq.html
   with some modification.


Connection Advisory Route




The issue I have is that the "dataStructure" of the routed ActiveMQMessage
is always null. Whereas the "dataStructure" of the original advisory message
has the RemoveInfo, ProducerInfo etc. depending on type of activity. If I
run the example route given at above mentioned URL, I do get the proper
"dataStructure" written to the output file used in that example.

If I change my route to match the route given in the example, except for the
"to" endpoint, the route becomes as follows.


Connection Advisory Route



  ${in.body}




With this route, the routed message type is changed to "ActiveMQTextMessage"
instead of the "ActiveMQMessage". The "dataStructure" is still null.

I have tried variations of above route definition. I have also tried to set
the "jmsMessageType" and "mapJmsMessage" options differently. None of these
works and I always get the dataStructure as null in the advisory message
routed to opposite broker.

Any clues?

Thanks

Regards
Nauman



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Advisory-messages-for-remote-broker-clients-tp4683016p4683308.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] [Reopened] (AMQ-5274) Stuck messages and CPU churn when aborted transacted message expires

2014-07-16 Thread Yannick Malins (JIRA) 

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

Yannick Malins reopened AMQ-5274:
-


Hi Tim,

I just ran my test against apache-activemq-5.11-20140715.223633-34 on win64 , 
and I got exactly the same issue.

The test script prints that it rejects messages 1->10 (the others have already 
expired), and after it closes, when you go to:

http://localhost:8161/admin/queues.jsp

you see:

ActiveMQ.DLQ20  0   20  0   Browse Active Consumers
Active Producers
Send To Purge Delete
queue.test  1   0   20  19  Browse Active Consumers
Active Producers
Send To Purge Delete

There is one "ghost" message stuck in queue.test

I will try integrating your junit and running that to see if I can reproduce 
with that, it will make things easier indeed

> Stuck messages and CPU churn when aborted transacted message expires
> 
>
> Key: AMQ-5274
> URL: https://issues.apache.org/jira/browse/AMQ-5274
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.8.0, 5.9.0, 5.9.1, 5.10.0
> Environment: win64, RHEL11
>Reporter: Yannick Malins
>Priority: Critical
> Attachments: AMQ-5274.zip, AMQ5274Test.java, logs_extract.txt
>
>
> The test case is a simple producer/consumer:
> Producer: 20 messages are injected, with a timeout of 10s.
> Consumer: The redelivery policy is set to 0 retries (the issue exists with 
> other values). The consumer uses transactions and throws a runtime exception 
> on each message received.
> queue stats show 20 enqueue, 19 dequeue, 1 pending
> DLQ stat show 20 enqueue: all 20 messages go to DLQ, IDs ending in 1-10 for 
> failing, 11-20 for expiry (approx)
> the pending item (ID ending in 10) is a "ghost message" , and remains stuck 
> indefinitely in queue.test
> if you browse, the message is not shown
> A) if you restart the broker, after a short while the message is cleaned:
> jvm 1|  WARN | Duplicate message add attempt rejected. Destination: 
> QUEUE://ActiveMQ.DLQ, Message id: ID:REDACTED-52872-1405079629779-1:1:1:1:10
> jvm 1|  WARN | 
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch@5b427f3c:ActiveMQ.DLQ,batchResetNeeded=false,storeHasMessages=true,size=0,cacheEnabled=true,maxBatchSize:20,hasSpace:tru
> e - cursor got duplicate: ID:REDACTED--52872-1405079629779-1:1:1:1:10, 4
> jvm 1|  WARN | duplicate message from store 
> ID:REDACTED--52872-1405079629779-1:1:1:1:10, redirecting for dlq processing
> B) if you purge, ActiveMQ logs a warning: "WARN | queue://queue.test after 
> purge complete, message count stats report: 1"
>   the queue is marked as being empty.
>   however if you restart the broker, the message re-appears shorty, 
> before being cleaned as above
>   
>   
> SUPPLEMENTARY: with activeMQ 5.9.0 and above , if you run the injection 
> several times, the CPU usage of ActiveMQ climbs drastically until the queue 
> is purged.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build is back to normal : ActiveMQ ยป ActiveMQ :: AMQP #1482

2014-07-16 Thread Apache Jenkins Server 
See