[jira] [Updated] (AMQ-6236) OOTB, security does not appear to work

[Paul (JIRA)]

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

Paul updated AMQ-6236:
--
Description: 
download 5.13.2 - don't touch it other than to extract that tar

cd into ActiveMQ home

export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq

bin/activemq console xbean:examples/conf/activemq-security.xml

(starts up)

Run this java code: note absence of all username and password fields:
{code:title=java|borderStyle=solid}
public static void main(String[] args) throws Exception{
System.out.println("1");
System.out.println("2");
ConnectionFactory cf = 
new ActiveMQConnectionFactory("tcp://192.168.3.106:61616");
System.out.println("3");
Connection conn = cf.createConnection();//userName, password);
System.out.println("4");
}
{code}
Output is:
1
2
3
4

There are no exceptions at all. In debug mode I can step over the 
connection-creation.

*Surely* this should fail? I have in fact been unable to get any connection 
rejected no matter how I configure it. Is this the result of connecting from 
the machine on which ActiveMQ is running?

I want to believe this is user error but after hours I am  unable to prove 
myself at fault.

If I add anonymousAccessAllowed="false" to the simpleAuthenticationPlugin I get 
the same behavior

  was:
download 5.13.2 - don't touch it other than to extract that tar

cd into ActiveMQ home

export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq

bin/activemq console xbean:examples/conf/activemq-security.xml

(starts up)

Run this java code: note absence of all username and password fields:

public static void main(String[] args) throws Exception{
System.out.println("1");
System.out.println("2");
ConnectionFactory cf = 
new ActiveMQConnectionFactory("tcp://192.168.3.106:61616");
System.out.println("3");
Connection conn = cf.createConnection();//userName, password);
System.out.println("4");
}

Output is:
1
2
3
4

There are no exceptions at all. In debug mode I can step over the 
connection-creation.

*Surely* this should fail? I have in fact been unable to get any connection 
rejected no matter how I configure it. Is this the result of connecting from 
the machine on which ActiveMQ is running?

I want to believe this is user error but after hours I am  unable to prove 
myself at fault.

If I add anonymousAccessAllowed="false" to the simpleAuthenticationPlugin I get 
the same behavior


> OOTB, security does not appear to work
> --
>
> Key: AMQ-6236
> URL: https://issues.apache.org/jira/browse/AMQ-6236
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.13.2
> Environment: Mac OSX 10.11.3 (15D21)
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
>Reporter: Paul
>
> download 5.13.2 - don't touch it other than to extract that tar
> cd into ActiveMQ home
> export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq
> bin/activemq console xbean:examples/conf/activemq-security.xml
> (starts up)
> Run this java code: note absence of all username and password fields:
> {code:title=java|borderStyle=solid}
> public static void main(String[] args) throws Exception{
>   System.out.println("1");
>   System.out.println("2");
>   ConnectionFactory cf = 
>   new ActiveMQConnectionFactory("tcp://192.168.3.106:61616");
>   System.out.println("3");
>   Connection conn = cf.createConnection();//userName, password);
>   System.out.println("4");
> }
> {code}
> Output is:
> 1
> 2
> 3
> 4
> There are no exceptions at all. In debug mode I can step over the 
> connection-creation.
> *Surely* this should fail? I have in fact been unable to get any connection 
> rejected no matter how I configure it. Is this the result of connecting from 
> the machine on which ActiveMQ is running?
> I want to believe this is user error but after hours I am  unable to prove 
> myself at fault.
> If I add anonymousAccessAllowed="false" to the simpleAuthenticationPlugin I 
> get the same behavior



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-6238) Please delete old releases from mirroring system

[Sebb (JIRA)]

Sebb created AMQ-6238:
-

 Summary: Please delete old releases from mirroring system
 Key: AMQ-6238
 URL: https://issues.apache.org/jira/browse/AMQ-6238
 Project: ActiveMQ
  Issue Type: Bug
Reporter: Sebb


To reduce the load on the ASF mirrors, projects are required to delete old 
releases [1]

Please can you remove all non-current releases?

Thanks!

Note: you can still reference superseded versions from the download page, but 
the links should be adjusted to point to the archive server.

[1] http://www.apache.org/dev/release.html#when-to-archive



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-6237) Download page must not link to snapshots / nightly builds

[Sebb (JIRA)]

Sebb created AMQ-6237:
-

 Summary: Download page must not link to snapshots / nightly builds
 Key: AMQ-6237
 URL: https://issues.apache.org/jira/browse/AMQ-6237
 Project: ActiveMQ
  Issue Type: Bug
 Environment: http://activemq.apache.org/download.html
Reporter: Sebb


Nightly builds / snapshots which are not formal releases should not be linked 
from the main download page.

Such builds have not been voted on and should only be used by developers who 
should be made aware that the code is without any guarantees.

Nightly builds are not formal ASF releases, and must not be promoted to the 
general public.

See [1] second para. The second sentence states:

"Do not include any links on the project website that might encourage 
non-developers to download and use nightly builds, snapshots, release 
candidates, or any other similar package."

[1] http://www.apache.org/dev/release.html#what




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-6236) OOTB, security does not appear to work

[Paul (JIRA)]

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

Paul updated AMQ-6236:
--
Description: 
download 5.13.2 - don't touch it other than to extract that tar

cd into ActiveMQ home

export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq

bin/activemq console xbean:examples/conf/activemq-security.xml

(starts up)

Run this java code: note absence of all username and password fields:

public static void main(String[] args) throws Exception{
System.out.println("1");
System.out.println("2");
ConnectionFactory cf = 
new ActiveMQConnectionFactory("tcp://192.168.3.106:61616");
System.out.println("3");
Connection conn = cf.createConnection();//userName, password);
System.out.println("4");
}

Output is:
1
2
3
4

There are no exceptions at all. In debug mode I can step over the 
connection-creation.

*Surely* this should fail? I have in fact been unable to get any connection 
rejected no matter how I configure it. Is this the result of connecting from 
the machine on which ActiveMQ is running?

