Re: [POLL] - Remove the old ActiveMQ Console
In my opinion, this control issue is totally overblown. First of all, we're not some newcomers trying to put a malware into the project. We're people that are developing this project for the last 5-7 years and are trying to position it better for the future, by replacing its most obsolete component. But most importantly, you put it as if Apache releases are totally uncontrollable and anybody can sneak into it anything they want. But you know well that's not the case, as we use proper releases of other projects and all skinning is done here. Additionally, every release is voted. So there's no chance of any misuse at the release time and once it's released it can't be changed. What happens when a project we use loses its track? We deal with that at that point (find a replacement, fork and continue developing, etc.) and it's the same for Spring, Jetty, HawtIO or any other part. So the risk of losing control is not valid neither from technical nor project image standpoint. 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 Tue, Jan 21, 2014 at 11:16 PM, Gary Tully gary.tu...@gmail.com wrote: inline On 21 January 2014 17:36, Daniel Kulp dk...@apache.org wrote: On Jan 21, 2014, at 12:07 PM, Gary Tully gary.tu...@gmail.com wrote: On 21 January 2014 16:30, Daniel Kulp dk...@apache.org wrote: 2) All the ActiveMQ related code needs to be moved into the ActiveMQ project. If someone is using ActiveMQ and wants to contribute changes to how the console looks or displays items or such, they should be making contributions to ActiveMQ, not some external community (open source, free, or otherwise). The hawt.io “framework” of libraries and such can remain outside, but the ActiveMQ specific portions needs to be part of this community. If it’s going to be the visible frontend of this project, we need to make sure it drives the developer willing to contribute enhancements into ActiveMQ. This is putting the cart before the horse! If we need some changes and if we can't make contributions to hawtio (patches, issues etc) we can deal with that by building our own plugin or throwing it out or whatever. But why do that now? You are basically asking THIS developer community to completely give up control over how ActiveMQ is presented to the users to a different community. I personally cannot think of anything much worse for this community than that. That seems like a horrible idea from an Apache community standpoint. That is not what I am asking. How can choosing to adopt a better solution to an open problem be giving up control? We can always change our minds and throw it out if it does not serve our needs. The PMC will always be in control of what is released. The goals of the Apache communities needs to be to make sure developers are driven into the Apache communities, not another community. Any goal that hopes to drive developers is a non starter. Developers choose, they are not driven. I am suggesting we make a sensible choice that helps our community by giving it a better web ui. hawtio wants to have the best activemq web console, we want to ship the best activemq console. The stars are aligned. If the alignment falters we address that. We don't have to own everything that makes activemq better and that makes our users experience better, we just have to ensure that it is better. Making the user experience better is certainly an important aspect of the Apache communities, but the primary focus should be on making sure the developer community is healthy and we aren’t driving potential developers elsewhere. That NEEDS to be the most important thing at this point, especially with the current active makeup of this community. In particular, since Apache is a 503b charitable non-profit foundation, we cannot be used to promote other communities, particularly those “owned” by a for-profit entity. (open source or otherwise, that’s somewhat irrelevant) Anyway, as far as *I’m* concerned (but I’m not a member of this PMC, just an interested party), if the hawt.io community is unwilling or unable to support the ActiveMQ community to allow ActiveMQ to maintain control over it’s user experience, then there is no-point engaging with them. It is a waste of time. That said, if hawt.io community want to create a full distribution of ActiveMQ + hawt.io to make life easier for users, they certainly are welcome to do so as long as it’s not branded ActiveMQ. (and again, not something to be promoted here) Dan If the hawt.io community is unwilling (or unable) to do the second part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then great. Lets start figuring out how to get that done. But that’s something that would need to be discussed on
[jira] [Created] (AMQ-4986) tightEncoding=false + failover triggers Broker memory exhaust
Felix Ehm created AMQ-4986:
--
Summary: tightEncoding=false + failover triggers Broker memory
exhaust
Key: AMQ-4986
URL: https://issues.apache.org/jira/browse/AMQ-4986
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0, 5.8.0, 5.7.0, 5.6.0
Environment: java 1.7
Client library 5.5.1
Reporter: Felix Ehm
Priority: Blocker
Fix For: 5.10.0
We experience this problem in combination with 5.5.1 client and the
tightEncodingEnabled=true.
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport: tcp:///10.18.3.97:60156@61616]
DEBUG Transport Transport Connection to: tcp://10.18.3.97:60156 failed:
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException {
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our case the dadaIn.readInt() read an int number of 785.477.224 which
triggers the broker to allocate blindly this amount of mem.
We do not know yet what triggers the wrong byte sequence from the client, but
on the brokers side, there should be a protection against this case.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (AMQ-4986) tightEncoding=false + failover triggers Broker memory exhaust
[
https://issues.apache.org/jira/browse/AMQ-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Ehm updated AMQ-4986:
---
Priority: Critical (was: Blocker)
tightEncoding=false + failover triggers Broker memory exhaust
-
Key: AMQ-4986
URL: https://issues.apache.org/jira/browse/AMQ-4986
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.6.0, 5.7.0, 5.8.0, 5.9.0
Environment: java 1.7
Client library 5.5.1
Reporter: Felix Ehm
Priority: Critical
Fix For: 5.10.0
We experience this problem in combination with 5.5.1 client and the
tightEncodingEnabled=true.
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport: tcp:///10.18.3.97:60156@61616]
DEBUG Transport Transport Connection to: tcp://10.18.3.97:60156 failed:
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError:
Java heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError:
Java heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException
{
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our case the dadaIn.readInt() read an int number of 785.477.224 which
triggers the broker to allocate blindly this amount of mem.
We do not know yet what triggers the wrong byte sequence from the client, but
on the brokers side, there should be a protection against this case.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (AMQ-4986) tightEncoding=false + failover triggers Broker memory exhaust
[
https://issues.apache.org/jira/browse/AMQ-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Ehm updated AMQ-4986:
---
Description:
We experience this problem in combination with 5.5.1 client and the
wireformat.tightEncodingEnabled=true + failover:
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener) with failover protocol: e.g.
failover:(tcp://123.123.123.123:61616?wireformat.tightEncodingEnabled=true)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport: tcp:///10.18.3.97:60156@61616]
DEBUG Transport Transport Connection to: tcp://10.18.3.97:60156 failed:
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException {
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our case the dadaIn.readInt() read an int number of 785.477.224 which
triggers the broker to allocate blindly this amount of mem.
We do not know yet what triggers the wrong byte sequence from the client, but
on the brokers side, there should be a protection against this case.
was:
We experience this problem in combination with 5.5.1 client and the
tightEncodingEnabled=true.
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport: tcp:///10.18.3.97:60156@61616]
DEBUG Transport Transport Connection to: tcp://10.18.3.97:60156 failed:
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException {
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our case the dadaIn.readInt() read an int number of 785.477.224 which
triggers the broker to allocate blindly this amount of mem.
[jira] [Updated] (AMQ-4986) tightEncoding=false + failover triggers Broker memory exhaust
[
https://issues.apache.org/jira/browse/AMQ-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Ehm updated AMQ-4986:
---
Description:
We experience this problem in combination with 5.5.1 client and the
wireformat.tightEncodingEnabled=false+ failover:
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener) with failover protocol: e.g.
failover:(tcp://123.123.123.123:61616?wireformat.tightEncodingEnabled=true)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport: tcp:///10.18.3.97:60156@61616]
DEBUG Transport Transport Connection to: tcp://10.18.3.97:60156 failed:
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException {
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our case the dadaIn.readInt() read an int number of 785.477.224 which
triggers the broker to allocate blindly this amount of mem.
We do not know yet what triggers the wrong byte sequence from the client, but
on the brokers side, there should be a protection against this case.
was:
We experience this problem in combination with 5.5.1 client and the
wireformat.tightEncodingEnabled=true + failover:
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener) with failover protocol: e.g.
failover:(tcp://123.123.123.123:61616?wireformat.tightEncodingEnabled=true)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport: tcp:///10.18.3.97:60156@61616]
DEBUG Transport Transport Connection to: tcp://10.18.3.97:60156 failed:
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException {
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our
[jira] [Updated] (AMQ-4986) tightEncoding=false + failover triggers Broker memory exhaust
[
https://issues.apache.org/jira/browse/AMQ-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Ehm updated AMQ-4986:
---
Description:
We experience this problem in combination with 5.5.1 client and the
wireformat.tightEncodingEnabled=false+ failover:
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener) with failover protocol: e.g.
failover:(tcp://123.123.123.123:61616?wireformat.tightEncodingEnabled=false)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport:
tcp:///123.123.123.123:60156@61616] DEBUG Transport Transport Connection to:
tcp://124.124.124.124:60156 failed: java.io.IOException: Unexpected error
occured: java.lang.OutOfMemoryError: Java heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException {
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our case the dadaIn.readInt() read an int number of 785.477.224 which
triggers the broker to allocate blindly this amount of mem.
We do not know yet what triggers the wrong byte sequence from the client, but
on the brokers side, there should be a protection against this case.
was:
We experience this problem in combination with 5.5.1 client and the
wireformat.tightEncodingEnabled=false+ failover:
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener) with failover protocol: e.g.
failover:(tcp://123.123.123.123:61616?wireformat.tightEncodingEnabled=false)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport: tcp:///10.18.3.97:60156@61616]
DEBUG Transport Transport Connection to: tcp://10.18.3.97:60156 failed:
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError: Java
heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException {
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
[jira] [Created] (AMQ-4987) io wait on replicated levelDB slaves
anselme dewavrin created AMQ-4987: - Summary: io wait on replicated levelDB slaves Key: AMQ-4987 URL: https://issues.apache.org/jira/browse/AMQ-4987 Project: ActiveMQ Issue Type: Test Components: activemq-leveldb-store Affects Versions: 5.9.0 Environment: debian VM 2.6.32-5-amd64, jdk7 Reporter: anselme dewavrin Priority: Minor Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster as explained on the activemq site. I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 600 messages/s). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Many thanks in advance Yours, Anselme -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQNET-467) Strange behaviour on connect with invalid credentials
Markus Karolus created AMQNET-467: - Summary: Strange behaviour on connect with invalid credentials Key: AMQNET-467 URL: https://issues.apache.org/jira/browse/AMQNET-467 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ, NMS Affects Versions: 1.6.2 Reporter: Markus Karolus Assignee: Jim Gomes Priority: Minor When I try to connect AMQ with invalid credentials I get an EndOfStreamException (Unable to read beyond the end of the stream) instead of an NMSSecurityException (BrokerError: java.lang.SecurityException: User name [***] or password is invalid). With the changes for AMQNET-360 the behaviour in the ResponseCorrelator has been changed. With the removing of the exception handling the ExceptionResponse with the Security-Exception will not be handled any more. Simple reproduction: TestRestartInvalidCredentialsWithFailover doesn't work -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [POLL] - Remove the old ActiveMQ Console
So why didn't you guys work on this console in-house? On Wednesday, January 22, 2014, Dejan Bosanac de...@nighttale.net wrote: In my opinion, this control issue is totally overblown. First of all, we're not some newcomers trying to put a malware into the project. We're people that are developing this project for the last 5-7 years and are trying to position it better for the future, by replacing its most obsolete component. But most importantly, you put it as if Apache releases are totally uncontrollable and anybody can sneak into it anything they want. But you know well that's not the case, as we use proper releases of other projects and all skinning is done here. Additionally, every release is voted. So there's no chance of any misuse at the release time and once it's released it can't be changed. What happens when a project we use loses its track? We deal with that at that point (find a replacement, fork and continue developing, etc.) and it's the same for Spring, Jetty, HawtIO or any other part. So the risk of losing control is not valid neither from technical nor project image standpoint. Regards -- Dejan Bosanac -- Red Hat, Inc. FuseSource is now part of Red Hat dbosa...@redhat.com javascript:; Twitter: @dejanb Blog: http://sensatic.net ActiveMQ in Action: http://www.manning.com/snyder/ On Tue, Jan 21, 2014 at 11:16 PM, Gary Tully gary.tu...@gmail.com wrote: inline On 21 January 2014 17:36, Daniel Kulp dk...@apache.org wrote: On Jan 21, 2014, at 12:07 PM, Gary Tully gary.tu...@gmail.com wrote: On 21 January 2014 16:30, Daniel Kulp dk...@apache.org wrote: 2) All the ActiveMQ related code needs to be moved into the ActiveMQ project. If someone is using ActiveMQ and wants to contribute changes to how the console looks or displays items or such, they should be making contributions to ActiveMQ, not some external community (open source, free, or otherwise). The hawt.io “framework” of libraries and such can remain outside, but the ActiveMQ specific portions needs to be part of this community. If it’s going to be the visible frontend of this project, we need to make sure it drives the developer willing to contribute enhancements into ActiveMQ. This is putting the cart before the horse! If we need some changes and if we can't make contributions to hawtio (patches, issues etc) we can deal with that by building our own plugin or throwing it out or whatever. But why do that now? You are basically asking THIS developer community to completely give up control over how ActiveMQ is presented to the users to a different community. I personally cannot think of anything much worse for this community than that. That seems like a horrible idea from an Apache community standpoint. That is not what I am asking. How can choosing to adopt a better solution to an open problem be giving up control? We can always change our minds and throw it out if it does not serve our needs. The PMC will always be in control of what is released. The goals of the Apache communities needs to be to make sure developers are driven into the Apache communities, not another community. Any goal that hopes to drive developers is a non starter. Developers choose, they are not driven. I am suggesting we make a sensible choice that helps our community by giving it a better web ui. hawtio wants to have the best activemq web console, we want to ship the best activemq console. The stars are aligned. If the alignment falters we address that. We don't have to own everything that makes activemq better and that makes our users experience better, we just have to ensure that it is better. Making the user experience better is certainly an important aspect of the Apache communities, but the primary focus should be on making sure the developer community is healthy and we aren’t driving potential developers elsewhere. That NEEDS to be the most important thing at this point, especially with the current active makeup of this community. In particular, since Apache is a 503b charitable non-profit foundation, we cannot be used to promote other communities, particularly those “owned” by a for-profit entity. (open source or otherwise, that’s somewhat irrelevant) Anyway, as far as *I’m* concerned (but I’m not a member of this PMC, just an interested party), if the hawt.io community is unwilling or unable to support the ActiveMQ community to allow ActiveMQ to maintain control over it’s user experience, then there is no-point engaging with them. It is a waste of time. That said, if hawt.io community want to create a full distribution of ActiveMQ + hawt.io to make life easier for users, they certainly are welcome to do so as long as it’s not branded ActiveMQ. (and again, not something to be promoted here) Dan If the hawt.io
[jira] [Commented] (AMQ-4986) tightEncoding=false + failover triggers Broker memory exhaust
[
https://issues.apache.org/jira/browse/AMQ-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878708#comment-13878708
]
Timothy Bish commented on AMQ-4986:
---
Are you mixing old versions of clients with newer broker versions ?
tightEncoding=false + failover triggers Broker memory exhaust
-
Key: AMQ-4986
URL: https://issues.apache.org/jira/browse/AMQ-4986
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.6.0, 5.7.0, 5.8.0, 5.9.0
Environment: java 1.7
Client library 5.5.1
Reporter: Felix Ehm
Priority: Critical
Fix For: 5.10.0
We experience this problem in combination with 5.5.1 client and the
wireformat.tightEncodingEnabled=false+ failover:
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener) with failover protocol: e.g.
failover:(tcp://123.123.123.123:61616?wireformat.tightEncodingEnabled=false)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport:
tcp:///123.123.123.123:60156@61616] DEBUG Transport Transport Connection to:
tcp://124.124.124.124:60156 failed: java.io.IOException: Unexpected error
occured: java.lang.OutOfMemoryError: Java heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError:
Java heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException
{
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our case the dadaIn.readInt() read an int number of 785.477.224 which
triggers the broker to allocate blindly this amount of mem.
We do not know yet what triggers the wrong byte sequence from the client, but
on the brokers side, there should be a protection against this case.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (AMQ-4985) java.util.ConcurrentModificationException while sending message
[ https://issues.apache.org/jira/browse/AMQ-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878711#comment-13878711 ] Timothy Bish commented on AMQ-4985: --- Do you have a test case? Have you tried moving to a newer broker version? At this point 5.6 is pretty ancient. java.util.ConcurrentModificationException while sending message --- Key: AMQ-4985 URL: https://issues.apache.org/jira/browse/AMQ-4985 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 5.6.0 Reporter: Sateesh Kapu Caused by: java.util.ConcurrentModificationException: null at java.util.ArrayList.writeObject(Unknown Source) ~[na:1.7.0_11] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_11] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[na:1.7.0_11] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[na:1.7.0_11] at java.lang.reflect.Method.invoke(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeSerialData(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeObject0(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeSerialData(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeObject0(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeSerialData(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeObject0(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeSerialData(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeObject0(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeObject(Unknown Source) ~[na:1.7.0_11] at org.apache.activemq.command.ActiveMQObjectMessage.storeContent(ActiveMQObjectMessage.java:106) ~[na:na] at org.apache.activemq.command.ActiveMQObjectMessage.setObject(ActiveMQObjectMessage.java:163) ~[na:na] at org.apache.activemq.ActiveMQSession.createObjectMessage(ActiveMQSession.java:381) ~[bundlefile:5.8.0] at org.apache.activemq.ra.ManagedSessionProxy.createObjectMessage(ManagedSessionProxy.java:220) ~[na:na] at org.springframework.jms.support.converter.SimpleMessageConverter.createMessageForSerializable(SimpleMessageConverter.java:166) ~[na:na] at org.springframework.jms.support.converter.SimpleMessageConverter.toMessage(SimpleMessageConverter.java:73) ~[na:na] at org.springframework.jms.core.JmsTemplate$6.createMessage(JmsTemplate.java:622) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:565) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate$4.doInJms(JmsTemplate.java:546) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:466) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:543) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:620) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:607) ~[bundlefile:3.0.6.RELEASE] -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-4988) Possible case of curroption in Scheduler store
Timothy Bish created AMQ-4988: - Summary: Possible case of curroption in Scheduler store Key: AMQ-4988 URL: https://issues.apache.org/jira/browse/AMQ-4988 Project: ActiveMQ Issue Type: Bug Components: Job Scheduler Affects Versions: 5.9.0, 5.8.0 Reporter: Timothy Bish Priority: Minor Fix For: 5.10.0 A potential point of store corruption exists where the journal files can be removed for some jobs before the index is updated. If the broker failed before the index update occurs the store could restart with index entries that map to journal files that no longer exist. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-4986) tightEncoding=false + failover triggers Broker memory exhaust
[
https://issues.apache.org/jira/browse/AMQ-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878723#comment-13878723
]
Felix Ehm commented on AMQ-4986:
Yes. We have a very large environment with 200 applications where we are not
in the situation to be able to update client and broker setups always together
(all openwire).
According to Hiram this mixing should be ok and from my understanding the
openwire protocol should at least make sure the communication is fine. But
exactly here is the point where it breaks.
As I wrote, we're still trying to find out why the broker reads something
buggy from the wire from the client.
Did I mention that the client and broker come into a CON/DISCON loop ? The
client-side failover receives a invalid magic back and closes the connection,
and reconnects, and so on
The workaround of course is to remove this option, which I strongly consider.
Independently from this, the presented code should be looked at to prevent this
allocation. What do you think?
tightEncoding=false + failover triggers Broker memory exhaust
-
Key: AMQ-4986
URL: https://issues.apache.org/jira/browse/AMQ-4986
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.6.0, 5.7.0, 5.8.0, 5.9.0
Environment: java 1.7
Client library 5.5.1
Reporter: Felix Ehm
Priority: Critical
Fix For: 5.10.0
We experience this problem in combination with 5.5.1 client and the
wireformat.tightEncodingEnabled=false+ failover:
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener) with failover protocol: e.g.
failover:(tcp://123.123.123.123:61616?wireformat.tightEncodingEnabled=false)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport:
tcp:///123.123.123.123:60156@61616] DEBUG Transport Transport Connection to:
tcp://124.124.124.124:60156 failed: java.io.IOException: Unexpected error
occured: java.lang.OutOfMemoryError: Java heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError:
Java heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException
{
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our case the dadaIn.readInt() read an int number of 785.477.224 which
triggers the broker to allocate blindly this amount of mem.
We do not know yet what triggers the wrong byte sequence from the client, but
on the brokers side, there should be a protection against this case.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (AMQ-4988) Possible case of curroption in Scheduler store
[ https://issues.apache.org/jira/browse/AMQ-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-4988. --- Resolution: Fixed Possible case of curroption in Scheduler store -- Key: AMQ-4988 URL: https://issues.apache.org/jira/browse/AMQ-4988 Project: ActiveMQ Issue Type: Bug Components: Job Scheduler Affects Versions: 5.8.0, 5.9.0 Reporter: Timothy Bish Priority: Minor Fix For: 5.10.0 A potential point of store corruption exists where the journal files can be removed for some jobs before the index is updated. If the broker failed before the index update occurs the store could restart with index entries that map to journal files that no longer exist. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQNET-467) Strange behaviour on connect with invalid credentials
[ https://issues.apache.org/jira/browse/AMQNET-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQNET-467: Fix Version/s: 1.7.0 1.6.3 Strange behaviour on connect with invalid credentials - Key: AMQNET-467 URL: https://issues.apache.org/jira/browse/AMQNET-467 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ, NMS Affects Versions: 1.6.2 Reporter: Markus Karolus Assignee: Timothy Bish Priority: Minor Labels: security Fix For: 1.6.3, 1.7.0 When I try to connect AMQ with invalid credentials I get an EndOfStreamException (Unable to read beyond the end of the stream) instead of an NMSSecurityException (BrokerError: java.lang.SecurityException: User name [***] or password is invalid). With the changes for AMQNET-360 the behaviour in the ResponseCorrelator has been changed. With the removing of the exception handling the ExceptionResponse with the Security-Exception will not be handled any more. Simple reproduction: TestRestartInvalidCredentialsWithFailover doesn't work -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (AMQNET-467) Strange behaviour on connect with invalid credentials
[ https://issues.apache.org/jira/browse/AMQNET-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reassigned AMQNET-467: --- Assignee: Timothy Bish (was: Jim Gomes) Strange behaviour on connect with invalid credentials - Key: AMQNET-467 URL: https://issues.apache.org/jira/browse/AMQNET-467 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ, NMS Affects Versions: 1.6.2 Reporter: Markus Karolus Assignee: Timothy Bish Priority: Minor Labels: security Fix For: 1.6.3, 1.7.0 When I try to connect AMQ with invalid credentials I get an EndOfStreamException (Unable to read beyond the end of the stream) instead of an NMSSecurityException (BrokerError: java.lang.SecurityException: User name [***] or password is invalid). With the changes for AMQNET-360 the behaviour in the ResponseCorrelator has been changed. With the removing of the exception handling the ExceptionResponse with the Security-Exception will not be handled any more. Simple reproduction: TestRestartInvalidCredentialsWithFailover doesn't work -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [POLL] - Remove the old ActiveMQ Console
On Jan 21, 2014, at 5:16 PM, Gary Tully gary.tu...@gmail.com wrote: inline On 21 January 2014 17:36, Daniel Kulp dk...@apache.org wrote: The goals of the Apache communities needs to be to make sure developers are driven into the Apache communities, not another community. Any goal that hopes to drive developers is a non starter. Developers choose, they are not driven. That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ. If I’m in the *ActiveMQ* console provided/endorsed by the ActiveMQ community and I see that my message is displaying wrong or the data isn’t displaying correctly or the column sizes aren’t taking things into consideration properly or similar, then I, as a developer, completely expect that I can contribute patches to ActiveMQ to fix that. Again, the download needs to drive developers to ActiveMQ, not an external community. Also, the documentation around how to use what is provided by ActiveMQ needs to be on the ActiveMQ web site. Any errors in that documentation should be handled by the ActiveMQ community. Patches for the documentation should go through ActiveMQ’s process. Dan I am suggesting we make a sensible choice that helps our community by giving it a better web ui. hawtio wants to have the best activemq web console, we want to ship the best activemq console. The stars are aligned. If the alignment falters we address that. We don't have to own everything that makes activemq better and that makes our users experience better, we just have to ensure that it is better. Making the user experience better is certainly an important aspect of the Apache communities, but the primary focus should be on making sure the developer community is healthy and we aren’t driving potential developers elsewhere. That NEEDS to be the most important thing at this point, especially with the current active makeup of this community. In particular, since Apache is a 503b charitable non-profit foundation, we cannot be used to promote other communities, particularly those “owned” by a for-profit entity. (open source or otherwise, that’s somewhat irrelevant) Anyway, as far as *I’m* concerned (but I’m not a member of this PMC, just an interested party), if the hawt.io community is unwilling or unable to support the ActiveMQ community to allow ActiveMQ to maintain control over it’s user experience, then there is no-point engaging with them. It is a waste of time. That said, if hawt.io community want to create a full distribution of ActiveMQ + hawt.io to make life easier for users, they certainly are welcome to do so as long as it’s not branded ActiveMQ. (and again, not something to be promoted here) Dan If the hawt.io community is unwilling (or unable) to do the second part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then great. Lets start figuring out how to get that done. But that’s something that would need to be discussed on their side first. Dan On Jan 21, 2014, at 10:55 AM, Gary Tully gary.tu...@gmail.com wrote: There are a lot of 0s and +1s for option [3] and two -1s Let me make a case for it to try and get consensus around it. I want to 'replace' the existing web console with something better. For configuration activemq did not build a dependency injection framework, we shipped spring. Learning from that, it does not make sense to me that we build and maintain a html5 web console. An admin/management web front end based over our extensive JMX api sounds perfect but it needs a community to evolve and improve it. We (activemq committers) have proven that we need help in that area. Anyone what to change their vote or further expand on the technical reasons we should not be branding hatwio? On 17 January 2014 13:33, Robert Davies rajdav...@gmail.com wrote: I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ? 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones). 2. Have two separate distributions, one with no console - and have a second distribution with the original console 3. One distribution, with hawtio as the console - ActiveMQ branded. 4. One distribution, but uses the original ActiveMQ console only. Here’s my vote: [1]. +1 [2] 0 [3] 0 [4] -1 thanks,
[jira] [Resolved] (AMQNET-467) Strange behaviour on connect with invalid credentials
[ https://issues.apache.org/jira/browse/AMQNET-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQNET-467. - Resolution: Fixed Fixed on trunk and 1.6.x fixes branch Strange behaviour on connect with invalid credentials - Key: AMQNET-467 URL: https://issues.apache.org/jira/browse/AMQNET-467 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ, NMS Affects Versions: 1.6.2 Reporter: Markus Karolus Assignee: Timothy Bish Priority: Minor Labels: security Fix For: 1.6.3, 1.7.0 When I try to connect AMQ with invalid credentials I get an EndOfStreamException (Unable to read beyond the end of the stream) instead of an NMSSecurityException (BrokerError: java.lang.SecurityException: User name [***] or password is invalid). With the changes for AMQNET-360 the behaviour in the ResponseCorrelator has been changed. With the removing of the exception handling the ExceptionResponse with the Security-Exception will not be handled any more. Simple reproduction: TestRestartInvalidCredentialsWithFailover doesn't work -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [POLL] - Remove the old ActiveMQ Console
On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp dk...@apache.org wrote: That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ. If this is true then we should not be using ANY 3rd party libs at all. Most users cannot tell where the line is between 3rd party libs and ActiveMQ's source. The ActiveMQ project is ultimately responsible for all functionality shipped (if its 3rd party or not). If it's a 3rd party defect then the ActiveMQ project needs to either work around the defect, patch the defect in the 3rd party library or work with the 3rd party to fix the defect. All 3 approaches are possible with hawtio too. -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
Mqtt messages
In what Persistence I can find MQTT messages? Does it write to any bases or jornals? -- View this message in context: http://activemq.2283324.n4.nabble.com/Mqtt-messages-tp4676634.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] [Commented] (AMQ-4970) Deletion of a queue inaffective across broker restart
[ https://issues.apache.org/jira/browse/AMQ-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879017#comment-13879017 ] james commented on AMQ-4970: Actually, i may have figured this out myself. topics don't seem to be reloaded at startup like queues. Deletion of a queue inaffective across broker restart - Key: AMQ-4970 URL: https://issues.apache.org/jira/browse/AMQ-4970 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Environment: mac osx/mavericks Reporter: Arthur Naseef Fix For: 5.10.0 Attachments: AMQ4970Test.zip, AMQ4970Test.zip, AMQ4970Test.zip, amq4970.patch Deleting a queue, it is revived from persistent store after a broker restart. The following steps reproduce the problem: * Create a queue (confirmed using the REST client I/F) * Shutdown the broker * Startup the broker * Confirm queue still exists via the hawtio ui (correct operation so far) * Delete the queue * Confirm queue removed via the hawtio ui * Shutdown the broker * Startup the broker * Confirm queue was not recreated via hawtio ui (failed: queue still exists) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-4985) java.util.ConcurrentModificationException while sending message
[ https://issues.apache.org/jira/browse/AMQ-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879102#comment-13879102 ] Sateesh Kapu commented on AMQ-4985: --- I don't have the simple test case. This is not consistent and seen when we do our server upgrade process which might be causing bunch of messages to published to its subscribers. We can move to latest version but our product is in final stages for release. We might update to latest version only for next release of our product. Can you help with any workaround to avoid concurrent modification exception. java.util.ConcurrentModificationException while sending message --- Key: AMQ-4985 URL: https://issues.apache.org/jira/browse/AMQ-4985 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 5.6.0 Reporter: Sateesh Kapu Caused by: java.util.ConcurrentModificationException: null at java.util.ArrayList.writeObject(Unknown Source) ~[na:1.7.0_11] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_11] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[na:1.7.0_11] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[na:1.7.0_11] at java.lang.reflect.Method.invoke(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeSerialData(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeObject0(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeSerialData(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeObject0(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeSerialData(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeObject0(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeSerialData(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeObject0(Unknown Source) ~[na:1.7.0_11] at java.io.ObjectOutputStream.writeObject(Unknown Source) ~[na:1.7.0_11] at org.apache.activemq.command.ActiveMQObjectMessage.storeContent(ActiveMQObjectMessage.java:106) ~[na:na] at org.apache.activemq.command.ActiveMQObjectMessage.setObject(ActiveMQObjectMessage.java:163) ~[na:na] at org.apache.activemq.ActiveMQSession.createObjectMessage(ActiveMQSession.java:381) ~[bundlefile:5.8.0] at org.apache.activemq.ra.ManagedSessionProxy.createObjectMessage(ManagedSessionProxy.java:220) ~[na:na] at org.springframework.jms.support.converter.SimpleMessageConverter.createMessageForSerializable(SimpleMessageConverter.java:166) ~[na:na] at org.springframework.jms.support.converter.SimpleMessageConverter.toMessage(SimpleMessageConverter.java:73) ~[na:na] at org.springframework.jms.core.JmsTemplate$6.createMessage(JmsTemplate.java:622) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:565) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate$4.doInJms(JmsTemplate.java:546) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:466) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:543) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:620) ~[bundlefile:3.0.6.RELEASE] at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:607) ~[bundlefile:3.0.6.RELEASE] -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQ-4899) Multiple consumers of the same virtual topic queue cannot have different message selectors
[ https://issues.apache.org/jira/browse/AMQ-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-4899: -- Fix Version/s: NEEDS_REVIEWED Multiple consumers of the same virtual topic queue cannot have different message selectors -- Key: AMQ-4899 URL: https://issues.apache.org/jira/browse/AMQ-4899 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.x Reporter: Ralph McNeal Priority: Minor Fix For: NEEDS_REVIEWED If two consumers of the same virtual topic queue have different message selectors, only one selector gets cached via the SubQueueSelectorCacheBroker.java. The problem is when the consumers are offline. Because the cache only caches one selector, the broker will only allow messages that pass the cached selector to be put in the queue. All other messages that may be intended for the other consumer will be lost. The fix would allow multiple selectors to be cached per Virtual Topic Consumer queue vs. one. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQ-4986) tightEncoding=false + failover triggers Broker memory exhaust
[
https://issues.apache.org/jira/browse/AMQ-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated AMQ-4986:
--
Priority: Major (was: Critical)
tightEncoding=false + failover triggers Broker memory exhaust
-
Key: AMQ-4986
URL: https://issues.apache.org/jira/browse/AMQ-4986
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.6.0, 5.7.0, 5.8.0, 5.9.0
Environment: java 1.7
Client library 5.5.1
Reporter: Felix Ehm
Fix For: NEEDS_REVIEWED
We experience this problem in combination with 5.5.1 client and the
wireformat.tightEncodingEnabled=false+ failover:
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener) with failover protocol: e.g.
failover:(tcp://123.123.123.123:61616?wireformat.tightEncodingEnabled=false)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport:
tcp:///123.123.123.123:60156@61616] DEBUG Transport Transport Connection to:
tcp://124.124.124.124:60156 failed: java.io.IOException: Unexpected error
occured: java.lang.OutOfMemoryError: Java heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError:
Java heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException
{
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our case the dadaIn.readInt() read an int number of 785.477.224 which
triggers the broker to allocate blindly this amount of mem.
We do not know yet what triggers the wrong byte sequence from the client, but
on the brokers side, there should be a protection against this case.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (AMQ-4986) tightEncoding=false + failover triggers Broker memory exhaust
[
https://issues.apache.org/jira/browse/AMQ-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated AMQ-4986:
--
Fix Version/s: (was: 5.10.0)
NEEDS_REVIEWED
tightEncoding=false + failover triggers Broker memory exhaust
-
Key: AMQ-4986
URL: https://issues.apache.org/jira/browse/AMQ-4986
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.6.0, 5.7.0, 5.8.0, 5.9.0
Environment: java 1.7
Client library 5.5.1
Reporter: Felix Ehm
Fix For: NEEDS_REVIEWED
We experience this problem in combination with 5.5.1 client and the
wireformat.tightEncodingEnabled=false+ failover:
Scenario:
1. start standard broker
2. start Client (with e.g. a MessageListener) with failover protocol: e.g.
failover:(tcp://123.123.123.123:61616?wireformat.tightEncodingEnabled=false)
3. wait around 30sec (default for inactivity check)
Result:
The client closes the connection and re-tries to the broker which in turn
throws the following exception:
{code}
2014-01-21 20:12:49,568 [ActiveMQ Transport:
tcp:///123.123.123.123:60156@61616] DEBUG Transport Transport Connection to:
tcp://124.124.124.124:60156 failed: java.io.IOException: Unexpected error
occured: java.lang.OutOfMemoryError: Java heap space
java.io.IOException: Unexpected error occured: java.lang.OutOfMemoryError:
Java heap space
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
at
org.apache.activemq.openwire.v8.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
at
org.apache.activemq.openwire.v8.WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:373)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:285)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
... 1 more
{code}
The problem here is that the BaseDataStreamMarshaller reads an int from the
buffer and re-uses it immediately to allocate a byte array:
{code}
protected byte[] looseUnmarshalByteArray(DataInput dataIn) throws IOException
{
byte rc[] = null;
if (dataIn.readBoolean()) {
int size = dataIn.readInt();
rc = new byte[size]; // PROBLEM! What happens if size has been
read and interpreted wrongly ?
dataIn.readFully(rc);
}
return rc;
}
{code}
In our case the dadaIn.readInt() read an int number of 785.477.224 which
triggers the broker to allocate blindly this amount of mem.
We do not know yet what triggers the wrong byte sequence from the client, but
on the brokers side, there should be a protection against this case.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (AMQ-4899) Multiple consumers of the same virtual topic queue cannot have different message selectors
[ https://issues.apache.org/jira/browse/AMQ-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-4899: -- Priority: Minor (was: Major) Multiple consumers of the same virtual topic queue cannot have different message selectors -- Key: AMQ-4899 URL: https://issues.apache.org/jira/browse/AMQ-4899 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.x Reporter: Ralph McNeal Priority: Minor If two consumers of the same virtual topic queue have different message selectors, only one selector gets cached via the SubQueueSelectorCacheBroker.java. The problem is when the consumers are offline. Because the cache only caches one selector, the broker will only allow messages that pass the cached selector to be put in the queue. All other messages that may be intended for the other consumer will be lost. The fix would allow multiple selectors to be cached per Virtual Topic Consumer queue vs. one. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-4970) Deletion of a queue inaffective across broker restart
[ https://issues.apache.org/jira/browse/AMQ-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879168#comment-13879168 ] Arthur Naseef commented on AMQ-4970: I think it's worth adding the protection - the extra processing only adds an infrequent operation that can only prevent problems. Deletion of a queue inaffective across broker restart - Key: AMQ-4970 URL: https://issues.apache.org/jira/browse/AMQ-4970 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Environment: mac osx/mavericks Reporter: Arthur Naseef Fix For: 5.10.0 Attachments: AMQ4970Test.zip, AMQ4970Test.zip, AMQ4970Test.zip, amq4970.patch Deleting a queue, it is revived from persistent store after a broker restart. The following steps reproduce the problem: * Create a queue (confirmed using the REST client I/F) * Shutdown the broker * Startup the broker * Confirm queue still exists via the hawtio ui (correct operation so far) * Delete the queue * Confirm queue removed via the hawtio ui * Shutdown the broker * Startup the broker * Confirm queue was not recreated via hawtio ui (failed: queue still exists) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [POLL] - Remove the old ActiveMQ Console
This whole then we shouldn't use any 3rd party libraries argument is getting old, Hiram. You know there's a difference between using a library behind the scenes and the entire web console itself that the users interact with directly. Come on, man. Give it up. On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino hi...@hiramchirino.com wrote: On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp dk...@apache.org wrote: That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ. If this is true then we should not be using ANY 3rd party libs at all. Most users cannot tell where the line is between 3rd party libs and ActiveMQ's source. The ActiveMQ project is ultimately responsible for all functionality shipped (if its 3rd party or not). If it's a 3rd party defect then the ActiveMQ project needs to either work around the defect, patch the defect in the 3rd party library or work with the 3rd party to fix the defect. All 3 approaches are possible with hawtio too. -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
Re: [POLL] - Remove the old ActiveMQ Console
Let's get the discussion back on track and try to reach some consensus. Without the hawt.io community donating the relevant ActiveMQ portions to the ASF we will not be able to get a consensus around proposal #3. Thus, that needs to be taken off the table. We have users specifically asking to retain the console. We also have people who have stepped up and volunteered to help enhancing the existing console. Thus, option #1 is off the table. This leaves #2 and #4. Out of the two, #4 is the status quo and has more support. The remaining question is if we want two distros or not? Cheers, Hadrian On 01/22/2014 04:47 PM, James Carman wrote: This whole then we shouldn't use any 3rd party libraries argument is getting old, Hiram. You know there's a difference between using a library behind the scenes and the entire web console itself that the users interact with directly. Come on, man. Give it up. On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino hi...@hiramchirino.com wrote: On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp dk...@apache.org wrote: That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ. If this is true then we should not be using ANY 3rd party libs at all. Most users cannot tell where the line is between 3rd party libs and ActiveMQ's source. The ActiveMQ project is ultimately responsible for all functionality shipped (if its 3rd party or not). If it's a 3rd party defect then the ActiveMQ project needs to either work around the defect, patch the defect in the 3rd party library or work with the 3rd party to fix the defect. All 3 approaches are possible with hawtio too. -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
Re: [POLL] - Remove the old ActiveMQ Console
I don't really see much of a difference. As long as the PMC is happy with the end product that we produce what's the problem? You don't like the way some UI element works? Then raise an ActiveMQ jira issue. We can follow the normal deficiency resolution processes to fix it. If you think we can't for some reason, I'd like to understand why you think that. Perhaps there some special ASF policy your talking about that I'm not aware of? If so, could you you provide me a pointer to where it's documented? On Wed, Jan 22, 2014 at 4:47 PM, James Carman ja...@carmanconsulting.com wrote: This whole then we shouldn't use any 3rd party libraries argument is getting old, Hiram. You know there's a difference between using a library behind the scenes and the entire web console itself that the users interact with directly. Come on, man. Give it up. On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino hi...@hiramchirino.com wrote: On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp dk...@apache.org wrote: That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ. If this is true then we should not be using ANY 3rd party libs at all. Most users cannot tell where the line is between 3rd party libs and ActiveMQ's source. The ActiveMQ project is ultimately responsible for all functionality shipped (if its 3rd party or not). If it's a 3rd party defect then the ActiveMQ project needs to either work around the defect, patch the defect in the 3rd party library or work with the 3rd party to fix the defect. All 3 approaches are possible with hawtio too. -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
Is skinning hawt.io enough to allow it be be packaged in ActiveMQ?
Starting up a new thread to avoid hijacking the original POLL thread. On Wed, Jan 22, 2014 at 5:29 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: Without the hawt.io community donating the relevant ActiveMQ portions to the ASF we will not be able to get a consensus around proposal #3. Thus, that needs to be taken off the table. I think that's a faulty assumption that needs to get discussed and addressed. Any hawtio UI that we package in the ActiveMQ will be reviewed by the PMC. Like any 3rd party library that we ship, it has to have an approved license and it's functionality has to be tested and verified by the ActiveMQ project. If we the PMC does not like some detail of hawtio we just need to open issues to address them and once it's to the PMC's liking we can then package it. This is no different from any other 3rd party lib we use so why are we treating it differently? -- Hiram Chirino
[jira] [Created] (AMQ-4989) Better protect worker thread in TcpTransportServer that handles socket accepts
Timothy Bish created AMQ-4989: - Summary: Better protect worker thread in TcpTransportServer that handles socket accepts Key: AMQ-4989 URL: https://issues.apache.org/jira/browse/AMQ-4989 Project: ActiveMQ Issue Type: Improvement Components: Transport Affects Versions: 5.9.0, 5.8.0, 5.7.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 5.10.0 The worker thread in the TcpTransportServer that handles socket accepts from a queue can die if the handle method allows a throwable to escape. We should catch these and log them as warn if the transport isn't stopping as this is unexpected and we don't want this thread to die and stop servicing incoming connections. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-4989) Better protect worker thread in TcpTransportServer that handles socket accepts
[ https://issues.apache.org/jira/browse/AMQ-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-4989. --- Resolution: Fixed Fix applied on trunk Better protect worker thread in TcpTransportServer that handles socket accepts -- Key: AMQ-4989 URL: https://issues.apache.org/jira/browse/AMQ-4989 Project: ActiveMQ Issue Type: Improvement Components: Transport Affects Versions: 5.7.0, 5.8.0, 5.9.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 5.10.0 The worker thread in the TcpTransportServer that handles socket accepts from a queue can die if the handle method allows a throwable to escape. We should catch these and log them as warn if the transport isn't stopping as this is unexpected and we don't want this thread to die and stop servicing incoming connections. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [POLL] - Remove the old ActiveMQ Console
Well, not all the PMC is happy. And you know full well that raising an AMQ JIRA issue won't help if the code is somewhere else. Sounds like the the options we can reach consensus on are #2 and #4. Let's focus on that. Hadrian On 01/22/2014 05:30 PM, Hiram Chirino wrote: I don't really see much of a difference. As long as the PMC is happy with the end product that we produce what's the problem? You don't like the way some UI element works? Then raise an ActiveMQ jira issue. We can follow the normal deficiency resolution processes to fix it. If you think we can't for some reason, I'd like to understand why you think that. Perhaps there some special ASF policy your talking about that I'm not aware of? If so, could you you provide me a pointer to where it's documented? On Wed, Jan 22, 2014 at 4:47 PM, James Carman ja...@carmanconsulting.com wrote: This whole then we shouldn't use any 3rd party libraries argument is getting old, Hiram. You know there's a difference between using a library behind the scenes and the entire web console itself that the users interact with directly. Come on, man. Give it up. On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino hi...@hiramchirino.com wrote: On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp dk...@apache.org wrote: That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ. If this is true then we should not be using ANY 3rd party libs at all. Most users cannot tell where the line is between 3rd party libs and ActiveMQ's source. The ActiveMQ project is ultimately responsible for all functionality shipped (if its 3rd party or not). If it's a 3rd party defect then the ActiveMQ project needs to either work around the defect, patch the defect in the 3rd party library or work with the 3rd party to fix the defect. All 3 approaches are possible with hawtio too.
Jenkins build is back to stable : ActiveMQ » ActiveMQ :: MQTT Protocol #1441
See https://builds.apache.org/job/ActiveMQ/org.apache.activemq$activemq-mqtt/1441/changes
Jenkins build is back to stable : ActiveMQ » ActiveMQ :: AMQP #1441
See https://builds.apache.org/job/ActiveMQ/org.apache.activemq$activemq-amqp/1441/changes
