Jenkins build is back to stable : ActiveMQ » ActiveMQ :: AMQP #1417

[Apache Jenkins Server]

See 

Re: Outdated documentation on the site

[Robert Davies]

some of the pages are  just duplicates by ${include} between the different 
versions - its all a bit of a mess - but your right it should be done - shout  
if you need help and good luck!

On 14 Nov 2013, at 23:32, Hadrian Zbarcea  wrote:

> Hi,
> 
> Some of documentation in the wiki is extremely outdated, like the getting 
> started guide [1]. I don't think anybody is using AMQ 4.x for instance. I'll 
> go through the whole site and update as much as I can in the coming days. Any 
> objections?
> 
> Hadrian
> 
> [1] http://activemq.apache.org/getting-started.html
> 
> 
> -- 
> Hadrian Zbarcea
> Principal Software Architect
> Talend, Inc
> http://coders.talend.com/
> http://camelbot.blogspot.com/

Rob Davies
-
Red Hat, Inc
Twitter: rajdavies
Blog: http://rajdavies.blogspot.com
ActiveMQ in Action: http://www.manning.com/snyder/

[jira] [Updated] (AMQ-4887) ActiveMQBytesMessage will lost content if message's property was set before copy

[caoyunfei (JIRA)]

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

caoyunfei updated AMQ-4887:
---

Description: 
ActiveMQBytesMessage will lost content if message's property was set before 
copy. Here is the test code:

Producer:
MessageProducer producer;  
//initialize Connection, Session, MessageProducer
byte[] bs = "bytes message".getBytes();  
BytesMessage message = session.createBytesMessage();  
message.writeBytes(bs);  //write bytes to message 1
  
for(int i=0; i< 0; i++){  
  // then set message's propery   2
message.setLongProperty("sendTime", System.currentTimeMillis());  
try{  
producer.send(message);  
}catch(){  
 e.printStackTrace();  
}
}  

Consumer:

MessageConsumer consumer  
//initailize Connection, Session, MessageConsumer  
for(int i=0; i<10; i++){  
ActiveMQBytesMessage msg = (ActiveMQBytesMessage)consumer.receive(60*1000); 
 
long sendTime = message.getLongProperty("sendTime");  
System.out.println("sendtime:" + sendTime);  
ByteSequence bs = message.getMessage().getContent();  
System.out.println("bytes data:" + new String(bs.getData()));  
}  

Expected result:
consumer gets bytes data in all received messages

Actual result:
only the fisrt message has bytes data, all other messages lost bytes data, 
while long property value is not lost;

Analysization:
message gets copied when send, it will call storeContent() before copy,  
DataOutputStream dataOut will be closed and the data in dataOut will be set to 
conent. This works correctly if there are no property was set.

when setLongProperty was called, it will call setObjectProperty() then will 
call  initializeWriting(), here DataOutputStream dataOut  will be create AGAIN. 

So when message was copied in second time, DataOutputStream dataOut is NOT 
null, but EMPTY, it will clear the value in content.

suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()