I want to believe this is user error but after hours I am  unable to prove 
myself at fault.

If I add anonymousAccessAllowed="false" to the simpleAuthenticationPlugin I get 
the same behavior

  was:
download 5.13.2 - don't touch it other than to extract that tar

cd into ActiveMQ home

export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq

bin/activemq console xbean:examples/conf/activemq-security.xml

(starts up)

Run this java code: note absence of all username and password fields:

public static void main(String[] args) throws Exception{
System.out.println("1");
System.out.println("2");
ConnectionFactory cf = 
new ActiveMQConnectionFactory("tcp://192.168.3.106:61616");
System.out.println("3");
Connection conn = cf.createConnection();//userName, password);
System.out.println("4");
}

Output is:
1
2
3
4

There are no exceptions at all. In debug mode I can step over the 
connection-creation.

*Surely* this should fail? I have in fact been unable to get any connection 
rejected no matter how I configure it. Is this the result of connecting from 
the machine on which ActiveMQ is running?

I want to believe this is user error but after hours I am  unable to prove 
myself at fault.


> OOTB, security does not appear to work
> --
>
> Key: AMQ-6236
> URL: https://issues.apache.org/jira/browse/AMQ-6236
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.13.2
> Environment: Mac OSX 10.11.3 (15D21)
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
>Reporter: Paul
>
> download 5.13.2 - don't touch it other than to extract that tar
> cd into ActiveMQ home
> export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq
> bin/activemq console xbean:examples/conf/activemq-security.xml
> (starts up)
> Run this java code: note absence of all username and password fields:
> public static void main(String[] args) throws Exception{
>   System.out.println("1");
>   System.out.println("2");
>   ConnectionFactory cf = 
>   new ActiveMQConnectionFactory("tcp://192.168.3.106:61616");
>   System.out.println("3");
>   Connection conn = cf.createConnection();//userName, password);
>   System.out.println("4");
> }
> Output is:
> 1
> 2
> 3
> 4
> There are no exceptions at all. In debug mode I can step over the 
> connection-creation.
> *Surely* this should fail? I have in fact been unable to get any connection 
> rejected no matter how I configure it. Is this the result of connecting from 
> the machine on which ActiveMQ is running?
> I want to believe this is user error but after hours I am  unable to prove 
> myself at fault.
> If I add anonymousAccessAllowed="false" to the simpleAuthenticationPlugin I 
> get the same behavior



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-6236) OOTB, security does not appear to work

[Paul (JIRA)]

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

Paul updated AMQ-6236:
--
Description: 
download 5.13.2 - don't touch it other than to extract that tar

cd into ActiveMQ home

export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq

bin/activemq console xbean:examples/conf/activemq-security.xml

(starts up)

Run this java code: note absence of all username and password fields:

public static void main(String[] args) throws Exception{
System.out.println("1");
System.out.println("2");
ConnectionFactory cf = 
new ActiveMQConnectionFactory("tcp://192.168.3.106:61616");
System.out.println("3");
Connection conn = cf.createConnection();//userName, password);
System.out.println("4");
}

Output is:
1
2
3
4

There are no exceptions at all. In debug mode I can step over the 
connection-creation.

*Surely* this should fail? I have in fact been unable to get any connection 
rejected no matter how I configure it. Is this the result of connecting from 
the machine on which ActiveMQ is running?

I want to believe this is user error but after hours I am  unable to prove 
myself at fault.

  was:
download 5.13.2 - don't touch it other than to extract that tar

cd {ActiveMQ home}
export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq

bin/activemq console xbean:examples/conf/activemq-security.xml

(starts up)

Run this java code: note absence of all username and password fields:

public static void main(String[] args) throws Exception{
System.out.println("1");
System.out.println("2");
ConnectionFactory cf = 
new ActiveMQConnectionFactory("tcp://192.168.3.106:61616");
System.out.println("3");
Connection conn = cf.createConnection();//userName, password);
System.out.println("4");
}

Output is:
1
2
3
4

There are no exceptions at all. In debug mode I can step over the 
connection-creation.

*Surely* this should fail? I have in fact been unable to get any connection 
rejected no matter how I configure it. Is this the result of connecting from 
the machine on which ActiveMQ is running?

I want to believe this is user error but after hours I am  unable to prove 
myself at fault.


> OOTB, security does not appear to work
> --
>
> Key: AMQ-6236
> URL: https://issues.apache.org/jira/browse/AMQ-6236
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.13.2
> Environment: Mac OSX 10.11.3 (15D21)
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
>Reporter: Paul
>
> download 5.13.2 - don't touch it other than to extract that tar
> cd into ActiveMQ home
> export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq
> bin/activemq console xbean:examples/conf/activemq-security.xml
> (starts up)
> Run this java code: note absence of all username and password fields:
> public static void main(String[] args) throws Exception{
>   System.out.println("1");
>   System.out.println("2");
>   ConnectionFactory cf = 
>   new ActiveMQConnectionFactory("tcp://192.168.3.106:61616");
>   System.out.println("3");
>   Connection conn = cf.createConnection();//userName, password);
>   System.out.println("4");
> }
> Output is:
> 1
> 2
> 3
> 4
> There are no exceptions at all. In debug mode I can step over the 
> connection-creation.
> *Surely* this should fail? I have in fact been unable to get any connection 
> rejected no matter how I configure it. Is this the result of connecting from 
> the machine on which ActiveMQ is running?
> I want to believe this is user error but after hours I am  unable to prove 
> myself at fault.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-6236) OOTB, security does not appear to work

[Paul (JIRA)]

Paul created AMQ-6236:
-

 Summary: OOTB, security does not appear to work
 Key: AMQ-6236
 URL: https://issues.apache.org/jira/browse/AMQ-6236
 Project: ActiveMQ
  Issue Type: Bug
  Components: security
Affects Versions: 5.13.2
 Environment: Mac OSX 10.11.3 (15D21)

java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

Reporter: Paul


download 5.13.2 - don't touch it other than to extract that tar

cd {ActiveMQ home}
export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq

bin/activemq console xbean:examples/conf/activemq-security.xml

(starts up)

Run this java code: note absence of all username and password fields:

public static void main(String[] args) throws Exception{
System.out.println("1");
System.out.println("2");
ConnectionFactory cf = 
new ActiveMQConnectionFactory("tcp://192.168.3.106:61616");
System.out.println("3");
Connection conn = cf.createConnection();//userName, password);
System.out.println("4");
}

Output is:
1
2
3
4

There are no exceptions at all. In debug mode I can step over the 
connection-creation.

*Surely* this should fail? I have in fact been unable to get any connection 
rejected no matter how I configure it. Is this the result of connecting from 
the machine on which ActiveMQ is running?

I want to believe this is user error but after hours I am  unable to prove 
myself at fault.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (AMQ-3888) Better Maven dependency for some specs

[Timothy Bish (JIRA)]

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

Timothy Bish closed AMQ-3888.
-
Resolution: Won't Fix

> Better Maven dependency for some specs
> --
>
> Key: AMQ-3888
> URL: https://issues.apache.org/jira/browse/AMQ-3888
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.6.0
>Reporter: Bruno Borges
>
> It seems that, to have ActiveMQ component for Camel run fine on a JBoss 
> instance, I had to add all these dependencies as 'provided' to avoid specs 
> artifacts falling on my WEB-INF/lib.
> Would be nice to have this fixed on the next release of ActiveMQ
> 
>   
>   org.apache.activemq
>   activemq-camel
>   
>   
>   org.apache.activemq
>   activemq-pool
>   
> 
>   
>   org.apache.geronimo.specs
>   geronimo-jta_1.0.1B_spec
>   1.0.1
>   provided
>   
>   
>   org.apache.geronimo.specs
>   geronimo-jms_1.1_spec
>   1.1.1
>   provided
>   
>   
>   org.apache.geronimo.specs
>   
> geronimo-j2ee-management_1.1_spec
>   1.0.1
>   provided
>   
>   
>   javax.inject
>   javax.inject
>   1
>   provided
>   
>   
>   org.mortbay.jetty
>   jsp-api-2.1
>   6.1.4
>   provided
>   
>   
>   org.mortbay.jetty
>   jsp-2.1
>   6.1.4
>   provided
>   
>   
>   javax.annotation
>   jsr250-api
>   1.0
>   provided
>   
>   
>   com.google.code.findbugs
>   jsr305
>   1.3.9
>   provided
>   



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (AMQ-3862) Ajax connector doesn't support guaranteed delivery

[Timothy Bish (JIRA)]

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

Timothy Bish closed AMQ-3862.
-
Resolution: Won't Fix

> Ajax connector doesn't support guaranteed delivery
> --
>
> Key: AMQ-3862
> URL: https://issues.apache.org/jira/browse/AMQ-3862
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 5.6.0
> Environment: Windows 7
>Reporter: Dave Thompson
>
> The Ajax connector do not support guaranteed delivery. As each message is 
> sent without a unique identifier and there is no checking of this, then it is 
> possible for a transport-level issue to cause messages to be lost.
> A good way to fix this would be to hold a queue of dispatched messages inside 
> the servlets, and the Ajax client could then submit the last received message 
> ID when it commences the poll for new messages - and the queued items which 
> have been delivered could then be erased.
> I'd try and fix this myself but I can't get the trunk working in Eclipse.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6203) KahaDB: Allow rewrite of message acks in older logs which prevent cleanup

[Arthur Naseef (JIRA)]

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

Arthur Naseef commented on AMQ-6203:


I agree with this - sounds like a great approach.

> KahaDB: Allow rewrite of message acks in older logs which prevent cleanup
> -
>
> Key: AMQ-6203
> URL: https://issues.apache.org/jira/browse/AMQ-6203
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: KahaDB
>Affects Versions: 5.13.0, 5.13.1, 5.12.3, 5.13.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0
>
>
> There are cases where a chain of journal logs can grow due to acks for 
> messages in older logs needing to be kept so that on recovery proper state 
> can be restored and older messages not be resurrected.  
> In many cases just moving the acks from one log forward to a new log can free 
> an entire chain during subsequent GC cycles.  The 'compacted' ack log can be 
> written during the time between GC cycles without the index lock being held 
> meaning normal broker operations can continue.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6203) KahaDB: Allow rewrite of message acks in older logs which prevent cleanup

[Jeff Genender (JIRA)]

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

Jeff Genender commented on AMQ-6203:


Yep... if it can be off by default and allow someone to turn it on, I think 
that totally would be a good bridge to have in those point releases.  It allows 
an escape route in the event it doesn't work and only impacts those who know 
enough to turn it on.  Thoughts?

> KahaDB: Allow rewrite of message acks in older logs which prevent cleanup
> -
>
> Key: AMQ-6203
> URL: https://issues.apache.org/jira/browse/AMQ-6203
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: KahaDB
>Affects Versions: 5.13.0, 5.13.1, 5.12.3, 5.13.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0
>
>
> There are cases where a chain of journal logs can grow due to acks for 
> messages in older logs needing to be kept so that on recovery proper state 
> can be restored and older messages not be resurrected.  
> In many cases just moving the acks from one log forward to a new log can free 
> an entire chain during subsequent GC cycles.  The 'compacted' ack log can be 
> written during the time between GC cycles without the index lock being held 
> meaning normal broker operations can continue.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6203) KahaDB: Allow rewrite of message acks in older logs which prevent cleanup

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-6203:
---

Initialize the value of compactAcksAfterNoGC on MessageDatabase.java to -1 and 
you should be all set. 