my fix:
ActiveMQBytesMessage :
 private void  initializeWriting() throws JMSException {
669The original code
..
701
//fix code
if(this.content !=null && this.content.length >0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}

  was:
ActiveMQBytesMessage will lost content if message's property was set before 
copy. Here is the test code:

Producer:
MessageProducer producer;  
//initialize Connection, Session, MessageProducer
byte[] bs = "bytes message".getBytes();  
BytesMessage message = session.createBytesMessage();  
message.writeBytes(bs);  //write bytes to message 1
  
for(int i=0; i< 0; i++){  
  // then set message's propery   2
message.setLongProperty("sendTime", System.currentTimeMillis());  
try{  
producer.send(message);  
}catch(){  
 e.printStackTrace();  
}
}  

Consumer:

MessageConsumer consumer  
//initailize Connection, Session, MessageConsumer  
for(int i=0; i<10; i++){  
ActiveMQBytesMessage msg = (ActiveMQBytesMessage)consumer.receive(60*1000); 
 
long sendTime = message.getLongProperty("sendTime");  
System.out.println("sendtime:" + sendTime);  
ByteSequence bs = message.getMessage().getContent();  
System.out.println("bytes data:" + new String(bs.getData()));  
}  

Expected result:
consumer gets bytes data in all received messages

Actual result:
only the fisrt message has bytes data, all other messages lost bytes data, 
while long property value is not lost;

Analysization:
message gets copied when send, it will call storeContent() before copy,  
DataOutputStream dataOut will be closed and the data in dataOut will be set to 
conent. This works correctly if there are no property was set.

when setLongProperty was called, it will call setObjectProperty() then will 
call  initializeWriting(), here DataOutputStream dataOut  will be create AGAIN. 

So when message was copied in second time, DataOutputStream dataOut is NOT 
null, but EMPTY, it will clear the value in content.

suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()

my fix:

 private void More ...initializeWriting() throws JMSException {
669The original code
..
701
//fix code
if(this.content !=null && this.content.length >0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}


> ActiveMQBytesMessage will lost content if message's property was set before 
> copy 
> -
>
> Ke

[jira] [Updated] (AMQ-4887) ActiveMQBytesMessage will lost content if message's property was set before copy

[caoyunfei (JIRA)]

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

caoyunfei updated AMQ-4887:
---

Description: 
ActiveMQBytesMessage will lost content if message's property was set before 
copy. Here is the test code:

Producer:
MessageProducer producer;  
//initialize Connection, Session, MessageProducer
byte[] bs = "bytes message".getBytes();  
BytesMessage message = session.createBytesMessage();  
message.writeBytes(bs);  //write bytes to message 1
  
for(int i=0; i< 0; i++){  
  // then set message's propery   2
message.setLongProperty("sendTime", System.currentTimeMillis());  
try{  
producer.send(message);  
}catch(){  
 e.printStackTrace();  
}
}  

Consumer:

MessageConsumer consumer  
//initailize Connection, Session, MessageConsumer  
for(int i=0; i<10; i++){  
ActiveMQBytesMessage msg = (ActiveMQBytesMessage)consumer.receive(60*1000); 
 
long sendTime = message.getLongProperty("sendTime");  
System.out.println("sendtime:" + sendTime);  
ByteSequence bs = message.getMessage().getContent();  
System.out.println("bytes data:" + new String(bs.getData()));  
}  

Expected result:
consumer gets bytes data in all received messages

Actual result:
only the fisrt message has bytes data, all other messages lost bytes data, 
while long property value is not lost;

Analysization:
message gets copied when send, it will call storeContent() before copy,  
DataOutputStream dataOut will be closed and the data in dataOut will be set to 
conent. This works correctly if there are no property was set.

when setLongProperty was called, it will call setObjectProperty() then will 
call  initializeWriting(), here DataOutputStream dataOut  will be create AGAIN. 

So when message was copied in second time, DataOutputStream dataOut is NOT 
null, but EMPTY, it will clear the value in content.

suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()

my fix:

 private void More ...initializeWriting() throws JMSException {
669The original code
..
701
//fix code
if(this.content !=null && this.content.length >0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}

  was:
ActiveMQBytesMessage will lost content if message's property was set before 
copy. Here is the test code:

Producer:
MessageProducer producer;  
//initialize Connection, Session, MessageProducer
byte[] bs = "bytes message".getBytes();  
BytesMessage message = session.createBytesMessage();  
message.writeBytes(bs);  //write bytes to message 1
  
for(int i=0; i< 0; i++){  
  // then set message's propery   2
message.setLongProperty("sendTime", System.currentTimeMillis());  
try{  
producer.send(message);  
}catch(){  
 e.printStackTrace();  
}
}  

Consumer:

MessageConsumer consumer  
//initailize Connection, Session, MessageConsumer  
for(int i=0; i<10; i++){  
ActiveMQBytesMessage msg = (ActiveMQBytesMessage)consumer.receive(60*1000); 
 
long sendTime = message.getLongProperty("sendTime");  
System.out.println("sendtime:" + sendTime);  
ByteSequence bs = message.getMessage().getContent();  
System.out.println("bytes data:" + new String(bs.getData()));  
}  

Expected result:
consumer gets bytes data in all received messages

Actual result:
only the fisrt message has bytes data, all other messages lost bytes data, 
while long property value is not lost;

Analysization:
message gets copied when send, it will call storeContent() before copy,  
DataOutputStream dataOut will be closed and the data in dataOut will be set to 
conent. This works correctly if there are no property was set.

when setLongProperty was called, it will call setObjectProperty() then will 
call  initializeWriting(), here DataOutputStream dataOut  will be create AGAIN. 

So when message was copied in second time, DataOutputStream dataOut is NOT 
null, but EMPTY, it will clear the value in content.

suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()

my fix:

 private void More ...initializeWriting() throws JMSException {
669The original code
..
701}
//fix code
if(this.content !=null && this.content.length >0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}


> ActiveMQBytesMessage will lost content if message's property was set before 
> copy 
> -
>
> Key: AMQ-4887
> 

[jira] [Commented] (AMQ-4693) Add kerberos [SASL] authentication for TCP connectors

[Steven (JIRA)]

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

Steven commented on AMQ-4693:
-

Gary, Christian, Claus?? Anybody from ActiveMQ team?

> Add kerberos [SASL] authentication for TCP connectors
> -
>
> Key: AMQ-4693
> URL: https://issues.apache.org/jira/browse/AMQ-4693
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: linux, solaris
>Reporter: Bhanu
>Priority: Minor
> Fix For: 5.10.0
>
>
> Hi,
> Can kerberos based authentication be added to ActiveMQ's TCP connectors.
> Thanks,
> Bhanu



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

[jira] [Created] (AMQ-4887) ActiveMQBytesMessage will lost content if message's property was set before copy

[caoyunfei (JIRA)]

caoyunfei created AMQ-4887:
--

 Summary: ActiveMQBytesMessage will lost content if message's 
property was set before copy 
 Key: AMQ-4887
 URL: https://issues.apache.org/jira/browse/AMQ-4887
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.9.0
Reporter: caoyunfei


ActiveMQBytesMessage will lost content if message's property was set before 
copy. Here is the test code:

Producer:
MessageProducer producer;  
//initialize Connection, Session, MessageProducer
byte[] bs = "bytes message".getBytes();  
BytesMessage message = session.createBytesMessage();  
message.writeBytes(bs);  //write bytes to message 1
  
for(int i=0; i< 0; i++){  
  // then set message's propery   2
message.setLongProperty("sendTime", System.currentTimeMillis());  
try{  
producer.send(message);  
}catch(){  
 e.printStackTrace();  
}
}  

Consumer:

MessageConsumer consumer  
//initailize Connection, Session, MessageConsumer  
for(int i=0; i<10; i++){  
ActiveMQBytesMessage msg = (ActiveMQBytesMessage)consumer.receive(60*1000); 
 
long sendTime = message.getLongProperty("sendTime");  
System.out.println("sendtime:" + sendTime);  
ByteSequence bs = message.getMessage().getContent();  
System.out.println("bytes data:" + new String(bs.getData()));  
}  

Expected result:
consumer gets bytes data in all received messages

Actual result:
only the fisrt message has bytes data, all other messages lost bytes data, 
while long property value is not lost;

Analysization:
message gets copied when send, it will call storeContent() before copy,  
DataOutputStream dataOut will be closed and the data in dataOut will be set to 
conent. This works correctly if there are no property was set.

when setLongProperty was called, it will call setObjectProperty() then will 
call  initializeWriting(), here DataOutputStream dataOut  will be create AGAIN. 

So when message was copied in second time, DataOutputStream dataOut is NOT 
null, but EMPTY, it will clear the value in content.

suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()

my fix:

 private void More ...initializeWriting() throws JMSException {
669The original code
..
701}
//fix code
if(this.content !=null && this.content.length >0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}



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

Re: Outdated documentation on the site

[Johan Edstrom]

Go, go, go!!!

On Nov 14, 2013, at 4:47 PM, Christian Posta  wrote:

> ummm... no. go for it :) thanks :)
> 
> On Thu, Nov 14, 2013 at 4:32 PM, Hadrian Zbarcea  wrote:
>> Hi,
>> 
>> Some of documentation in the wiki is extremely outdated, like the getting
>> started guide [1]. I don't think anybody is using AMQ 4.x for instance. I'll
>> go through the whole site and update as much as I can in the coming days.
>> Any objections?
>> 
>> Hadrian
>> 
>> [1] http://activemq.apache.org/getting-started.html
>> 
>> 
>> --
>> Hadrian Zbarcea
>> Principal Software Architect
>> Talend, Inc
>> http://coders.talend.com/
>> http://camelbot.blogspot.com/
> 
> 
> 
> -- 
> Christian Posta
> http://www.christianposta.com/blog
> twitter: @christianposta

Re: Outdated documentation on the site

[Christian Posta]

ummm... no. go for it :) thanks :)

On Thu, Nov 14, 2013 at 4:32 PM, Hadrian Zbarcea  wrote:
> Hi,
>
> Some of documentation in the wiki is extremely outdated, like the getting
> started guide [1]. I don't think anybody is using AMQ 4.x for instance. I'll
> go through the whole site and update as much as I can in the coming days.
> Any objections?
>
> Hadrian
>
> [1] http://activemq.apache.org/getting-started.html
>
>
> --
> Hadrian Zbarcea
> Principal Software Architect
> Talend, Inc
> http://coders.talend.com/
> http://camelbot.blogspot.com/



-- 
Christian Posta
http://www.christianposta.com/blog
twitter: @christianposta

[jira] [Commented] (AMQNET-459) Dot Net platform - invalid durable queue test case, durable queue does not work

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQNET-459:
-

This is a very old release, recommend you move to the 1.6.x line. 

> Dot Net platform - invalid durable queue test case, durable queue does not 
> work
> ---
>
> Key: AMQNET-459
> URL: https://issues.apache.org/jira/browse/AMQNET-459
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Reporter: Jim Dandy
>Priority: Minor
> Attachments: DurableTest.cs
>
>
> I've been having difficulty getting durable consumers working with ActiveMQ 
> in a C# and Windows environment (works fine in Java).
> So I looked at the test case and was surprised to see the test uses the same 
> connection and session to run both the consumer and the producer, for the 
> entire test. If you separate the consumer and producer into separate 
> processes the test fails.
> The test code is found in file csharp_api/DurableTest.cs



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

[jira] [Commented] (AMQNET-459) Dot Net platform - invalid durable queue test case, durable queue does not work