> KahaDB: Allow rewrite of message acks in older logs which prevent cleanup
> -
>
> Key: AMQ-6203
> URL: https://issues.apache.org/jira/browse/AMQ-6203
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: KahaDB
>Affects Versions: 5.13.0, 5.13.1, 5.12.3, 5.13.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0
>
>
> There are cases where a chain of journal logs can grow due to acks for 
> messages in older logs needing to be kept so that on recovery proper state 
> can be restored and older messages not be resurrected.  
> In many cases just moving the acks from one log forward to a new log can free 
> an entire chain during subsequent GC cycles.  The 'compacted' ack log can be 
> written during the time between GC cycles without the index lock being held 
> meaning normal broker operations can continue.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6203) KahaDB: Allow rewrite of message acks in older logs which prevent cleanup

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon commented on AMQ-6203:
-

I agree with Tim that it is a bit risky to back port this.  But I think it is 
ok to do it as long as it is off by default.  So I will go ahead and do that 
for a 5.13.3 release because it seems there are a few different people 
requesting this.

> KahaDB: Allow rewrite of message acks in older logs which prevent cleanup
> -
>
> Key: AMQ-6203
> URL: https://issues.apache.org/jira/browse/AMQ-6203
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: KahaDB
>Affects Versions: 5.13.0, 5.13.1, 5.12.3, 5.13.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0
>
>
> There are cases where a chain of journal logs can grow due to acks for 
> messages in older logs needing to be kept so that on recovery proper state 
> can be restored and older messages not be resurrected.  
> In many cases just moving the acks from one log forward to a new log can free 
> an entire chain during subsequent GC cycles.  The 'compacted' ack log can be 
> written during the time between GC cycles without the index lock being held 
> meaning normal broker operations can continue.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6203) KahaDB: Allow rewrite of message acks in older logs which prevent cleanup

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-6203:
---

These changes operate at the journal level where mistakes means loss of 
messages in the worse case, so for folks dropping this into their production as 
a point release unaware of this change there could be some big surprises if I 
happened to have missed something in there.

If someone does take it upon themselves to put this on a point release I'd 
recommend that they make it off by default just to protect those not expecting 
such a change.  

> KahaDB: Allow rewrite of message acks in older logs which prevent cleanup
> -
>
> Key: AMQ-6203
> URL: https://issues.apache.org/jira/browse/AMQ-6203
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: KahaDB
>Affects Versions: 5.13.0, 5.13.1, 5.12.3, 5.13.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0
>
>
> There are cases where a chain of journal logs can grow due to acks for 
> messages in older logs needing to be kept so that on recovery proper state 
> can be restored and older messages not be resurrected.  
> In many cases just moving the acks from one log forward to a new log can free 
> an entire chain during subsequent GC cycles.  The 'compacted' ack log can be 
> written during the time between GC cycles without the index lock being held 
> meaning normal broker operations can continue.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMQ-6235) SimpleDiscoveryAgent doesn't honor it's configured initialReconnectDelay

[Timothy Bish (JIRA)]

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

Timothy Bish resolved AMQ-6235.
---
Resolution: Fixed

> SimpleDiscoveryAgent doesn't honor it's configured initialReconnectDelay
> 
>
> Key: AMQ-6235
> URL: https://issues.apache.org/jira/browse/AMQ-6235
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, networkbridge
>Affects Versions: 5.x
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0
>
>
> The SimpleDiscoveryAgent code has a configurable initialReconnectDelay that 
> is not currently used correctly.  If the connection is lost right away on a 
> connect attempt it may use the delay but if the connection has been up longer 
> than the configurable minConnectTime then a connection attempt is immediately 
> tried and will then drop back to the initialReconnectDelay if this immediate 
> reconnection attempt fails.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6235) SimpleDiscoveryAgent doesn't honor it's configured initialReconnectDelay

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on AMQ-6235:
--

Commit b1c55fdc744987245c409af5835fd1a74bdc49ed in activemq's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=b1c55fd ]

https://issues.apache.org/jira/browse/AMQ-6235

Honor the initialReconnectDelay configuration in all cases.  

> SimpleDiscoveryAgent doesn't honor it's configured initialReconnectDelay
> 
>
> Key: AMQ-6235
> URL: https://issues.apache.org/jira/browse/AMQ-6235
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, networkbridge
>Affects Versions: 5.x
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0
>
>
> The SimpleDiscoveryAgent code has a configurable initialReconnectDelay that 
> is not currently used correctly.  If the connection is lost right away on a 
> connect attempt it may use the delay but if the connection has been up longer 
> than the configurable minConnectTime then a connection attempt is immediately 
> tried and will then drop back to the initialReconnectDelay if this immediate 
> reconnection attempt fails.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6203) KahaDB: Allow rewrite of message acks in older logs which prevent cleanup

[Jeff Genender (JIRA)]

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

Jeff Genender commented on AMQ-6203:


Hi Tim, thanks for the quick response.  May I ask how is this not applicable to 
a point release from the perspective that it has the potential to fix a blocker 
bug(s) that affects 3 major versions of ActiveMQ?  The code looks good and it 
seems that the behavior of this fix is transparent to the user.  Its a good fix 
that has a great impact and it really would be great to get it into those other 
point releases.  AMQ-5695 looks heavily connected as we have determined form 
log files that it looks like the acks are what cause the log file leaks in 
those versions.

> KahaDB: Allow rewrite of message acks in older logs which prevent cleanup
> -
>
> Key: AMQ-6203
> URL: https://issues.apache.org/jira/browse/AMQ-6203
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: KahaDB
>Affects Versions: 5.13.0, 5.13.1, 5.12.3, 5.13.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0
>
>
> There are cases where a chain of journal logs can grow due to acks for 
> messages in older logs needing to be kept so that on recovery proper state 
> can be restored and older messages not be resurrected.  
> In many cases just moving the acks from one log forward to a new log can free 
> an entire chain during subsequent GC cycles.  The 'compacted' ack log can be 
> written during the time between GC cycles without the index lock being held 
> meaning normal broker operations can continue.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6203) KahaDB: Allow rewrite of message acks in older logs which prevent cleanup

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-6203:
---

This is new functionality with potential side effects which requires proper 
testing before someone were to put it into production and is not suitable for a 
point release where this sort of large behavioural change would not be 
expected.  

> KahaDB: Allow rewrite of message acks in older logs which prevent cleanup
> -
>
> Key: AMQ-6203
> URL: https://issues.apache.org/jira/browse/AMQ-6203
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: KahaDB
>Affects Versions: 5.13.0, 5.13.1, 5.12.3, 5.13.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0
>
>
> There are cases where a chain of journal logs can grow due to acks for 
> messages in older logs needing to be kept so that on recovery proper state 
> can be restored and older messages not be resurrected.  
> In many cases just moving the acks from one log forward to a new log can free 
> an entire chain during subsequent GC cycles.  The 'compacted' ack log can be 
> written during the time between GC cycles without the index lock being held 
> meaning normal broker operations can continue.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5695) KahaDB not cleaning up log files

[Jeff Genender (JIRA)]

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

Jeff Genender commented on AMQ-5695:


5.13.1 still has it.

It would be nice to see if AMQ-6203 fix will resolve this one.

> KahaDB not cleaning up log files
> 
>
> Key: AMQ-5695
> URL: https://issues.apache.org/jira/browse/AMQ-5695
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Stefan Warten
>Priority: Blocker
>
> Since we have upgraded ActiveMQ from 5.10.0 to 5.11.1, KahaDB is not cleaning 
> up log files properly. It seems to keep all of them. It helped once to 
> restart the service and minutes later, ActiveMQ cleaned up 95% of log files 
> but mostly it is not cleaning up at all.
> When partition was full, I stopped ActiveMQ, copied the KahaDB to another 
> host and started it with empty queues again. Then I forwarded all messages 
> from that other host back. Even when all messages were forwarded and all 
> queues were empty, the old KahaDB log files were not cleaned up.
> I stopped ActiveMQ, removed db.data and db.redo to rebuild index which took 
> around 3h (350GB of log files) but still, the log files are not cleaned up.
> [...]
> 2015-03-30 18:21:55,532 | INFO  | @13786:158508, 32130 entries recovered 
> .. | org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain
> 2015-03-30 18:22:02,090 | INFO  | Recovery replayed 321378917 operations from 
> the journal in 9226.159 seconds. | 
> org.apache.activemq.store.kahadb.MessageDatabase | WrapperSimpleAppMain
> 2015-03-30 18:22:02,402 | INFO  | installing runtimeConfiguration plugin | 
> org.apache.activemq.plugin.RuntimeConfigurationPlugin | WrapperSimpleAppMain
> 2015-03-30 18:22:04,576 | INFO  | Apache ActiveMQ 5.11.1 
> (prd-mig-02-sat.example.com, 
> ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) is starting | 
> org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2015-03-30 18:22:04,946 | INFO  | pending local transactions: [] | 
> org.apache.activemq.store.kahadb.MultiKahaDBTransactionStore | 
> WrapperSimpleAppMain
> 2015-03-30 18:22:08,488 | INFO  | Configuration class path resource 
> [activemq.xml] | org.apache.activemq.plugin.RuntimeConfigurationBroker | 
> WrapperSimpleAppMain
> 2015-03-30 18:22:12,198 | INFO  | Listening for connections at: 
> nio://prd-mig-02-sat.example.com:61616?transport.reuseAddress=true | 
> org.apache.activemq.transport.TransportServerThreadSupport | 
> WrapperSimpleAppMain
> 2015-03-30 18:22:12,199 | INFO  | Connector openwire started | 
> org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain
> 2015-03-30 18:22:12,232 | INFO  | Listening for connections at: 
> stomp+nio://prd-mig-02-sat.example.com:61613?transport.closeAsync=false=true
>  | org.apache.activemq.transport.TransportServerThreadSupport | 
> WrapperSimpleAppMain
> 2015-03-30 18:22:12,234 | INFO  | Connector stomp started | 
> org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain
> 2015-03-30 18:22:12,237 | INFO  | Establishing network connection from 
> vm://prd-mig-02-sat.example.com?async=false=true to 
> tcp://172.42.15.40:61616 | 
> org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain
> 2015-03-30 18:22:12,286 | INFO  | Connector vm://prd-mig-02-sat.example.com 
> started | org.apache.activemq.broker.TransportConnector | WrapperSimpleAppMain
> 2015-03-30 18:22:12,318 | INFO  | Establishing network connection from 
> vm://prd-mig-02-sat.example.com?async=false=true to 
> tcp://172.42.15.39:61616 | 
> org.apache.activemq.network.DiscoveryNetworkConnector | WrapperSimpleAppMain
> 2015-03-30 18:22:12,321 | INFO  | Network Connector 
> DiscoveryNetworkConnector:FORWARDER:BrokerService[prd-mig-02-sat.example.com] 
> started | org.apache.activemq.network.NetworkConnector | WrapperSimpleAppMain
> 2015-03-30 18:22:12,325 | INFO  | Apache ActiveMQ 5.11.1 
> (prd-mig-02-sat.example.com, 
> ID:prd-mig-02-sat.example.com-26260-1427730492201-1:1) started | 
> org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2015-03-30 18:22:12,326 | INFO  | For help or more information please see: 
> http://activemq.apache.org | org.apache.activemq.broker.BrokerService | 
> WrapperSimpleAppMain
> 2015-03-30 18:22:12,381 | INFO  | Network connection between 
> vm://prd-mig-02-sat.example.com#0 and tcp:///172.42.15.40:61616@58567 
> (prdvip-amq-01-sat.example.com) has been established. | 
> org.apache.activemq.network.DemandForwardingBridgeSupport | 
> triggerStartAsyncNetworkBridgeCreation: 
> remoteBroker=tcp:///172.42.15.40:61616@58567, localBroker= 
> vm://prd-mig-02-sat.example.com#0
> 2015-03-30 18:22:12,381 | INFO  | Network connection between 
> vm://prd-mig-02-sat.example.com#2 and tcp:///172.42.15.39:61616@4523 
> 