[Jim Dandy (JIRA)]

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

Jim Dandy commented on AMQNET-459:
--

Why can't I edit my earlier comments? Anyway, I got 1.6.1 and things have 
changed a lot; still looking for the durable tests.

> Dot Net platform - invalid durable queue test case, durable queue does not 
> work
> ---
>
> Key: AMQNET-459
> URL: https://issues.apache.org/jira/browse/AMQNET-459
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Reporter: Jim Dandy
>Priority: Minor
> Attachments: DurableTest.cs
>
>
> I've been having difficulty getting durable consumers working with ActiveMQ 
> in a C# and Windows environment (works fine in Java).
> So I looked at the test case and was surprised to see the test uses the same 
> connection and session to run both the consumer and the producer, for the 
> entire test. If you separate the consumer and producer into separate 
> processes the test fails.
> The test code is found in file csharp_api/DurableTest.cs



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

[jira] [Commented] (AMQNET-459) Dot Net platform - invalid durable queue test case, durable queue does not work

[Jim Dandy (JIRA)]

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

Jim Dandy commented on AMQNET-459:
--

I have Apache.NMS.ActiveMQ-1.4.1-bin.zip

> Dot Net platform - invalid durable queue test case, durable queue does not 
> work
> ---
>
> Key: AMQNET-459
> URL: https://issues.apache.org/jira/browse/AMQNET-459
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Reporter: Jim Dandy
>Priority: Minor
> Attachments: DurableTest.cs
>
>
> I've been having difficulty getting durable consumers working with ActiveMQ 
> in a C# and Windows environment (works fine in Java).
> So I looked at the test case and was surprised to see the test uses the same 
> connection and session to run both the consumer and the producer, for the 
> entire test. If you separate the consumer and producer into separate 
> processes the test fails.
> The test code is found in file csharp_api/DurableTest.cs



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

[jira] [Commented] (AMQNET-459) Dot Net platform - invalid durable queue test case, durable queue does not work

[Jim Dandy (JIRA)]

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

Jim Dandy commented on AMQNET-459:
--

I didn't make any changes to the test; perhaps I need a newer version. Will 
have to see if a newer version shares a session or not, still believe the test 
use separate threads/processes.

> Dot Net platform - invalid durable queue test case, durable queue does not 
> work
> ---
>
> Key: AMQNET-459
> URL: https://issues.apache.org/jira/browse/AMQNET-459
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Reporter: Jim Dandy
>Priority: Minor
> Attachments: DurableTest.cs
>
>
> I've been having difficulty getting durable consumers working with ActiveMQ 
> in a C# and Windows environment (works fine in Java).
> So I looked at the test case and was surprised to see the test uses the same 
> connection and session to run both the consumer and the producer, for the 
> entire test. If you separate the consumer and producer into separate 
> processes the test fails.
> The test code is found in file csharp_api/DurableTest.cs



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

Outdated documentation on the site

[Hadrian Zbarcea]

Hi,

Some of documentation in the wiki is extremely outdated, like the 
getting started guide [1]. I don't think anybody is using AMQ 4.x for 
instance. I'll go through the whole site and update as much as I can in 
the coming days. Any objections?


Hadrian

[1] http://activemq.apache.org/getting-started.html


--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Illegal Host Name; Problem starting up activemq 5.9.0

[jephperro]

Hi I'm trying to upgrade our ActiveMQ 5.4 instance to version 5.9.

But right out of the box, I've hit a problem.  The linux server ApacheMQ is
running on has a name with an underscore in it, and that's preventing MQ
from starting.