[jira] [Commented] (AMQ-6203) KahaDB: Allow rewrite of message acks in older logs which prevent cleanup

[Jeff Genender (JIRA)]

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

Jeff Genender commented on AMQ-6203:


This actually looks like its related to AMQ-5695. Any reason why this wasn't 
back ported to the aforementioned version branch? If this truly does fix up 
those versions, this is a good candidate to be in 5.13.x.  I also believe this 
affects 5.11.x, 5.12. as well.  See AMQ-5695 for details.

> KahaDB: Allow rewrite of message acks in older logs which prevent cleanup
> -
>
> Key: AMQ-6203
> URL: https://issues.apache.org/jira/browse/AMQ-6203
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: KahaDB
>Affects Versions: 5.13.0, 5.13.1, 5.12.3, 5.13.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0
>
>
> There are cases where a chain of journal logs can grow due to acks for 
> messages in older logs needing to be kept so that on recovery proper state 
> can be restored and older messages not be resurrected.  
> In many cases just moving the acks from one log forward to a new log can free 
> an entire chain during subsequent GC cycles.  The 'compacted' ack log can be 
> written during the time between GC cycles without the index lock being held 
> meaning normal broker operations can continue.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (AMQ-6207) KahaDB: corruption of the index possible on sudden stop of the broker

[Jeff Genender (JIRA)]

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

Jeff Genender updated AMQ-6207:
---
Comment: was deleted

(was: This actually looks like its related to AMQ-5695.  Any reason why this 
wasn't back ported to the aforementioned version branches?  If this truly does 
fix up those versions, this is a good candidate to be in those other releases.)

> KahaDB: corruption of the index possible on sudden stop of the broker
> -
>
> Key: AMQ-6207
> URL: https://issues.apache.org/jira/browse/AMQ-6207
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB
>Affects Versions: 5.11.4, 5.12.3, 5.13.2
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.14.0, 5.13.3
>
> Attachments: kahadb-corruption.tar.bz2
>
>
> On a sudden stop of the broker it's possible for the KahaDB index to become 
> corrupt and the broker will refuse to start.  The issue is in the PageFile 
> code that is mixing writes to both the recovery file and the index file.  The 
> writes need to happen in a deterministic way such that the recovery file 
> isn't missing data that might make it into the the main index file.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-6234) Cannot configure the load balancing count when using Message Groups

[I McClure (JIRA)]

I McClure created AMQ-6234:
--

 Summary: Cannot configure the load balancing count when using 
Message Groups
 Key: AMQ-6234
 URL: https://issues.apache.org/jira/browse/AMQ-6234
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Documentation
Affects Versions: 5.10.0
 Environment: Centos 6.7;  Oracle Java 1.6.0_30
Reporter: I McClure


We are seeing ActiveMQ configure the first 10 messages with different 
JMSXGroupID values to the same consuming node before distributing subsequent 
messages across the attached consumers.

We need to be able to configure this value down to 1 to allow us to evenly 
balance the load across the consumers in a round robin fashion.

But we cannot see from the documentation how to configure this property.

For example:
1 AMQ broker with a queue that has 3 attached consumers.
Sending a message with a JMSXGroupID of 'A' goes to consumer 1
The next 9 messages with different JMSXGroupIDs also go to consumer 1
The 11th message with a different JMSXGroupdID goes to consumer 2

This results in an unevenly balanced cluster of consumers when utilising 
Message Groups.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-475) [Artemis Testsuite] SessionCloseTest#testCanNotUseXAWithClosedSession fails

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232229#comment-15232229
 ] 

ASF GitHub Bot commented on ARTEMIS-475:


Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/444


> [Artemis Testsuite] SessionCloseTest#testCanNotUseXAWithClosedSession fails
> ---
>
> Key: ARTEMIS-475
> URL: https://issues.apache.org/jira/browse/ARTEMIS-475
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: expected:<4> but was:<-7>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.artemis.tests.util.ActiveMQTestBase.expectXAException(ActiveMQTestBase.java:953)
>   at 
> org.apache.activemq.artemis.tests.integration.client.SessionCloseTest.testCanNotUseXAWithClosedSession(SessionCloseTest.java:135)
> {code}
> The test fails because of 
> https://github.com/apache/activemq-artemis/commit/ddf8d8f96e33f5f80e1c7a1590de9579aa8ead50
>  We need to update expected XA return code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-475) [Artemis Testsuite] SessionCloseTest#testCanNotUseXAWithClosedSession fails

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232227#comment-15232227
 ] 

ASF subversion and git services commented on ARTEMIS-475:
-

Commit 9055c76cc88320d94a6c4341b9b29b68e2e0cd7a in activemq-artemis's branch 
refs/heads/master from [~eduda]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=9055c76 ]

ARTEMIS-475 - [Artemis Testsuite] 
SessionCloseTest#testCanNotUseXAWithClosedSession fails


> [Artemis Testsuite] SessionCloseTest#testCanNotUseXAWithClosedSession fails
> ---
>
> Key: ARTEMIS-475
> URL: https://issues.apache.org/jira/browse/ARTEMIS-475
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: expected:<4> but was:<-7>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.artemis.tests.util.ActiveMQTestBase.expectXAException(ActiveMQTestBase.java:953)
>   at 
> org.apache.activemq.artemis.tests.integration.client.SessionCloseTest.testCanNotUseXAWithClosedSession(SessionCloseTest.java:135)
> {code}
> The test fails because of 
> https://github.com/apache/activemq-artemis/commit/ddf8d8f96e33f5f80e1c7a1590de9579aa8ead50
>  We need to update expected XA return code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-472) AMQ222137 warning does not display the cause of the problem

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232108#comment-15232108
 ] 

ASF GitHub Bot commented on ARTEMIS-472:


Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/442


> AMQ222137 warning does not display the cause of the problem
> ---
>
> Key: ARTEMIS-472
> URL: https://issues.apache.org/jira/browse/ARTEMIS-472
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.2.0
>Reporter: Jeff Mesnil
>
> While creating a cluster of Artemis servers, I encountered this warning:
> {noformat}
> 18:01:45,009 WARN  [org.apache.activemq.artemis.core.server] (Thread-2 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@491444
> ff-1205056429)) AMQ222137: Unable to announce backup, retrying
> {noformat}
> The cause of the error was not displayed and I had to debug to figure out 
> that I forgot to set the cluster user credentials to let the node join the 
> cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-472) AMQ222137 warning does not display the cause of the problem

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232106#comment-15232106
 ] 

ASF subversion and git services commented on ARTEMIS-472:
-

Commit ed5533ecb6ebbde13d7d9cf13a0d72eb190ee8c8 in activemq-artemis's branch 
refs/heads/master from [~jmesnil]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=ed5533e ]

[ARTEMIS-472] add cause to AMQ222137 warning

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-472


> AMQ222137 warning does not display the cause of the problem
> ---
>
> Key: ARTEMIS-472
> URL: https://issues.apache.org/jira/browse/ARTEMIS-472
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.2.0
>Reporter: Jeff Mesnil
>
> While creating a cluster of Artemis servers, I encountered this warning:
> {noformat}
> 18:01:45,009 WARN  [org.apache.activemq.artemis.core.server] (Thread-2 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@491444
> ff-1205056429)) AMQ222137: Unable to announce backup, retrying
> {noformat}
> The cause of the error was not displayed and I had to debug to figure out 
> that I forgot to set the cluster user credentials to let the node join the 
> cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-472) AMQ222137 warning does not display the cause of the problem

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232105#comment-15232105
 ] 

ASF subversion and git services commented on ARTEMIS-472:
-

Commit ed5533ecb6ebbde13d7d9cf13a0d72eb190ee8c8 in activemq-artemis's branch 
refs/heads/master from [~jmesnil]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=ed5533e ]

[ARTEMIS-472] add cause to AMQ222137 warning

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-472


> AMQ222137 warning does not display the cause of the problem
> ---
>
> Key: ARTEMIS-472
> URL: https://issues.apache.org/jira/browse/ARTEMIS-472
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.2.0
>Reporter: Jeff Mesnil
>
> While creating a cluster of Artemis servers, I encountered this warning:
> {noformat}
> 18:01:45,009 WARN  [org.apache.activemq.artemis.core.server] (Thread-2 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@491444
> ff-1205056429)) AMQ222137: Unable to announce backup, retrying
> {noformat}
> The cause of the error was not displayed and I had to debug to figure out 
> that I forgot to set the cluster user credentials to let the node join the 
> cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon edited comment on AMQ-6142 at 4/8/16 11:14 AM:
--

Yep agreed, lets roll back the sync I added.  I think the Jira reported for 
AMQ-5857 was about client side and not the broker side (since 
reduceMemoryFootprint exists to clear the duplicate state, at least for 
queues).  I would say we either need to roll that commit back as well or maybe 
figure out a way so that the client can clear out the state but the broker 
won't clear it out until it is safe to do so.


was (Author: christopher.l.shannon):
Yep agreed, lets roll back the sync I added.  I think the Jira reported for 
AMQ-5857 was about client side and not the broker side (since 
reduceMemoryFootprint exists to clear the duplicate state, at least for 
queues).  I would say we either need to roll that back that commit as well or 
maybe figure out a way so that the client can clear out the state but the 
broker won't clear it out until it is safe to do so.

> ActiveMQBytesMessage decompress throws DataFormatException incorrect header 
> check
> -
>
> Key: AMQ-6142
> URL: https://issues.apache.org/jira/browse/AMQ-6142
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.10.2, 5.12.1, 5.11.3, 5.13.0
>Reporter: Claudio Tagliola
>Assignee: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
> Attachments: Client.java, MessageListener.java, Server.java, 
> amq-6142.diff, pom.xml
>
>
> In our environment we use an embedded broker. On one topic where compression 
> is enabled, the server is also listening in on the messages. From ActiveMQ 
> 5.10.0 up to 5.13.0, we encounter DataFormatException: incorrect header check 
> exceptions on the tcp clients due to corruption of the payload. Attached are 
> a test server and client. At some point, the client will exit due to 
> mentioned exception. Increase chances by running multiple clients. This 
> scenario works with 5.8.0 and 5.9.1.
> If the server has multiple consumers on the same topic, they will encounter 
> corruption as well, but this has other side-effects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon commented on AMQ-6142:
-

Yep agreed, lets roll back the sync I added.  I think the Jira reported for 
AMQ-5857 was about client side and not the broker side (since 
reduceMemoryFootprint exists to clear the duplicate state, at least for 
queues).  I would say we either need to roll that back that commit as well or 
maybe figure out a way so that the client can clear out the state but the 
broker won't clear it out until it is safe to do so.

> ActiveMQBytesMessage decompress throws DataFormatException incorrect header 
> check
> -
>
> Key: AMQ-6142
> URL: https://issues.apache.org/jira/browse/AMQ-6142
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.10.2, 5.12.1, 5.11.3, 5.13.0
>Reporter: Claudio Tagliola
>Assignee: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
> Attachments: Client.java, MessageListener.java, Server.java, 
> amq-6142.diff, pom.xml
>
>
> In our environment we use an embedded broker. On one topic where compression 
> is enabled, the server is also listening in on the messages. From ActiveMQ 
> 5.10.0 up to 5.13.0, we encounter DataFormatException: incorrect header check 
> exceptions on the tcp clients due to corruption of the payload. Attached are 
> a test server and client. At some point, the client will exit due to 
> mentioned exception. Increase chances by running multiple clients. This 
> scenario works with 5.8.0 and 5.9.1.
> If the server has multiple consumers on the same topic, they will encounter 
> corruption as well, but this has other side-effects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-6233) Causing server OOM when publishing messages through RESTful API without clientId param