2013-11-14 13:53:24,689 | INFO  | Connector mqtt started |
org.apache.activemq.broker.TransportConnector | main
2013-11-14 13:53:24,786 | ERROR | Failed to start Apache ActiveMQ
([localhost, ID:cms_delta.mycompany.com-49872-1384466004457-0:1],
java.net.URISyntaxException: Illegal character in hostname at index 8:
ws://cms_delta.mycompany.com:61614?maximumConnections=1000&wireFormat.maxFrameSize=104857600)
| org.apache.activemq.broker.BrokerService | main



Is there somewhere I can set the name of the server ?  The server does have
other aliases that I could use instead if I knew where to set it.

Thanks



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Illegal-Host-Name-Problem-starting-up-activemq-5-9-0-tp4674502.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

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

[Matt Smith (JIRA)]

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

Matt Smith commented on AMQ-4828:
-

I've run into the same issue. Is there a view in hawtio console that is 
equivalent to the old connections tab?

> Bug in web console
> --
>
> Key: AMQ-4828
> URL: https://issues.apache.org/jira/browse/AMQ-4828
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: webconsole
>Affects Versions: 5.9.0
> Environment: Karaf 2.3.3, Java 1.6.0.45 x64, Windows 7 Pro x64 
>Reporter: brat
>Priority: Minor
>  Labels: web-console
> Attachments: error.txt
>
>
> I think I discovered a bug in activemq-web-console under karaf (not sure
> if it exists in the standalone amq).
> When you try to open http://localhost:8181/activemqweb/connections.jsp it will
> show "Error!" and "Exception occurred while processing this request, check 
> the log for more information!".
> Stack trace attached. Seems like networkTTL property cannot be found for some 
> reason?



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

Re: Cutting a 5.9.1 release

[Robert Davies]

sounds good - there’s some compliance issues with MQTT - I see if I can squeeze 
those in.

On 14 Nov 2013, at 15:29, Hiram Chirino  wrote:

> So what do you guys think about doing a quick 5.9.1 release.  There
> were some big bugs in the 5.9.0 release that have now been fixed and
> perhaps we should cut a release now before any major changes make
> their way into trunk?
> 
> What do ya guys think?
> 
> 
> -- 
> Hiram Chirino
> 
> Engineering | Red Hat, Inc.
> 
> hchir...@redhat.com | fusesource.com | redhat.com
> 
> skype: hiramchirino | twitter: @hiramchirino
> 
> blog: Hiram Chirino's Bit Mojo

Rob Davies
-
Red Hat, Inc
Twitter: rajdavies
Blog: http://rajdavies.blogspot.com
ActiveMQ in Action: http://www.manning.com/snyder/

Re: Cutting a 5.9.1 release

[Jean-Baptiste Onofré]

FYI, about Karaf/OSGi integration, I have the following patches to submit:
- instead of depending to the jetty feature, ActiveMQ feature should 
depend to the http feature. It will allow to easily migrate to Karaf 3.0.0.
- extends the ActiveMQ Karaf commands package import version range to 
support Karaf 3.0.0

- some fixes in the features and metadata

I will create the Jira and submit the patches tomorrow.

Regards
JB

On 11/14/2013 04:29 PM, Hiram Chirino wrote:

So what do you guys think about doing a quick 5.9.1 release.  There
were some big bugs in the 5.9.0 release that have now been fixed and
perhaps we should cut a release now before any major changes make
their way into trunk?

What do ya guys think?




--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[jira] [Resolved] (AMQNET-460) WaitForRedeliveries ignores failoverRedeliveryWaitPeriod

[Timothy Bish (JIRA)]

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

Timothy Bish resolved AMQNET-460.
-

   Resolution: Fixed
Fix Version/s: 1.7.0
   1.6.1
 Assignee: Timothy Bish  (was: Jim Gomes)

> WaitForRedeliveries ignores failoverRedeliveryWaitPeriod
> 
>
> Key: AMQNET-460
> URL: https://issues.apache.org/jira/browse/AMQNET-460
> Project: ActiveMQ .Net
>  Issue Type: Bug
>Affects Versions: 1.6.0
>Reporter: Remo Gloor
>Assignee: Timothy Bish
> Fix For: 1.6.1, 1.7.0
>
>
> MessageConsumer.WaitForRedeliveries() 
> while (numberNotReplayed > 0 && expiry < DateTime.Now);
> should be
> while (numberNotReplayed > 0 && expiry > DateTime.Now);



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

Re: Cutting a 5.9.1 release

[Christian Posta]

+1 .. let's do it

On Thu, Nov 14, 2013 at 7:59 AM, Timothy Bish  wrote:
> On 11/14/2013 10:29 AM, Hiram Chirino wrote:
>>
>> So what do you guys think about doing a quick 5.9.1 release.  There
>> were some big bugs in the 5.9.0 release that have now been fixed and
>> perhaps we should cut a release now before any major changes make
>> their way into trunk?
>>
>> What do ya guys think?
>>
>>
> +1  there's some good fixes in there that could help a lot of users.
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.b...@redhat.com | www.fusesource.com | www.redhat.com
> skype: tabish121 | twitter: @tabish121
> blog: http://timbish.blogspot.com/
>



-- 
Christian Posta
http://www.christianposta.com/blog
twitter: @christianposta

[jira] [Resolved] (AMQNET-463) previouslyDeliveredMessages.Add() does not change value

[Timothy Bish (JIRA)]

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

Timothy Bish resolved AMQNET-463.
-

   Resolution: Fixed
Fix Version/s: 1.7.0
   1.6.1
 Assignee: Timothy Bish  (was: Jim Gomes)

Fix applied on trunk and 1.6.x

> previouslyDeliveredMessages.Add() does not change value
> ---
>
> Key: AMQNET-463
> URL: https://issues.apache.org/jira/browse/AMQNET-463
> Project: ActiveMQ .Net
>  Issue Type: Bug
>Reporter: Remo Gloor
>Assignee: Timothy Bish
> Fix For: 1.6.1, 1.7.0
>
>
> MessageConsumer uses previouslyDeliveredMessages.Add()
> When the value exists it won't change that value. Hence the whole algorithm 
> based on previouslyDeliveredMessages won't work atm.
> Use assignment instead
> previouslyDeliveredMessages[messageId] = X;



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

Re: Cutting a 5.9.1 release

[Timothy Bish]

On 11/14/2013 10:29 AM, Hiram Chirino wrote:

So what do you guys think about doing a quick 5.9.1 release.  There
were some big bugs in the 5.9.0 release that have now been fixed and
perhaps we should cut a release now before any major changes make
their way into trunk?

What do ya guys think?



+1  there's some good fixes in there that could help a lot of users.

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

Re: Cutting a 5.9.1 release

[Jean-Baptiste Onofré]

+1 for the Apache branding in hawt.io as well.

Regards
JB

On 11/14/2013 04:45 PM, Dejan Bosanac wrote:

+1 as well. It'd be good to do an apache branding for hawtio as well. I'd
hope I can jump to that in the next couple of days.

Regards
--
Dejan Bosanac
--
Red Hat, Inc.
FuseSource is now part of Red Hat
dbosa...@redhat.com
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/


On Thu, Nov 14, 2013 at 4:33 PM, Jean-Baptiste Onofré wrote:


Hi Hiram,

I'm fully agree.

I have some fix about OSGi and Karaf integration as well (preparing the
support of Karaf 3). I can commit that tomorrow.

Regards
JB


On 11/14/2013 04:29 PM, Hiram Chirino wrote:


So what do you guys think about doing a quick 5.9.1 release.  There
were some big bugs in the 5.9.0 release that have now been fixed and
perhaps we should cut a release now before any major changes make
their way into trunk?

What do ya guys think?




--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com





--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [ISSUE] - bin/activemq.bat for Windows users

[Dejan Bosanac]

I agree. Putting too much in the activemq unix start script was an
oversight and led to some bugs and inconsistencies we could have avoided.

Regards
--
Dejan Bosanac
--
Red Hat, Inc.
FuseSource is now part of Red Hat
dbosa...@redhat.com
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/


On Thu, Nov 14, 2013 at 4:38 PM, Hiram Chirino wrote:

> I kinda wish that both activemq unix script and activemq were simple
> start activemq in the foreground scripts.  Starting activemq as a
> service/background is different on Windows and Linux/Unix so that
> should done using other extra files etc.
>
> For example we could have a bin/activemq-service script for unix that
> handles doing the init.d unix stuff: 'activemq-service start'
> 'activemq-service stop' etc.
>
> On Wed, Nov 13, 2013 at 8:57 AM, Claus Ibsen 
> wrote:
> > Thanks
> >
> > So I assume it would be okay to remove the start from the
> > activemq.bat, and have Windows users start the broker as we do unix.
> >
> >
> >
> > On Wed, Nov 13, 2013 at 1:47 PM, Gary Tully 
> wrote:
> >> I think part of the reason is that only the unix scripts got an update
> >> via https://issues.apache.org/jira/browse/AMQ-2453
> >>
> >> consistency is good and simpler from a doc perspective.
> >>
> >> On 13 November 2013 12:21, Claus Ibsen  wrote:
> >>> Hi
> >>>
> >>> I was looking at ticket
> >>> https://issues.apache.org/jira/browse/AMQ-3101
> >>>
> >>>
> >>> I wonder why starting ActiveMQ on windows and unix is different,
> according to
> >>>
> http://activemq.apache.org/version-5-getting-started.html#Version5GettingStarted-StartingActiveMQ
> >>>
> >>> On windows we tell users to do
> >>>bin\activemq
> >>>
> >>> And on unix
> >>>bin/activemq start
> >>>
> >>> eg on unix you pass in the start command.
> >>>
> >>> I would prefer that on Windows you should pass on the command as well
> such as
> >>>bin\activemq start
> >>>
> >>> Otherwise you cannot get the help syntax by just using bin/activemq
> >>>
> >>> Usage: Main [--extdir ] [task] [task-options] [task data]
> >>>
> >>> Tasks:
> >>> browse   - Display selected messages in a
> >>> specified destination.
> >>> bstat- Performs a predefined query that
> >>> displays useful statistics regarding the specified broker
> >>> create   - Creates a runnable broker instance in
> >>> the specified path.
> >>> decrypt  - Decrypts given text
> >>> dstat- Performs a predefined query that
> >>> displays useful tabular statistics regarding the specified destination
> >>> type
> >>> encrypt  - Encrypts given text
> >>> export   - Exports a stopped brokers data files to
> >>> an archive file
> >>> list - Lists all available brokers in the
> >>> specified JMX context
> >>> purge- Delete selected destination's messages
> >>> that matches the message selector
> >>> query- Display selected broker component's
> >>> attributes and statistics.
> >>> start- Creates and starts a broker using a
> >>> configuration file, or a broker URI.
> >>> stop - Stops a running broker specified by the
> >>> broker name.
> >>>
> >>>
> >>> So I would if we should change this for Windows in the activemq.bat
> >>> file, to not have the "start" command in there. So its consistent with
> >>> unix.
> >>>
> >>> And also fixes AMQ-3101
> >>>
> >>>
> >>> Anyone know any reason about the "start" in the bin/activemq.bat file?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> 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
> >>
> >>
> >>
> >> --
> >> http://redhat.com
> >> http://blog.garytully.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
>
>
>
> --
> Hiram Chirino
>
> Engineering | Red Hat, Inc.
>
> hchir...@redhat.com | fusesource.com | redhat.com
>
> skype: hiramchirino | twitter: @hiramchirino
>
> blog: Hiram Chirino's Bit Mojo
>

Re: Cutting a 5.9.1 release

[Dejan Bosanac]

+1 as well. It'd be good to do an apache branding for hawtio as well. I'd
hope I can jump to that in the next couple of days.

Regards
--
Dejan Bosanac
--
Red Hat, Inc.
FuseSource is now part of Red Hat
dbosa...@redhat.com
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/


On Thu, Nov 14, 2013 at 4:33 PM, Jean-Baptiste Onofré wrote:

> Hi Hiram,
>
> I'm fully agree.
>
> I have some fix about OSGi and Karaf integration as well (preparing the
> support of Karaf 3). I can commit that tomorrow.
>
> Regards
> JB
>
>
> On 11/14/2013 04:29 PM, Hiram Chirino wrote:
>
>> So what do you guys think about doing a quick 5.9.1 release.  There
>> were some big bugs in the 5.9.0 release that have now been fixed and
>> perhaps we should cut a release now before any major changes make
>> their way into trunk?
>>
>> What do ya guys think?
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Cutting a 5.9.1 release

[Jean-Baptiste Onofré]

Hi Hiram,

I'm fully agree.

I have some fix about OSGi and Karaf integration as well (preparing the 
support of Karaf 3). I can commit that tomorrow.


Regards
JB

On 11/14/2013 04:29 PM, Hiram Chirino wrote:

So what do you guys think about doing a quick 5.9.1 release.  There
were some big bugs in the 5.9.0 release that have now been fixed and
perhaps we should cut a release now before any major changes make
their way into trunk?

What do ya guys think?




--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [ISSUE] - bin/activemq.bat for Windows users

[Hiram Chirino]

I kinda wish that both activemq unix script and activemq were simple
start activemq in the foreground scripts.  Starting activemq as a
service/background is different on Windows and Linux/Unix so that
should done using other extra files etc.

For example we could have a bin/activemq-service script for unix that
handles doing the init.d unix stuff: 'activemq-service start'
'activemq-service stop' etc.

On Wed, Nov 13, 2013 at 8:57 AM, Claus Ibsen  wrote:
> Thanks
>
> So I assume it would be okay to remove the start from the
> activemq.bat, and have Windows users start the broker as we do unix.
>
>
>
> On Wed, Nov 13, 2013 at 1:47 PM, Gary Tully  wrote:
>> I think part of the reason is that only the unix scripts got an update
>> via https://issues.apache.org/jira/browse/AMQ-2453
>>
>> consistency is good and simpler from a doc perspective.
>>
>> On 13 November 2013 12:21, Claus Ibsen  wrote:
>>> Hi
>>>
>>> I was looking at ticket
>>> https://issues.apache.org/jira/browse/AMQ-3101
>>>
>>>
>>> I wonder why starting ActiveMQ on windows and unix is different, according 
>>> to
>>> http://activemq.apache.org/version-5-getting-started.html#Version5GettingStarted-StartingActiveMQ
>>>
>>> On windows we tell users to do
>>>bin\activemq
>>>
>>> And on unix
>>>bin/activemq start
>>>
>>> eg on unix you pass in the start command.
>>>
>>> I would prefer that on Windows you should pass on the command as well such 
>>> as
>>>bin\activemq start
>>>
>>> Otherwise you cannot get the help syntax by just using bin/activemq
>>>
>>> Usage: Main [--extdir ] [task] [task-options] [task data]
>>>
>>> Tasks:
>>> browse   - Display selected messages in a
>>> specified destination.
>>> bstat- Performs a predefined query that
>>> displays useful statistics regarding the specified broker
>>> create   - Creates a runnable broker instance in
>>> the specified path.
>>> decrypt  - Decrypts given text
>>> dstat- Performs a predefined query that
>>> displays useful tabular statistics regarding the specified destination
>>> type
>>> encrypt  - Encrypts given text
>>> export   - Exports a stopped brokers data files to
>>> an archive file
>>> list - Lists all available brokers in the
>>> specified JMX context
>>> purge- Delete selected destination's messages
>>> that matches the message selector
>>> query- Display selected broker component's
>>> attributes and statistics.
>>> start- Creates and starts a broker using a
>>> configuration file, or a broker URI.
>>> stop - Stops a running broker specified by the
>>> broker name.
>>>
>>>
>>> So I would if we should change this for Windows in the activemq.bat
>>> file, to not have the "start" command in there. So its consistent with
>>> unix.
>>>
>>> And also fixes AMQ-3101
>>>
>>>
>>> Anyone know any reason about the "start" in the bin/activemq.bat file?
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>>
>>
>> --
>> http://redhat.com
>> http://blog.garytully.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



-- 
Hiram Chirino

Engineering | Red Hat, Inc.

hchir...@redhat.com | fusesource.com | redhat.com

skype: hiramchirino | twitter: @hiramchirino

blog: Hiram Chirino's Bit Mojo

Cutting a 5.9.1 release

[Hiram Chirino]

So what do you guys think about doing a quick 5.9.1 release.  There
were some big bugs in the 5.9.0 release that have now been fixed and
perhaps we should cut a release now before any major changes make
their way into trunk?

What do ya guys think?


-- 
Hiram Chirino

Engineering | Red Hat, Inc.

hchir...@redhat.com | fusesource.com | redhat.com

skype: hiramchirino | twitter: @hiramchirino

blog: Hiram Chirino's Bit Mojo

[jira] [Assigned] (AMQ-4886) AMQ2149LevelDBTest hangs or fails frequently

[Kevin Earls (JIRA)]

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

Kevin Earls reassigned AMQ-4886:


Assignee: Kevin Earls

> AMQ2149LevelDBTest hangs or fails frequently
> 
>
> Key: AMQ-4886
> URL: https://issues.apache.org/jira/browse/AMQ-4886
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: Kevin Earls
>Assignee: Kevin Earls
> Attachments: AMQ2149LevelDBTest.stack
>
>
> I'll update this as I get more information, but this test suite has multiple 
> cases that hang and timeout frequently 
> (testTopicTransactionalOrderWithRestart and testTopicOrderWithRestart seem to 
> do so most frequently.)  
> It can also hang in tearDown, which causes the whole suite to hang without 
> timing out, which can be a problem when run under Hudson or Jenkins.  
> I will  attach a stack trace of the tearDown hang, and also update 
> AMQ2149Test to prevent this.  I'm also going to update the test to use JUnit4 
> and reduce the timeouts from 30 to 5 minutes.



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

[jira] [Updated] (AMQ-4886) AMQ2149LevelDBTest hangs or fails frequently

[Kevin Earls (JIRA)]

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

Kevin Earls updated AMQ-4886:
-

Attachment: AMQ2149LevelDBTest.stack

> AMQ2149LevelDBTest hangs or fails frequently
> 
>
> Key: AMQ-4886
> URL: https://issues.apache.org/jira/browse/AMQ-4886
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: Kevin Earls
> Attachments: AMQ2149LevelDBTest.stack
>
>
> I'll update this as I get more information, but this test suite has multiple 
> cases that hang and timeout frequently 
> (testTopicTransactionalOrderWithRestart and testTopicOrderWithRestart seem to 
> do so most frequently.)  
> It can also hang in tearDown, which causes the whole suite to hang without 
> timing out, which can be a problem when run under Hudson or Jenkins.  
> I will  attach a stack trace of the tearDown hang, and also update 
> AMQ2149Test to prevent this.  I'm also going to update the test to use JUnit4 
> and reduce the timeouts from 30 to 5 minutes.



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

[jira] [Updated] (AMQ-2210) Infinite loop: WARN PrefetchSubscription - Ack before disaptch, waiting for recovery dispatch: MessageAck

[Kevin Earls (JIRA)]

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

Kevin Earls updated AMQ-2210:
-

Attachment: (was: AMQ2149LevelDBTest.stack)

> Infinite loop: WARN  PrefetchSubscription   - Ack before disaptch, 
> waiting for recovery dispatch: MessageAck
> 
>
> Key: AMQ-2210
> URL: https://issues.apache.org/jira/browse/AMQ-2210
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.2.0
> Environment: solaris 10 trunk version 764403
>Reporter: ying
>Assignee: Gary Tully
>Priority: Blocker
> Fix For: 5.3.0
>
>
> Reproduce steps:
> 1. setup 4 network of brokers with multicast discovery
> 2. start client consumers and producers
> 3. let the producer produce message constantly
> 4. in jconsole, stop() the broker the consumers are connecting to
> 5. after the consumers failover to another broker, the newly connected broker 
> will get into an infinite loop:
> WARN  PrefetchSubscription   - Ack before disaptch, waiting for 
> recovery dispatch: MessageAck {commandId = 1232, responseRequired = true, 
> ackType = 2, consumerId = ID:host01-39430-1239887122787-0:0:2:1, 
> firstMessageId = ID:host01-39430-1239887122787-0:0:87:1:5, lastMessageId = 
> ID:host01-39430-1239887122787-0:0:87:1:5, destination = 
> queue://Consumer.A-host01-1527-1239887124983.VirtualTopic.B, transactionId = 
> TX:ID:host01-39430-1239887122787-0:0:38, messageCount = 1}
> This broker will stop functioning and consumer is not processing messages. 



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

[jira] [Created] (AMQ-4886) AMQ2149LevelDBTest hangs or fails frequently

[Kevin Earls (JIRA)]

Kevin Earls created AMQ-4886:


 Summary: AMQ2149LevelDBTest hangs or fails frequently
 Key: AMQ-4886
 URL: https://issues.apache.org/jira/browse/AMQ-4886
 Project: ActiveMQ
  Issue Type: Bug
Reporter: Kevin Earls


I'll update this as I get more information, but this test suite has multiple 
cases that hang and timeout frequently (testTopicTransactionalOrderWithRestart 
and testTopicOrderWithRestart seem to do so most frequently.)  

It can also hang in tearDown, which causes the whole suite to hang without 
timing out, which can be a problem when run under Hudson or Jenkins.  

I will  attach a stack trace of the tearDown hang, and also update AMQ2149Test 
to prevent this.  I'm also going to update the test to use JUnit4 and reduce 
the timeouts from 30 to 5 minutes.




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

[jira] [Updated] (AMQ-2210) Infinite loop: WARN PrefetchSubscription - Ack before disaptch, waiting for recovery dispatch: MessageAck

[Kevin Earls (JIRA)]

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

Kevin Earls updated AMQ-2210:
-

Attachment: AMQ2149LevelDBTest.stack

> Infinite loop: WARN  PrefetchSubscription   - Ack before disaptch, 
> waiting for recovery dispatch: MessageAck
> 
>
> Key: AMQ-2210
> URL: https://issues.apache.org/jira/browse/AMQ-2210
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.2.0
> Environment: solaris 10 trunk version 764403
>Reporter: ying
>Assignee: Gary Tully
>Priority: Blocker
> Fix For: 5.3.0
>
> Attachments: AMQ2149LevelDBTest.stack
>
>
> Reproduce steps:
> 1. setup 4 network of brokers with multicast discovery
> 2. start client consumers and producers
> 3. let the producer produce message constantly
> 4. in jconsole, stop() the broker the consumers are connecting to
> 5. after the consumers failover to another broker, the newly connected broker 
> will get into an infinite loop:
> WARN  PrefetchSubscription   - Ack before disaptch, waiting for 
> recovery dispatch: MessageAck {commandId = 1232, responseRequired = true, 
> ackType = 2, consumerId = ID:host01-39430-1239887122787-0:0:2:1, 
> firstMessageId = ID:host01-39430-1239887122787-0:0:87:1:5, lastMessageId = 
> ID:host01-39430-1239887122787-0:0:87:1:5, destination = 
> queue://Consumer.A-host01-1527-1239887124983.VirtualTopic.B, transactionId = 
> TX:ID:host01-39430-1239887122787-0:0:38, messageCount = 1}
> This broker will stop functioning and consumer is not processing messages. 



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

[jira] [Comment Edited] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)