[Ding Jinqiang (JIRA)]

Ding Jinqiang created AMQ-6233:
--

 Summary: Causing server OOM when publishing messages through 
RESTful API without clientId param
 Key: AMQ-6233
 URL: https://issues.apache.org/jira/browse/AMQ-6233
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.13.2
Reporter: Ding Jinqiang


When I firstly try using the RESTful API to produce messages, I found that 
ActiveMQ soon ran into OOM Error, and then I found out that it is because:
1. I didn't send a clientId param
2. I use the plain HttpURLConnection to send request, without maintaining 
cookies.

According to org.apache.activemq.web.MessageServlet#getWebClient 
 and 
org.apache.activemq.web.WebClient#getWebClient(javax.servlet.http.HttpServletRequest):
{code:borderStyle=solid}
/** org.apache.activemq.web.MessageServlet#getWebClient **/
public WebClient getWebClient(HttpServletRequest request) {
String clientId = request.getParameter("clientId");
if (clientId != null) {
synchronized (this) {
LOG.debug("Getting local client [" + clientId + "]");
WebClient client = clients.get(clientId);
if (client == null) {
LOG.debug("Creating new client [" + clientId + "]");
client = new WebClient();
clients.put(clientId, client);
}
return client;
}

} else {
return WebClient.getWebClient(request);
}
}

/** 
org.apache.activemq.web.WebClient#getWebClient(javax.servlet.http.HttpServletRequest
 **/
public static WebClient getWebClient(HttpServletRequest request) {
HttpSession session = request.getSession(true);
WebClient client = getWebClient(session);
if (client == null || client.isClosed()) {
client = WebClient.createWebClient(request);
session.setAttribute(WEB_CLIENT_ATTRIBUTE, client);
}

return client;
}

{code}

I finally found that it will create new WebClient every time I publish a new 
message, which soon drain total memory.

To my mind, solution is, either doing some stuff to prevent that case (maybe 
using a default webClient instead of creating new one) or explaining it 
seriously in your documantation at http://activemq.apache.org/rest.html 




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-6232) Additional '\n' added when publishing messages through RESTful API

[Ding Jinqiang (JIRA)]

Ding Jinqiang created AMQ-6232:
--

 Summary: Additional  '\n' added when publishing messages through 
RESTful API
 Key: AMQ-6232
 URL: https://issues.apache.org/jira/browse/AMQ-6232
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.13.2
Reporter: Ding Jinqiang


I think there's a problem in reading post body in 
org.apache.activemq.web.MessageServletSupport#getPostedMessageBody:

{code:title=MessageServletSupport.java|borderStyle=solid}
 /**
 * @return the text that was posted to the servlet which is used as the body
 * of the message to be sent
 */
protected String getPostedMessageBody(HttpServletRequest request) throws 
IOException {
String answer = request.getParameter(bodyParameter);
String contentType = request.getContentType();
if (answer == null && contentType != null) {
LOG.debug("Content-Type={}", contentType);
// lets read the message body instead
BufferedReader reader = request.getReader();
StringBuffer buffer = new StringBuffer();   //BTW, StringBuilder is 
a better choice?
while (true) {
String line = reader.readLine();  //shouldn't using readLine
if (line == null) {
break;
}
buffer.append(line);
buffer.append("\n");// additional '\n' added when last line 
doesn't end with '\n'
}
return buffer.toString();
}
return answer;
}
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-475) [Artemis Testsuite] SessionCloseTest#testCanNotUseXAWithClosedSession fails

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231709#comment-15231709
 ] 

ASF GitHub Bot commented on ARTEMIS-475:


GitHub user dudaerich opened a pull request:

https://github.com/apache/activemq-artemis/pull/444

ARTEMIS-475 - [Artemis Testsuite] SessionCloseTest#testCanNotUseXAWit…

…hClosedSession fails

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

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-475

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

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


commit 4f7c206853fdcaeef83c21d327e9637a1e959dd9
Author: Erich Duda 
Date:   2016-04-08T06:25:44Z

ARTEMIS-475 - [Artemis Testsuite] 
SessionCloseTest#testCanNotUseXAWithClosedSession fails




> [Artemis Testsuite] SessionCloseTest#testCanNotUseXAWithClosedSession fails
> ---
>
> Key: ARTEMIS-475
> URL: https://issues.apache.org/jira/browse/ARTEMIS-475
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: expected:<4> but was:<-7>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.artemis.tests.util.ActiveMQTestBase.expectXAException(ActiveMQTestBase.java:953)
>   at 
> org.apache.activemq.artemis.tests.integration.client.SessionCloseTest.testCanNotUseXAWithClosedSession(SessionCloseTest.java:135)
> {code}
> The test fails because of 
> https://github.com/apache/activemq-artemis/commit/ddf8d8f96e33f5f80e1c7a1590de9579aa8ead50
>  We need to update expected XA return code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARTEMIS-475) [Artemis Testsuite] SessionCloseTest#testCanNotUseXAWithClosedSession fails

[Erich Duda (JIRA)]

Erich Duda created ARTEMIS-475:
--

 Summary: [Artemis Testsuite] 
SessionCloseTest#testCanNotUseXAWithClosedSession fails
 Key: ARTEMIS-475
 URL: https://issues.apache.org/jira/browse/ARTEMIS-475
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Erich Duda


{code}
java.lang.AssertionError: expected:<4> but was:<-7>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at 
org.apache.activemq.artemis.tests.util.ActiveMQTestBase.expectXAException(ActiveMQTestBase.java:953)
at 
org.apache.activemq.artemis.tests.integration.client.SessionCloseTest.testCanNotUseXAWithClosedSession(SessionCloseTest.java:135)
{code}

The test fails because of 
https://github.com/apache/activemq-artemis/commit/ddf8d8f96e33f5f80e1c7a1590de9579aa8ead50
 We need to update expected XA return code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)