[Remo Gloor (JIRA)]

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

Remo Gloor edited comment on AMQNET-462 at 11/14/13 2:36 PM:
-

My unittest and fixes for this problem rely other patches that are not applied 
since 9 months. I won't spend the time to reduce them to the current trunks 
version and separate the various problems from each other into small patches 
because I have the feeling that my help isn't really apprechiated and there is 
little to know guarantee that such patches will be applied anyway. So it's just 
waste of time. This is just to tell you that you have a problem. I fixed this 
and various other problems related to the new failover implementation for 
myself already.

Applying patches that are open for 9 months would be a good start to work 
together from your side.


was (Author: remogloor):
My unittest and fixes for this problem rely other patches that are not applied 
since 9 months. I won't spend the time to reduce them to the current trunks 
version and separate the various problems from each other into small patches 
because I have the feeling that my help isn't really apprechiated and there is 
little to know guarantee that such patches will be applied anyway. So it's just 
waste of time. This is just to tell you that you have a problem. I fixed it for 
myself already.

Applying patches that are open for 9 months would be a good start to work 
together from your side.

> Failover transport: Deduplication algorithm is wrong (1)
> 
>
> Key: AMQNET-462
> URL: https://issues.apache.org/jira/browse/AMQNET-462
> Project: ActiveMQ .Net
>  Issue Type: Bug
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>
> 1. Create and start consumer
> 2. Messages are delivered and queued in unconsumed messages
> 3. Listener is added
> 4. Messages are Redispatched
> 5. Messages are considered duplicates
> Succestion:
> Have a cleare state of messages in the unconsumed messages. Either they 
> should be in the connections duplicate list or not.
> If they are in the in the dup list. then rollback dup whenever a message is 
> redispatched.
> If not check dup before deliver to message to the client. (Receive/Deliver to 
> Listener)
> This makes it much easier to get a correct code then currently where 
> unconsumed messages can either be in the dup list or not.



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

[jira] [Commented] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)

[Remo Gloor (JIRA)]

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

Remo Gloor commented on AMQNET-462:
---

My unittest and fixes for this problem rely other patches that are not applied 
since 9 months. I won't spend the time to reduce them to the current trunks 
version and separate the various problems from each other into small patches 
because I have the feeling that my help isn't really apprechiated and there is 
little to know guarantee that such patches will be applied anyway. So it's just 
waste of time. This is just to tell you that you have a problem. I fixed it for 
myself already.

Applying patches that are open for 9 months would be a good start to work 
together from your side.

> Failover transport: Deduplication algorithm is wrong (1)
> 
>
> Key: AMQNET-462
> URL: https://issues.apache.org/jira/browse/AMQNET-462
> Project: ActiveMQ .Net
>  Issue Type: Bug
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>
> 1. Create and start consumer
> 2. Messages are delivered and queued in unconsumed messages
> 3. Listener is added
> 4. Messages are Redispatched
> 5. Messages are considered duplicates
> Succestion:
> Have a cleare state of messages in the unconsumed messages. Either they 
> should be in the connections duplicate list or not.
> If they are in the in the dup list. then rollback dup whenever a message is 
> redispatched.
> If not check dup before deliver to message to the client. (Receive/Deliver to 
> Listener)
> This makes it much easier to get a correct code then currently where 
> unconsumed messages can either be in the dup list or not.



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

[jira] [Commented] (AMQNET-461) FailoverTransport PoisonAcks Rollbacked messages

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQNET-461:
-

Do you have a test case?

> FailoverTransport PoisonAcks Rollbacked messages
> 
>
> Key: AMQNET-461
> URL: https://issues.apache.org/jira/browse/AMQNET-461
> Project: ActiveMQ .Net
>  Issue Type: Bug
>Affects Versions: 1.6.0
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>
> When using FailoverTransport with nonBlockingRedelivery messages get 
> PoisonAcked:
> 1. Message is rolledback e.g. due to a concurrency exception on the db or any 
> other processing error.
> 2. Message is sheduled for redelivery e.g. in 30 Sec.
> 3. Connection is lost before message is redelivered
> 4. Connection is reestablished before message is redelivered.
> 5. Server redelivers message due to the connection loss
> 6. Message is dsipatched and processed.
> 7. Resheduled Message gets dispatched => Duplicate
> 8. No previously delivered messages => Send PoisonAck => Message is in the 
> DLQ even though it is processed succesfully.



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

[jira] [Commented] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQNET-462:
-

A unit test for this would be a good start.

> Failover transport: Deduplication algorithm is wrong (1)
> 
>
> Key: AMQNET-462
> URL: https://issues.apache.org/jira/browse/AMQNET-462
> Project: ActiveMQ .Net
>  Issue Type: Bug
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>
> 1. Create and start consumer
> 2. Messages are delivered and queued in unconsumed messages
> 3. Listener is added
> 4. Messages are Redispatched
> 5. Messages are considered duplicates
> Succestion:
> Have a cleare state of messages in the unconsumed messages. Either they 
> should be in the connections duplicate list or not.
> If they are in the in the dup list. then rollback dup whenever a message is 
> redispatched.
> If not check dup before deliver to message to the client. (Receive/Deliver to 
> Listener)
> This makes it much easier to get a correct code then currently where 
> unconsumed messages can either be in the dup list or not.



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

[jira] [Closed] (AMQNET-459) Dot Net platform - invalid durable queue test case, durable queue does not work

[Timothy Bish (JIRA)]

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

Timothy Bish closed AMQNET-459.
---

Resolution: Cannot Reproduce

> Dot Net platform - invalid durable queue test case, durable queue does not 
> work
> ---
>
> Key: AMQNET-459
> URL: https://issues.apache.org/jira/browse/AMQNET-459
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: ActiveMQ
>Reporter: Jim Dandy
>Priority: Minor
> Attachments: DurableTest.cs
>
>
> I've been having difficulty getting durable consumers working with ActiveMQ 
> in a C# and Windows environment (works fine in Java).
> So I looked at the test case and was surprised to see the test uses the same 
> connection and session to run both the consumer and the producer, for the 
> entire test. If you separate the consumer and producer into separate 
> processes the test fails.
> The test code is found in file csharp_api/DurableTest.cs



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

[jira] [Updated] (AMQ-4712) MQTT unit tests fail

[Kevin Earls (JIRA)]

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

Kevin Earls updated AMQ-4712:
-

Attachment: MQTTTest.testSendMQTTReceiveJMS.stack

> MQTT unit tests fail
> 
>
> Key: AMQ-4712
> URL: https://issues.apache.org/jira/browse/AMQ-4712
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT, Test Cases
>Affects Versions: 5.9.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Rob Davies
> Fix For: 5.10.0
>
> Attachments: MQTTTest.testSendMQTTReceiveJMS.stack
>
>
> Running org.apache.activemq.transport.mqtt.MQTTNioTest
> Tests run: 19, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 160.808 sec 
> <<< FAILURE!
> Running org.apache.activemq.transport.mqtt.MQTTSSLTest
> Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 161.426 sec 
> <<< FAILURE!
> Running org.apache.activemq.transport.mqtt.MQTTTest
> Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 158.184 sec 
> <<< FAILURE!
> Results :
> Tests in error:
>   testPingOnMQTTNIO(org.apache.activemq.transport.mqtt.MQTTNioTest): The 
> client id MUST be configured when clean session is set to false
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTNioTest):
>  String index out of range: -6
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTSSLTest):
>  Command from server contained an invalid message id: 1
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTTest):
>  Command from server contained an invalid message id: 1
> Tests run: 55, Failures: 0, Errors: 4, Skipped: 0



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

[jira] [Commented] (AMQ-4712) MQTT unit tests fail

[Kevin Earls (JIRA)]

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

Kevin Earls commented on AMQ-4712:
--

I just saw a case where testSendMQTTReceiveJMS hung on one of the CI boxes.  
I'll attach a stack trace.


> MQTT unit tests fail
> 
>
> Key: AMQ-4712
> URL: https://issues.apache.org/jira/browse/AMQ-4712
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT, Test Cases
>Affects Versions: 5.9.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Rob Davies
> Fix For: 5.10.0
>
> Attachments: MQTTTest.testSendMQTTReceiveJMS.stack
>
>
> Running org.apache.activemq.transport.mqtt.MQTTNioTest
> Tests run: 19, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 160.808 sec 
> <<< FAILURE!
> Running org.apache.activemq.transport.mqtt.MQTTSSLTest
> Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 161.426 sec 
> <<< FAILURE!
> Running org.apache.activemq.transport.mqtt.MQTTTest
> Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 158.184 sec 
> <<< FAILURE!
> Results :
> Tests in error:
>   testPingOnMQTTNIO(org.apache.activemq.transport.mqtt.MQTTNioTest): The 
> client id MUST be configured when clean session is set to false
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTNioTest):
>  String index out of range: -6
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTSSLTest):
>  Command from server contained an invalid message id: 1
>   
> testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTTest):
>  Command from server contained an invalid message id: 1
> Tests run: 55, Failures: 0, Errors: 4, Skipped: 0



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

[jira] [Created] (AMQNET-463) previouslyDeliveredMessages.Add() does not change value

[Remo Gloor (JIRA)]

Remo Gloor created AMQNET-463:
-

 Summary: previouslyDeliveredMessages.Add() does not change value
 Key: AMQNET-463
 URL: https://issues.apache.org/jira/browse/AMQNET-463
 Project: ActiveMQ .Net
  Issue Type: Bug
Reporter: Remo Gloor
Assignee: Jim Gomes


MessageConsumer uses previouslyDeliveredMessages.Add()

When the value exists it won't change that value. Hence the whole algorithm 
based on previouslyDeliveredMessages won't work atm.

Use assignment instead
previouslyDeliveredMessages[messageId] = X;



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

[jira] [Updated] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)

[Remo Gloor (JIRA)]

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

Remo Gloor updated AMQNET-462:
--

Description: 
1. Create and start consumer
2. Messages are delivered and queued in unconsumed messages
3. Listener is added
4. Messages are Redispatched
5. Messages are considered duplicates


Succestion:
Have a cleare state of messages in the unconsumed messages. Either they should 
be in the connections dupplicate list or not.
If they are in the in the dup list. then rollback dup whenever a message is 
redispatched.
If not check dup before deliver to message to the client. (Receive/Deliver to 
Listener)
This makes it much easier to get a correct code then currently where unconsumed 
messages can either be in the dup list or not.

  was:
1. Create and start consumer
2. Messages are delivered and queued in unconsumed messages
3. Listener is added
4. Messages are Redispatched
5. Messages are considered duplicates


> Failover transport: Deduplication algorithm is wrong (1)
> 
>
> Key: AMQNET-462
> URL: https://issues.apache.org/jira/browse/AMQNET-462
> Project: ActiveMQ .Net
>  Issue Type: Bug
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>
> 1. Create and start consumer
> 2. Messages are delivered and queued in unconsumed messages
> 3. Listener is added
> 4. Messages are Redispatched
> 5. Messages are considered duplicates
> Succestion:
> Have a cleare state of messages in the unconsumed messages. Either they 
> should be in the connections dupplicate list or not.
> If they are in the in the dup list. then rollback dup whenever a message is 
> redispatched.
> If not check dup before deliver to message to the client. (Receive/Deliver to 
> Listener)
> This makes it much easier to get a correct code then currently where 
> unconsumed messages can either be in the dup list or not.



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

[jira] [Updated] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)

[Remo Gloor (JIRA)]

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

Remo Gloor updated AMQNET-462:
--

Description: 
1. Create and start consumer
2. Messages are delivered and queued in unconsumed messages
3. Listener is added
4. Messages are Redispatched
5. Messages are considered duplicates


Succestion:
Have a cleare state of messages in the unconsumed messages. Either they should 
be in the connections duplicate list or not.
If they are in the in the dup list. then rollback dup whenever a message is 
redispatched.
If not check dup before deliver to message to the client. (Receive/Deliver to 
Listener)
This makes it much easier to get a correct code then currently where unconsumed 
messages can either be in the dup list or not.

  was:
1. Create and start consumer
2. Messages are delivered and queued in unconsumed messages
3. Listener is added
4. Messages are Redispatched
5. Messages are considered duplicates


Succestion:
Have a cleare state of messages in the unconsumed messages. Either they should 
be in the connections dupplicate list or not.
If they are in the in the dup list. then rollback dup whenever a message is 
redispatched.
If not check dup before deliver to message to the client. (Receive/Deliver to 
Listener)
This makes it much easier to get a correct code then currently where unconsumed 
messages can either be in the dup list or not.


> Failover transport: Deduplication algorithm is wrong (1)
> 
>
> Key: AMQNET-462
> URL: https://issues.apache.org/jira/browse/AMQNET-462
> Project: ActiveMQ .Net
>  Issue Type: Bug
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>
> 1. Create and start consumer
> 2. Messages are delivered and queued in unconsumed messages
> 3. Listener is added
> 4. Messages are Redispatched
> 5. Messages are considered duplicates
> Succestion:
> Have a cleare state of messages in the unconsumed messages. Either they 
> should be in the connections duplicate list or not.
> If they are in the in the dup list. then rollback dup whenever a message is 
> redispatched.
> If not check dup before deliver to message to the client. (Receive/Deliver to 
> Listener)
> This makes it much easier to get a correct code then currently where 
> unconsumed messages can either be in the dup list or not.



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

[jira] [Created] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)

[Remo Gloor (JIRA)]

Remo Gloor created AMQNET-462:
-

 Summary: Failover transport: Deduplication algorithm is wrong (1)
 Key: AMQNET-462
 URL: https://issues.apache.org/jira/browse/AMQNET-462
 Project: ActiveMQ .Net
  Issue Type: Bug
Reporter: Remo Gloor
Assignee: Jim Gomes


1. Create and start consumer
2. Messages are delivered and queued in unconsumed messages
3. Listener is added
4. Messages are Redispatched
5. Messages are considered duplicates



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

[jira] [Created] (AMQNET-461) FailoverTransport PoisonAcks Rollbacked messages

[Remo Gloor (JIRA)]

Remo Gloor created AMQNET-461:
-

 Summary: FailoverTransport PoisonAcks Rollbacked messages
 Key: AMQNET-461
 URL: https://issues.apache.org/jira/browse/AMQNET-461
 Project: ActiveMQ .Net
  Issue Type: Bug
Affects Versions: 1.6.0
Reporter: Remo Gloor
Assignee: Jim Gomes


When using FailoverTransport with nonBlockingRedelivery messages get 
PoisonAcked:

1. Message is rolledback e.g. due to a concurrency exception on the db or any 
other processing error.
2. Message is sheduled for redelivery e.g. in 30 Sec.
3. Connection is lost before message is redelivered
4. Connection is reestablished before message is redelivered.
5. Server redelivers message due to the connection loss
6. Message is dsipatched and processed.
7. Resheduled Message gets dispatched => Duplicate
8. No previously delivered messages => Send PoisonAck => Message is in the DLQ 
even though it is processed succesfully.



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

[jira] [Created] (AMQNET-460) WaitForRedeliveries ignores failoverRedeliveryWaitPeriod

[Remo Gloor (JIRA)]

Remo Gloor created AMQNET-460:
-

 Summary: WaitForRedeliveries ignores failoverRedeliveryWaitPeriod
 Key: AMQNET-460
 URL: https://issues.apache.org/jira/browse/AMQNET-460
 Project: ActiveMQ .Net
  Issue Type: Bug
Affects Versions: 1.6.0
Reporter: Remo Gloor
Assignee: Jim Gomes


MessageConsumer.WaitForRedeliveries() 

while (numberNotReplayed > 0 && expiry < DateTime.Now);

should be

while (numberNotReplayed > 0 && expiry > DateTime.Now);



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

[jira] [Reopened] (AMQ-4884) Wildcard matches do not match

[Rob Davies (JIRA)]

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

Rob Davies reopened AMQ-4884:
-


There's another case where A does not match A.> - its arguable if it should but 
to be compatible with MQTT wildcards on topics it does need to.

> Wildcard matches do not match
> -
>
> Key: AMQ-4884
> URL: https://issues.apache.org/jira/browse/AMQ-4884
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0, 5.9.0
>Reporter: Rob Davies
>Assignee: Rob Davies
> Fix For: 5.10.0
>
>
> If you subscribe to a Wildcard Destination (e.g. a Topic) - with an name 
> A.*.> then a message sent to a Destination A.B should match that Wildcard and 
> be assigned to that Subscriber. This is not the case currently.



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