You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Martyn Taylor <mt...@redhat.com> on 2015/05/13 19:12:11 UTC
[VOTE] Apache Artemis 1.0.0 (RC2)
Hello all.
I've cut a second release candidate of Apache Artemis 1.0.0 addressing
the initial RC feedback from community members.
This is a first release of the Artemis project with protocol support for
AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
The binary distributions can be found here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
The source archives can be found here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
The source tag:
https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
The project website for that version has been staged to:
http://people.apache.org/~martyntaylor/
The vote will remain open for 72 hours.
[ ] +1 approve the release as Apache Artemis 1.0.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Here's my (non-binding) +1
Regards
Martyn
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Howard Gao <ho...@gmail.com>.
＋1. Sorry for the late response. Regarding OpenWire support in this first
release, we have implemented a basic support of JMS clients. Non JMS
features (activemq extensions) and advanced features(like failover) are not
implemented yet. As OpenWire is not the core protocol which should have
'all' the functionalities claimed in the first release, so I don't think we
need to block the release for bugs/features in openwire support. Here is
the documentation in artemis that describes the openwire support for the
users:
https://github.com/apache/activemq-artemis/blob/master/docs/user-manual/en/interoperability.md#openwire
Regards
Howard
On Wed, May 20, 2015 at 6:44 PM, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 13 May 2015 at 18:12, Martyn Taylor <mt...@redhat.com> wrote:
> > Hello all.
> >
> > I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> > initial RC feedback from community members.
> >
> > This is a first release of the Artemis project with protocol support for
> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >
> > The release notes can be found here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >
> > The binary distributions can be found here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The source archives can be found here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The Maven repository is here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >
> > The source tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >
> > The project website for that version has been staged to:
> > http://people.apache.org/~martyntaylor/
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1 approve the release as Apache Artemis 1.0.0
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my (non-binding) +1
> >
> > Regards
> > Martyn
>
> I gave the src and bin tar.gz files a kick and didnt notice any issues
> of note beyond those already discussed.
>
> Robbie
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 13 May 2015 at 18:12, Martyn Taylor <mt...@redhat.com> wrote:
> Hello all.
>
> I've cut a second release candidate of Apache Artemis 1.0.0 addressing the
> initial RC feedback from community members.
>
> This is a first release of the Artemis project with protocol support for
> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>
> The binary distributions can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
> The source archives can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>
> The source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.0.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
> Martyn
I gave the src and bin tar.gz files a kick and didnt notice any issues
of note beyond those already discussed.
Robbie
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Clebert <cl...@gmail.com>.
Sent from my iPad
> On May 14, 2015, at 11:05, Jim Gomes <e....@gmail.com> wrote:
>
> -1
>
> Two reasons:
>
> 1. The default configuration of localhost for the broker does not allow
> connections from off-machine. For some reason, socket connections are
> refused from non-local clients. I had to change the broker.xml config to
> use the machine's actual IP address, and then non-local clients could
> connect.
You can specify the host when u create the broker. I disagree this is a reason.
Just use --host when you create the broker. Localhost by default is on purpose and I wouldn't change it.
> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> unknown response IDs from the broker. I don't think the OpenWire protocol
> is being negotiated correctly. I am running with the latest NMS trunk
> version (1.8.0).
>
That's probably a bug but I wouldn't hold the release on this. Raise the issue and we can fix it on 6.0.1.
>
>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com> wrote:
>>
>> Hello all.
>>
>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing the
>> initial RC feedback from community members.
>>
>> This is a first release of the Artemis project with protocol support for
>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>
>> The release notes can be found here:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>
>> The binary distributions can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>
>> The source archives can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>
>> The Maven repository is here:
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>
>> The source tag:
>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>
>> The project website for that version has been staged to:
>> http://people.apache.org/~martyntaylor/
>>
>> The vote will remain open for 72 hours.
>>
>> [ ] +1 approve the release as Apache Artemis 1.0.0
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Here's my (non-binding) +1
>>
>> Regards
>> Martyn
>>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Andy Taylor <an...@gmail.com>.
I'd be happy either way.
On 14 May 2015 20:00, "Justin Bertram" <jb...@apache.com> wrote:
> > why don't we just add a flag --secure or something similar and document
> it.
>
> I'm fine with a flag, but I'd advocate using --unsecure and having a
> secure configuration by default. Then it's up to the user to decide which
> they want.
>
>
> Justin
>
> ----- Original Message -----
> From: "Andy Taylor" <an...@gmail.com>
> To: dev@activemq.apache.org
> Sent: Thursday, May 14, 2015 1:18:15 PM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> If its not 100% air tight then there are still vulnerabilities. I think
> something useful out of the box is better.
>
> Since the user now has to create an instance befote tunning tbw broker,
> why don't we just add a flag --secure or something similar and document it.
> Then it's up to the user to decide which they want.
> On 14 May 2015 19:08, "Justin Bertram" <jb...@apache.com> wrote:
>
> > > The security issue is a valid argument, but like you say if its not
> > common for users to unzip and deploy into production then its actually a
> > moot point.
> >
> > "Production" systems are not the only systems on which security is
> > important. Consider a casual user who starts the broker just to play
> > around with it and then forgets to turn it off. Now that unsuspecting
> user
> > has an additional attack vector on their machine. Oftentimes black-hats
> > will compromise a "lesser" (i.e. non production) system in order to get
> to
> > the real target.
> >
> > I'm not trying to be some kind of security alarmist or saying our
> > distribution has to be 100% air-tight. All I'm saying is that the
> default
> > configuration should be conservative from a security/access
> stand-point. I
> > don't think it's acceptable that if I start the broker then anybody who
> can
> > connect to my machine remotely now has the ability to start filling up my
> > disk with messages. If the consensus is to bind to public network
> > interfaces by default then we should likewise modify the configuration to
> > be read-only by default at the very least.
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Andy Taylor" <an...@gmail.com>
> > To: dev@activemq.apache.org
> > Sent: Thursday, May 14, 2015 12:21:24 PM
> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >
> > On 14/05/15 17:11, Justin Bertram wrote:
> > >> However, it is doubtful this is the way any broker will ever be run
> for
> > real.
> > >
> > > Yes, of course.
> > >
> > > As I see it, the default configuration is for users (mostly developers)
> > who want to start up a broker quickly, run a few examples, look at the
> > console, etc. All that would typically be done locally since that is the
> > simplest, fastest use-case. To move beyond that use-case (e.g. to one
> with
> > remote clients) hopefully the user would have reviewed a bit of the
> > documentation and come to understand more of how the broker works, the
> > importance of security, etc.
> > >
> > > I don't think it's common for users to unzip the broker and deploy to
> > production with no changes. IMO, the broker configuration is typically
> > tailored for the application and environment. Binding the network
> > transports to the proper interface is just part of that process.
> > The security issue is a valid argument, but like you say if its not
> > common for users to unzip and deploy into production then its actually a
> > moot point.
> >
> > There are arguments to and for it but personally im happy to open the
> > broker up to remote clients. Maybe we just improve the management
> > functionality(and write) and only allow local clients for admin stuff.
> > >
> > >
> > >> It's like having a web server start up without the ability to server
> > web pages by default.
> > >
> > > If the web server was 100% read-only then I'd probably be find with it
> > binding to a public interface by default. However, if there was any way
> for
> > remote users to impact my machine through that server (beyond a DOS
> attack)
> > then I would want the server to bind to localhost by default or be
> secured
> > with e.g. a username/password. That just seems like common sense to me.
> > >
> > > In short, I think we should take a pretty conservative approach with
> our
> > user's security. I think binding the server to 0.0.0.0 (i.e. all network
> > interfaces) by default with the current configuration is too liberal. If
> > we were to bind to 0.0.0.0 by default I'd want to either remove the
> default
> > user account altogether or change it so that the default user could only
> > consume messages (i.e. couldn't produce messages, create queues, or
> perform
> > management operations).
> > >
> > >
> > > Justin
> > >
> > > ----- Original Message -----
> > > From: "Jim Gomes" <e....@gmail.com>
> > > To: "ActiveMQ Dev" <de...@activemq.apache.org>
> > > Sent: Thursday, May 14, 2015 10:28:15 AM
> > > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> > >
> > > If it was done on purpose for security reasons, that's cool. However,
> it
> > is
> > > doubtful this is the way any broker will ever be run for real. The
> whole
> > > purpose of a broker is to integrate disparate systems. It's like
> having a
> > > web server start up without the ability to server web pages by default.
> > > Kind of silly.
> > >
> > > Anyway, I will log the bug with the NMS clients, and I do think the
> > release
> > > should be held up because of this problem. It's a show-stopper for NMS
> > > clients. Here's the server exception being thrown:
> > >
> > > ERROR [org.apache.activemq.artemis.core.server] error decoding:
> > > java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> > > {commandId = 0, responseRequired = false, consumerId =
> > > ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> > > false, start = false, flush = false, prefetch = 32766, destination =
> > > topic://UnitTest.Status}
> > > at
> > >
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > > at
> > >
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > > at
> > >
> >
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> > > [artemis-server-1.0.0.jar:1.0.0]
> > > at
> > >
> >
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> > > [artemis-core-client-1.0.0.jar:1.0.0]
> > > at
> > >
> >
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> >
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> >
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> >
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> >
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> > >
> > >
> > >
> > > On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com>
> > wrote:
> > >
> > >> IMO the broker correctly binds to localhost only and does not, by
> > default,
> > >> allow connections from remote machines. This is a simple
> > security/sanity
> > >> measure to prevent access to default (i.e. unsecured) instances.
> > >>
> > >> The merit of this configuration is obviously up for debate, but it's
> > worth
> > >> noting it was done on purpose.
> > >>
> > >>
> > >> Justin
> > >>
> > >> ----- Original Message -----
> > >> From: "Jim Gomes" <e....@gmail.com>
> > >> To: "ActiveMQ Dev" <de...@activemq.apache.org>
> > >> Sent: Thursday, May 14, 2015 10:05:55 AM
> > >> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> > >>
> > >> -1
> > >>
> > >> Two reasons:
> > >>
> > >> 1. The default configuration of localhost for the broker does not
> allow
> > >> connections from off-machine. For some reason, socket connections are
> > >> refused from non-local clients. I had to change the broker.xml config
> to
> > >> use the machine's actual IP address, and then non-local clients could
> > >> connect.
> > >> 2. The basic NMS OpenWire client fails to connect at all. It is
> getting
> > >> unknown response IDs from the broker. I don't think the OpenWire
> > protocol
> > >> is being negotiated correctly. I am running with the latest NMS trunk
> > >> version (1.8.0).
> > >>
> > >>
> > >> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> > >> wrote:
> > >>
> > >>> Hello all.
> > >>>
> > >>> I've cut a second release candidate of Apache Artemis 1.0.0
> addressing
> > >> the
> > >>> initial RC feedback from community members.
> > >>>
> > >>> This is a first release of the Artemis project with protocol support
> > for
> > >>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> > >>>
> > >>> The release notes can be found here:
> > >>>
> > >>>
> > >>
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> > >>>
> > >>> The binary distributions can be found here:
> > >>>
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> > >>>
> > >>> The source archives can be found here:
> > >>>
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> > >>>
> > >>> The Maven repository is here:
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> > >>>
> > >>> The source tag:
> > >>>
> > >>>
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> > >>>
> > >>> The project website for that version has been staged to:
> > >>> http://people.apache.org/~martyntaylor/
> > >>>
> > >>> The vote will remain open for 72 hours.
> > >>>
> > >>> [ ] +1 approve the release as Apache Artemis 1.0.0
> > >>> [ ] +0 no opinion
> > >>> [ ] -1 disapprove (and reason why)
> > >>>
> > >>> Here's my (non-binding) +1
> > >>>
> > >>> Regards
> > >>> Martyn
> > >>>
> > >>
> >
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Justin Bertram <jb...@apache.com>.
> why don't we just add a flag --secure or something similar and document it.
I'm fine with a flag, but I'd advocate using --unsecure and having a secure configuration by default. Then it's up to the user to decide which they want.
Justin
----- Original Message -----
From: "Andy Taylor" <an...@gmail.com>
To: dev@activemq.apache.org
Sent: Thursday, May 14, 2015 1:18:15 PM
Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
If its not 100% air tight then there are still vulnerabilities. I think
something useful out of the box is better.
Since the user now has to create an instance befote tunning tbw broker,
why don't we just add a flag --secure or something similar and document it.
Then it's up to the user to decide which they want.
On 14 May 2015 19:08, "Justin Bertram" <jb...@apache.com> wrote:
> > The security issue is a valid argument, but like you say if its not
> common for users to unzip and deploy into production then its actually a
> moot point.
>
> "Production" systems are not the only systems on which security is
> important. Consider a casual user who starts the broker just to play
> around with it and then forgets to turn it off. Now that unsuspecting user
> has an additional attack vector on their machine. Oftentimes black-hats
> will compromise a "lesser" (i.e. non production) system in order to get to
> the real target.
>
> I'm not trying to be some kind of security alarmist or saying our
> distribution has to be 100% air-tight. All I'm saying is that the default
> configuration should be conservative from a security/access stand-point. I
> don't think it's acceptable that if I start the broker then anybody who can
> connect to my machine remotely now has the ability to start filling up my
> disk with messages. If the consensus is to bind to public network
> interfaces by default then we should likewise modify the configuration to
> be read-only by default at the very least.
>
>
> Justin
>
> ----- Original Message -----
> From: "Andy Taylor" <an...@gmail.com>
> To: dev@activemq.apache.org
> Sent: Thursday, May 14, 2015 12:21:24 PM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> On 14/05/15 17:11, Justin Bertram wrote:
> >> However, it is doubtful this is the way any broker will ever be run for
> real.
> >
> > Yes, of course.
> >
> > As I see it, the default configuration is for users (mostly developers)
> who want to start up a broker quickly, run a few examples, look at the
> console, etc. All that would typically be done locally since that is the
> simplest, fastest use-case. To move beyond that use-case (e.g. to one with
> remote clients) hopefully the user would have reviewed a bit of the
> documentation and come to understand more of how the broker works, the
> importance of security, etc.
> >
> > I don't think it's common for users to unzip the broker and deploy to
> production with no changes. IMO, the broker configuration is typically
> tailored for the application and environment. Binding the network
> transports to the proper interface is just part of that process.
> The security issue is a valid argument, but like you say if its not
> common for users to unzip and deploy into production then its actually a
> moot point.
>
> There are arguments to and for it but personally im happy to open the
> broker up to remote clients. Maybe we just improve the management
> functionality(and write) and only allow local clients for admin stuff.
> >
> >
> >> It's like having a web server start up without the ability to server
> web pages by default.
> >
> > If the web server was 100% read-only then I'd probably be find with it
> binding to a public interface by default. However, if there was any way for
> remote users to impact my machine through that server (beyond a DOS attack)
> then I would want the server to bind to localhost by default or be secured
> with e.g. a username/password. That just seems like common sense to me.
> >
> > In short, I think we should take a pretty conservative approach with our
> user's security. I think binding the server to 0.0.0.0 (i.e. all network
> interfaces) by default with the current configuration is too liberal. If
> we were to bind to 0.0.0.0 by default I'd want to either remove the default
> user account altogether or change it so that the default user could only
> consume messages (i.e. couldn't produce messages, create queues, or perform
> management operations).
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Jim Gomes" <e....@gmail.com>
> > To: "ActiveMQ Dev" <de...@activemq.apache.org>
> > Sent: Thursday, May 14, 2015 10:28:15 AM
> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >
> > If it was done on purpose for security reasons, that's cool. However, it
> is
> > doubtful this is the way any broker will ever be run for real. The whole
> > purpose of a broker is to integrate disparate systems. It's like having a
> > web server start up without the ability to server web pages by default.
> > Kind of silly.
> >
> > Anyway, I will log the bug with the NMS clients, and I do think the
> release
> > should be held up because of this problem. It's a show-stopper for NMS
> > clients. Here's the server exception being thrown:
> >
> > ERROR [org.apache.activemq.artemis.core.server] error decoding:
> > java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> > {commandId = 0, responseRequired = false, consumerId =
> > ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> > false, start = false, flush = false, prefetch = 32766, destination =
> > topic://UnitTest.Status}
> > at
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > at
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > at
> >
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> > [artemis-server-1.0.0.jar:1.0.0]
> > at
> >
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> > [artemis-core-client-1.0.0.jar:1.0.0]
> > at
> >
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> >
> >
> >
> > On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com>
> wrote:
> >
> >> IMO the broker correctly binds to localhost only and does not, by
> default,
> >> allow connections from remote machines. This is a simple
> security/sanity
> >> measure to prevent access to default (i.e. unsecured) instances.
> >>
> >> The merit of this configuration is obviously up for debate, but it's
> worth
> >> noting it was done on purpose.
> >>
> >>
> >> Justin
> >>
> >> ----- Original Message -----
> >> From: "Jim Gomes" <e....@gmail.com>
> >> To: "ActiveMQ Dev" <de...@activemq.apache.org>
> >> Sent: Thursday, May 14, 2015 10:05:55 AM
> >> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >>
> >> -1
> >>
> >> Two reasons:
> >>
> >> 1. The default configuration of localhost for the broker does not allow
> >> connections from off-machine. For some reason, socket connections are
> >> refused from non-local clients. I had to change the broker.xml config to
> >> use the machine's actual IP address, and then non-local clients could
> >> connect.
> >> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> >> unknown response IDs from the broker. I don't think the OpenWire
> protocol
> >> is being negotiated correctly. I am running with the latest NMS trunk
> >> version (1.8.0).
> >>
> >>
> >> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> >> wrote:
> >>
> >>> Hello all.
> >>>
> >>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> >> the
> >>> initial RC feedback from community members.
> >>>
> >>> This is a first release of the Artemis project with protocol support
> for
> >>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>>
> >>> The release notes can be found here:
> >>>
> >>>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>>
> >>> The binary distributions can be found here:
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>>
> >>> The source archives can be found here:
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>>
> >>> The Maven repository is here:
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>>
> >>> The source tag:
> >>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>>
> >>> The project website for that version has been staged to:
> >>> http://people.apache.org/~martyntaylor/
> >>>
> >>> The vote will remain open for 72 hours.
> >>>
> >>> [ ] +1 approve the release as Apache Artemis 1.0.0
> >>> [ ] +0 no opinion
> >>> [ ] -1 disapprove (and reason why)
> >>>
> >>> Here's my (non-binding) +1
> >>>
> >>> Regards
> >>> Martyn
> >>>
> >>
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Andy Taylor <an...@gmail.com>.
If its not 100% air tight then there are still vulnerabilities. I think
something useful out of the box is better.
Since the user now has to create an instance befote tunning tbw broker,
why don't we just add a flag --secure or something similar and document it.
Then it's up to the user to decide which they want.
On 14 May 2015 19:08, "Justin Bertram" <jb...@apache.com> wrote:
> > The security issue is a valid argument, but like you say if its not
> common for users to unzip and deploy into production then its actually a
> moot point.
>
> "Production" systems are not the only systems on which security is
> important. Consider a casual user who starts the broker just to play
> around with it and then forgets to turn it off. Now that unsuspecting user
> has an additional attack vector on their machine. Oftentimes black-hats
> will compromise a "lesser" (i.e. non production) system in order to get to
> the real target.
>
> I'm not trying to be some kind of security alarmist or saying our
> distribution has to be 100% air-tight. All I'm saying is that the default
> configuration should be conservative from a security/access stand-point. I
> don't think it's acceptable that if I start the broker then anybody who can
> connect to my machine remotely now has the ability to start filling up my
> disk with messages. If the consensus is to bind to public network
> interfaces by default then we should likewise modify the configuration to
> be read-only by default at the very least.
>
>
> Justin
>
> ----- Original Message -----
> From: "Andy Taylor" <an...@gmail.com>
> To: dev@activemq.apache.org
> Sent: Thursday, May 14, 2015 12:21:24 PM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> On 14/05/15 17:11, Justin Bertram wrote:
> >> However, it is doubtful this is the way any broker will ever be run for
> real.
> >
> > Yes, of course.
> >
> > As I see it, the default configuration is for users (mostly developers)
> who want to start up a broker quickly, run a few examples, look at the
> console, etc. All that would typically be done locally since that is the
> simplest, fastest use-case. To move beyond that use-case (e.g. to one with
> remote clients) hopefully the user would have reviewed a bit of the
> documentation and come to understand more of how the broker works, the
> importance of security, etc.
> >
> > I don't think it's common for users to unzip the broker and deploy to
> production with no changes. IMO, the broker configuration is typically
> tailored for the application and environment. Binding the network
> transports to the proper interface is just part of that process.
> The security issue is a valid argument, but like you say if its not
> common for users to unzip and deploy into production then its actually a
> moot point.
>
> There are arguments to and for it but personally im happy to open the
> broker up to remote clients. Maybe we just improve the management
> functionality(and write) and only allow local clients for admin stuff.
> >
> >
> >> It's like having a web server start up without the ability to server
> web pages by default.
> >
> > If the web server was 100% read-only then I'd probably be find with it
> binding to a public interface by default. However, if there was any way for
> remote users to impact my machine through that server (beyond a DOS attack)
> then I would want the server to bind to localhost by default or be secured
> with e.g. a username/password. That just seems like common sense to me.
> >
> > In short, I think we should take a pretty conservative approach with our
> user's security. I think binding the server to 0.0.0.0 (i.e. all network
> interfaces) by default with the current configuration is too liberal. If
> we were to bind to 0.0.0.0 by default I'd want to either remove the default
> user account altogether or change it so that the default user could only
> consume messages (i.e. couldn't produce messages, create queues, or perform
> management operations).
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Jim Gomes" <e....@gmail.com>
> > To: "ActiveMQ Dev" <de...@activemq.apache.org>
> > Sent: Thursday, May 14, 2015 10:28:15 AM
> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >
> > If it was done on purpose for security reasons, that's cool. However, it
> is
> > doubtful this is the way any broker will ever be run for real. The whole
> > purpose of a broker is to integrate disparate systems. It's like having a
> > web server start up without the ability to server web pages by default.
> > Kind of silly.
> >
> > Anyway, I will log the bug with the NMS clients, and I do think the
> release
> > should be held up because of this problem. It's a show-stopper for NMS
> > clients. Here's the server exception being thrown:
> >
> > ERROR [org.apache.activemq.artemis.core.server] error decoding:
> > java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> > {commandId = 0, responseRequired = false, consumerId =
> > ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> > false, start = false, flush = false, prefetch = 32766, destination =
> > topic://UnitTest.Status}
> > at
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > at
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > at
> >
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> > [artemis-server-1.0.0.jar:1.0.0]
> > at
> >
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> > [artemis-core-client-1.0.0.jar:1.0.0]
> > at
> >
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> >
> >
> >
> > On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com>
> wrote:
> >
> >> IMO the broker correctly binds to localhost only and does not, by
> default,
> >> allow connections from remote machines. This is a simple
> security/sanity
> >> measure to prevent access to default (i.e. unsecured) instances.
> >>
> >> The merit of this configuration is obviously up for debate, but it's
> worth
> >> noting it was done on purpose.
> >>
> >>
> >> Justin
> >>
> >> ----- Original Message -----
> >> From: "Jim Gomes" <e....@gmail.com>
> >> To: "ActiveMQ Dev" <de...@activemq.apache.org>
> >> Sent: Thursday, May 14, 2015 10:05:55 AM
> >> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >>
> >> -1
> >>
> >> Two reasons:
> >>
> >> 1. The default configuration of localhost for the broker does not allow
> >> connections from off-machine. For some reason, socket connections are
> >> refused from non-local clients. I had to change the broker.xml config to
> >> use the machine's actual IP address, and then non-local clients could
> >> connect.
> >> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> >> unknown response IDs from the broker. I don't think the OpenWire
> protocol
> >> is being negotiated correctly. I am running with the latest NMS trunk
> >> version (1.8.0).
> >>
> >>
> >> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> >> wrote:
> >>
> >>> Hello all.
> >>>
> >>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> >> the
> >>> initial RC feedback from community members.
> >>>
> >>> This is a first release of the Artemis project with protocol support
> for
> >>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>>
> >>> The release notes can be found here:
> >>>
> >>>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>>
> >>> The binary distributions can be found here:
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>>
> >>> The source archives can be found here:
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>>
> >>> The Maven repository is here:
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>>
> >>> The source tag:
> >>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>>
> >>> The project website for that version has been staged to:
> >>> http://people.apache.org/~martyntaylor/
> >>>
> >>> The vote will remain open for 72 hours.
> >>>
> >>> [ ] +1 approve the release as Apache Artemis 1.0.0
> >>> [ ] +0 no opinion
> >>> [ ] -1 disapprove (and reason why)
> >>>
> >>> Here's my (non-binding) +1
> >>>
> >>> Regards
> >>> Martyn
> >>>
> >>
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Justin Bertram <jb...@apache.com>.
> The security issue is a valid argument, but like you say if its not common for users to unzip and deploy into production then its actually a moot point.
"Production" systems are not the only systems on which security is important. Consider a casual user who starts the broker just to play around with it and then forgets to turn it off. Now that unsuspecting user has an additional attack vector on their machine. Oftentimes black-hats will compromise a "lesser" (i.e. non production) system in order to get to the real target.
I'm not trying to be some kind of security alarmist or saying our distribution has to be 100% air-tight. All I'm saying is that the default configuration should be conservative from a security/access stand-point. I don't think it's acceptable that if I start the broker then anybody who can connect to my machine remotely now has the ability to start filling up my disk with messages. If the consensus is to bind to public network interfaces by default then we should likewise modify the configuration to be read-only by default at the very least.
Justin
----- Original Message -----
From: "Andy Taylor" <an...@gmail.com>
To: dev@activemq.apache.org
Sent: Thursday, May 14, 2015 12:21:24 PM
Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
On 14/05/15 17:11, Justin Bertram wrote:
>> However, it is doubtful this is the way any broker will ever be run for real.
>
> Yes, of course.
>
> As I see it, the default configuration is for users (mostly developers) who want to start up a broker quickly, run a few examples, look at the console, etc. All that would typically be done locally since that is the simplest, fastest use-case. To move beyond that use-case (e.g. to one with remote clients) hopefully the user would have reviewed a bit of the documentation and come to understand more of how the broker works, the importance of security, etc.
>
> I don't think it's common for users to unzip the broker and deploy to production with no changes. IMO, the broker configuration is typically tailored for the application and environment. Binding the network transports to the proper interface is just part of that process.
The security issue is a valid argument, but like you say if its not
common for users to unzip and deploy into production then its actually a
moot point.
There are arguments to and for it but personally im happy to open the
broker up to remote clients. Maybe we just improve the management
functionality(and write) and only allow local clients for admin stuff.
>
>
>> It's like having a web server start up without the ability to server web pages by default.
>
> If the web server was 100% read-only then I'd probably be find with it binding to a public interface by default. However, if there was any way for remote users to impact my machine through that server (beyond a DOS attack) then I would want the server to bind to localhost by default or be secured with e.g. a username/password. That just seems like common sense to me.
>
> In short, I think we should take a pretty conservative approach with our user's security. I think binding the server to 0.0.0.0 (i.e. all network interfaces) by default with the current configuration is too liberal. If we were to bind to 0.0.0.0 by default I'd want to either remove the default user account altogether or change it so that the default user could only consume messages (i.e. couldn't produce messages, create queues, or perform management operations).
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <e....@gmail.com>
> To: "ActiveMQ Dev" <de...@activemq.apache.org>
> Sent: Thursday, May 14, 2015 10:28:15 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> If it was done on purpose for security reasons, that's cool. However, it is
> doubtful this is the way any broker will ever be run for real. The whole
> purpose of a broker is to integrate disparate systems. It's like having a
> web server start up without the ability to server web pages by default.
> Kind of silly.
>
> Anyway, I will log the bug with the NMS clients, and I do think the release
> should be held up because of this problem. It's a show-stopper for NMS
> clients. Here's the server exception being thrown:
>
> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> {commandId = 0, responseRequired = false, consumerId =
> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> false, start = false, flush = false, prefetch = 32766, destination =
> topic://UnitTest.Status}
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> [artemis-server-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> [artemis-core-client-1.0.0.jar:1.0.0]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>
>
> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com> wrote:
>
>> IMO the broker correctly binds to localhost only and does not, by default,
>> allow connections from remote machines. This is a simple security/sanity
>> measure to prevent access to default (i.e. unsecured) instances.
>>
>> The merit of this configuration is obviously up for debate, but it's worth
>> noting it was done on purpose.
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jim Gomes" <e....@gmail.com>
>> To: "ActiveMQ Dev" <de...@activemq.apache.org>
>> Sent: Thursday, May 14, 2015 10:05:55 AM
>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>
>> -1
>>
>> Two reasons:
>>
>> 1. The default configuration of localhost for the broker does not allow
>> connections from off-machine. For some reason, socket connections are
>> refused from non-local clients. I had to change the broker.xml config to
>> use the machine's actual IP address, and then non-local clients could
>> connect.
>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>> unknown response IDs from the broker. I don't think the OpenWire protocol
>> is being negotiated correctly. I am running with the latest NMS trunk
>> version (1.8.0).
>>
>>
>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
>> wrote:
>>
>>> Hello all.
>>>
>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the
>>> initial RC feedback from community members.
>>>
>>> This is a first release of the Artemis project with protocol support for
>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>
>>> The release notes can be found here:
>>>
>>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>
>>> The binary distributions can be found here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The source archives can be found here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The Maven repository is here:
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>
>>> The source tag:
>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>
>>> The project website for that version has been staged to:
>>> http://people.apache.org/~martyntaylor/
>>>
>>> The vote will remain open for 72 hours.
>>>
>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>> [ ] +0 no opinion
>>> [ ] -1 disapprove (and reason why)
>>>
>>> Here's my (non-binding) +1
>>>
>>> Regards
>>> Martyn
>>>
>>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Hiram Chirino <hi...@hiramchirino.com>.
BTW now that we generate the instance configuration, we could create
fully secure configurations by default. For example we could generate
a broker with SSL enabled using a generated self signed cert. We
could also create a default admin users with a generated password etc.
On Thu, May 14, 2015 at 1:21 PM, Andy Taylor <an...@gmail.com> wrote:
> On 14/05/15 17:11, Justin Bertram wrote:
>>>
>>> However, it is doubtful this is the way any broker will ever be run for
>>> real.
>>
>>
>> Yes, of course.
>>
>> As I see it, the default configuration is for users (mostly developers)
>> who want to start up a broker quickly, run a few examples, look at the
>> console, etc. All that would typically be done locally since that is the
>> simplest, fastest use-case. To move beyond that use-case (e.g. to one with
>> remote clients) hopefully the user would have reviewed a bit of the
>> documentation and come to understand more of how the broker works, the
>> importance of security, etc.
>>
>> I don't think it's common for users to unzip the broker and deploy to
>> production with no changes. IMO, the broker configuration is typically
>> tailored for the application and environment. Binding the network transports
>> to the proper interface is just part of that process.
>
> The security issue is a valid argument, but like you say if its not common
> for users to unzip and deploy into production then its actually a moot
> point.
>
> There are arguments to and for it but personally im happy to open the broker
> up to remote clients. Maybe we just improve the management functionality(and
> write) and only allow local clients for admin stuff.
>
>>
>>
>>> It's like having a web server start up without the ability to server web
>>> pages by default.
>>
>>
>> If the web server was 100% read-only then I'd probably be find with it
>> binding to a public interface by default. However, if there was any way for
>> remote users to impact my machine through that server (beyond a DOS attack)
>> then I would want the server to bind to localhost by default or be secured
>> with e.g. a username/password. That just seems like common sense to me.
>>
>> In short, I think we should take a pretty conservative approach with our
>> user's security. I think binding the server to 0.0.0.0 (i.e. all network
>> interfaces) by default with the current configuration is too liberal. If we
>> were to bind to 0.0.0.0 by default I'd want to either remove the default
>> user account altogether or change it so that the default user could only
>> consume messages (i.e. couldn't produce messages, create queues, or perform
>> management operations).
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jim Gomes" <e....@gmail.com>
>> To: "ActiveMQ Dev" <de...@activemq.apache.org>
>> Sent: Thursday, May 14, 2015 10:28:15 AM
>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>
>> If it was done on purpose for security reasons, that's cool. However, it
>> is
>> doubtful this is the way any broker will ever be run for real. The whole
>> purpose of a broker is to integrate disparate systems. It's like having a
>> web server start up without the ability to server web pages by default.
>> Kind of silly.
>>
>> Anyway, I will log the bug with the NMS clients, and I do think the
>> release
>> should be held up because of this problem. It's a show-stopper for NMS
>> clients. Here's the server exception being thrown:
>>
>> ERROR [org.apache.activemq.artemis.core.server] error decoding:
>> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
>> {commandId = 0, responseRequired = false, consumerId =
>> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
>> false, start = false, flush = false, prefetch = 32766, destination =
>> topic://UnitTest.Status}
>> at
>>
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> at
>>
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> at
>>
>> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
>> [artemis-server-1.0.0.jar:1.0.0]
>> at
>>
>> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
>> [artemis-core-client-1.0.0.jar:1.0.0]
>> at
>>
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>>
>>
>>
>> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com>
>> wrote:
>>
>>> IMO the broker correctly binds to localhost only and does not, by
>>> default,
>>> allow connections from remote machines. This is a simple security/sanity
>>> measure to prevent access to default (i.e. unsecured) instances.
>>>
>>> The merit of this configuration is obviously up for debate, but it's
>>> worth
>>> noting it was done on purpose.
>>>
>>>
>>> Justin
>>>
>>> ----- Original Message -----
>>> From: "Jim Gomes" <e....@gmail.com>
>>> To: "ActiveMQ Dev" <de...@activemq.apache.org>
>>> Sent: Thursday, May 14, 2015 10:05:55 AM
>>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>>
>>> -1
>>>
>>> Two reasons:
>>>
>>> 1. The default configuration of localhost for the broker does not allow
>>> connections from off-machine. For some reason, socket connections are
>>> refused from non-local clients. I had to change the broker.xml config to
>>> use the machine's actual IP address, and then non-local clients could
>>> connect.
>>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>>> unknown response IDs from the broker. I don't think the OpenWire protocol
>>> is being negotiated correctly. I am running with the latest NMS trunk
>>> version (1.8.0).
>>>
>>>
>>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
>>> wrote:
>>>
>>>> Hello all.
>>>>
>>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>>>
>>> the
>>>>
>>>> initial RC feedback from community members.
>>>>
>>>> This is a first release of the Artemis project with protocol support for
>>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>>
>>>> The release notes can be found here:
>>>>
>>>>
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>>
>>>>
>>>> The binary distributions can be found here:
>>>>
>>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>>
>>>>
>>>> The source archives can be found here:
>>>>
>>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>>
>>>>
>>>> The Maven repository is here:
>>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>>
>>>>
>>>> The source tag:
>>>>
>>>>
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>>
>>>>
>>>> The project website for that version has been staged to:
>>>> http://people.apache.org/~martyntaylor/
>>>>
>>>> The vote will remain open for 72 hours.
>>>>
>>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>>> [ ] +0 no opinion
>>>> [ ] -1 disapprove (and reason why)
>>>>
>>>> Here's my (non-binding) +1
>>>>
>>>> Regards
>>>> Martyn
>>>>
>>>
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Andy Taylor <an...@gmail.com>.
On 14/05/15 17:11, Justin Bertram wrote:
>> However, it is doubtful this is the way any broker will ever be run for real.
>
> Yes, of course.
>
> As I see it, the default configuration is for users (mostly developers) who want to start up a broker quickly, run a few examples, look at the console, etc. All that would typically be done locally since that is the simplest, fastest use-case. To move beyond that use-case (e.g. to one with remote clients) hopefully the user would have reviewed a bit of the documentation and come to understand more of how the broker works, the importance of security, etc.
>
> I don't think it's common for users to unzip the broker and deploy to production with no changes. IMO, the broker configuration is typically tailored for the application and environment. Binding the network transports to the proper interface is just part of that process.
The security issue is a valid argument, but like you say if its not
common for users to unzip and deploy into production then its actually a
moot point.
There are arguments to and for it but personally im happy to open the
broker up to remote clients. Maybe we just improve the management
functionality(and write) and only allow local clients for admin stuff.
>
>
>> It's like having a web server start up without the ability to server web pages by default.
>
> If the web server was 100% read-only then I'd probably be find with it binding to a public interface by default. However, if there was any way for remote users to impact my machine through that server (beyond a DOS attack) then I would want the server to bind to localhost by default or be secured with e.g. a username/password. That just seems like common sense to me.
>
> In short, I think we should take a pretty conservative approach with our user's security. I think binding the server to 0.0.0.0 (i.e. all network interfaces) by default with the current configuration is too liberal. If we were to bind to 0.0.0.0 by default I'd want to either remove the default user account altogether or change it so that the default user could only consume messages (i.e. couldn't produce messages, create queues, or perform management operations).
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <e....@gmail.com>
> To: "ActiveMQ Dev" <de...@activemq.apache.org>
> Sent: Thursday, May 14, 2015 10:28:15 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> If it was done on purpose for security reasons, that's cool. However, it is
> doubtful this is the way any broker will ever be run for real. The whole
> purpose of a broker is to integrate disparate systems. It's like having a
> web server start up without the ability to server web pages by default.
> Kind of silly.
>
> Anyway, I will log the bug with the NMS clients, and I do think the release
> should be held up because of this problem. It's a show-stopper for NMS
> clients. Here's the server exception being thrown:
>
> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> {commandId = 0, responseRequired = false, consumerId =
> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> false, start = false, flush = false, prefetch = 32766, destination =
> topic://UnitTest.Status}
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> [artemis-server-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> [artemis-core-client-1.0.0.jar:1.0.0]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>
>
> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com> wrote:
>
>> IMO the broker correctly binds to localhost only and does not, by default,
>> allow connections from remote machines. This is a simple security/sanity
>> measure to prevent access to default (i.e. unsecured) instances.
>>
>> The merit of this configuration is obviously up for debate, but it's worth
>> noting it was done on purpose.
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jim Gomes" <e....@gmail.com>
>> To: "ActiveMQ Dev" <de...@activemq.apache.org>
>> Sent: Thursday, May 14, 2015 10:05:55 AM
>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>
>> -1
>>
>> Two reasons:
>>
>> 1. The default configuration of localhost for the broker does not allow
>> connections from off-machine. For some reason, socket connections are
>> refused from non-local clients. I had to change the broker.xml config to
>> use the machine's actual IP address, and then non-local clients could
>> connect.
>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>> unknown response IDs from the broker. I don't think the OpenWire protocol
>> is being negotiated correctly. I am running with the latest NMS trunk
>> version (1.8.0).
>>
>>
>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
>> wrote:
>>
>>> Hello all.
>>>
>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the
>>> initial RC feedback from community members.
>>>
>>> This is a first release of the Artemis project with protocol support for
>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>
>>> The release notes can be found here:
>>>
>>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>
>>> The binary distributions can be found here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The source archives can be found here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The Maven repository is here:
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>
>>> The source tag:
>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>
>>> The project website for that version has been staged to:
>>> http://people.apache.org/~martyntaylor/
>>>
>>> The vote will remain open for 72 hours.
>>>
>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>> [ ] +0 no opinion
>>> [ ] -1 disapprove (and reason why)
>>>
>>> Here's my (non-binding) +1
>>>
>>> Regards
>>> Martyn
>>>
>>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Justin Bertram <jb...@apache.com>.
> However, it is doubtful this is the way any broker will ever be run for real.
Yes, of course.
As I see it, the default configuration is for users (mostly developers) who want to start up a broker quickly, run a few examples, look at the console, etc. All that would typically be done locally since that is the simplest, fastest use-case. To move beyond that use-case (e.g. to one with remote clients) hopefully the user would have reviewed a bit of the documentation and come to understand more of how the broker works, the importance of security, etc.
I don't think it's common for users to unzip the broker and deploy to production with no changes. IMO, the broker configuration is typically tailored for the application and environment. Binding the network transports to the proper interface is just part of that process.
> It's like having a web server start up without the ability to server web pages by default.
If the web server was 100% read-only then I'd probably be find with it binding to a public interface by default. However, if there was any way for remote users to impact my machine through that server (beyond a DOS attack) then I would want the server to bind to localhost by default or be secured with e.g. a username/password. That just seems like common sense to me.
In short, I think we should take a pretty conservative approach with our user's security. I think binding the server to 0.0.0.0 (i.e. all network interfaces) by default with the current configuration is too liberal. If we were to bind to 0.0.0.0 by default I'd want to either remove the default user account altogether or change it so that the default user could only consume messages (i.e. couldn't produce messages, create queues, or perform management operations).
Justin
----- Original Message -----
From: "Jim Gomes" <e....@gmail.com>
To: "ActiveMQ Dev" <de...@activemq.apache.org>
Sent: Thursday, May 14, 2015 10:28:15 AM
Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
If it was done on purpose for security reasons, that's cool. However, it is
doubtful this is the way any broker will ever be run for real. The whole
purpose of a broker is to integrate disparate systems. It's like having a
web server start up without the ability to server web pages by default.
Kind of silly.
Anyway, I will log the bug with the NMS clients, and I do think the release
should be held up because of this problem. It's a show-stopper for NMS
clients. Here's the server exception being thrown:
ERROR [org.apache.activemq.artemis.core.server] error decoding:
java.lang.IllegalStateException: Cannot handle command: ConsumerControl
{commandId = 0, responseRequired = false, consumerId =
ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
false, start = false, flush = false, prefetch = 32766, destination =
topic://UnitTest.Status}
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com> wrote:
> IMO the broker correctly binds to localhost only and does not, by default,
> allow connections from remote machines. This is a simple security/sanity
> measure to prevent access to default (i.e. unsecured) instances.
>
> The merit of this configuration is obviously up for debate, but it's worth
> noting it was done on purpose.
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <e....@gmail.com>
> To: "ActiveMQ Dev" <de...@activemq.apache.org>
> Sent: Thursday, May 14, 2015 10:05:55 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> -1
>
> Two reasons:
>
> 1. The default configuration of localhost for the broker does not allow
> connections from off-machine. For some reason, socket connections are
> refused from non-local clients. I had to change the broker.xml config to
> use the machine's actual IP address, and then non-local clients could
> connect.
> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> unknown response IDs from the broker. I don't think the OpenWire protocol
> is being negotiated correctly. I am running with the latest NMS trunk
> version (1.8.0).
>
>
> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> wrote:
>
> > Hello all.
> >
> > I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> > initial RC feedback from community members.
> >
> > This is a first release of the Artemis project with protocol support for
> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >
> > The release notes can be found here:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >
> > The binary distributions can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The source archives can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The Maven repository is here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >
> > The source tag:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >
> > The project website for that version has been staged to:
> > http://people.apache.org/~martyntaylor/
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1 approve the release as Apache Artemis 1.0.0
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my (non-binding) +1
> >
> > Regards
> > Martyn
> >
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Clebert <cl...@gmail.com>.
We have requested a rename. Infra is waiting on a window to reboot JIRA.
Sent from my iPad
> On May 14, 2015, at 11:41, Jim Gomes <e....@gmail.com> wrote:
>
> Logged bug ACTIVEMQ6-106.
>
> And at the risk of opening a big can of worms, do we need to have
> Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
> something? I was very hesitant to enter a bug there, and had to
> double-check that it was indeed the Artemis bug tracker.
>
>> On Thu, May 14, 2015 at 8:28 AM, Jim Gomes <e....@gmail.com> wrote:
>>
>> If it was done on purpose for security reasons, that's cool. However, it
>> is doubtful this is the way any broker will ever be run for real. The whole
>> purpose of a broker is to integrate disparate systems. It's like having a
>> web server start up without the ability to server web pages by default.
>> Kind of silly.
>>
>> Anyway, I will log the bug with the NMS clients, and I do think the
>> release should be held up because of this problem. It's a show-stopper for
>> NMS clients. Here's the server exception being thrown:
>>
>> ERROR [org.apache.activemq.artemis.core.server] error decoding:
>> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
>> {commandId = 0, responseRequired = false, consumerId =
>> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
>> false, start = false, flush = false, prefetch = 32766, destination =
>> topic://UnitTest.Status}
>> at
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> at
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> at
>> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
>> [artemis-server-1.0.0.jar:1.0.0]
>> at
>> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
>> [artemis-core-client-1.0.0.jar:1.0.0]
>> at
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>>
>>
>>
>> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com>
>> wrote:
>>
>>> IMO the broker correctly binds to localhost only and does not, by
>>> default, allow connections from remote machines. This is a simple
>>> security/sanity measure to prevent access to default (i.e. unsecured)
>>> instances.
>>>
>>> The merit of this configuration is obviously up for debate, but it's
>>> worth noting it was done on purpose.
>>>
>>>
>>> Justin
>>>
>>> ----- Original Message -----
>>> From: "Jim Gomes" <e....@gmail.com>
>>> To: "ActiveMQ Dev" <de...@activemq.apache.org>
>>> Sent: Thursday, May 14, 2015 10:05:55 AM
>>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>>
>>> -1
>>>
>>> Two reasons:
>>>
>>> 1. The default configuration of localhost for the broker does not allow
>>> connections from off-machine. For some reason, socket connections are
>>> refused from non-local clients. I had to change the broker.xml config to
>>> use the machine's actual IP address, and then non-local clients could
>>> connect.
>>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>>> unknown response IDs from the broker. I don't think the OpenWire protocol
>>> is being negotiated correctly. I am running with the latest NMS trunk
>>> version (1.8.0).
>>>
>>>
>>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
>>> wrote:
>>>
>>>> Hello all.
>>>>
>>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>>> the
>>>> initial RC feedback from community members.
>>>>
>>>> This is a first release of the Artemis project with protocol support for
>>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>>
>>>> The release notes can be found here:
>>>>
>>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>>
>>>> The binary distributions can be found here:
>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>>
>>>> The source archives can be found here:
>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>>
>>>> The Maven repository is here:
>>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>>
>>>> The source tag:
>>>>
>>>>
>>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>>
>>>> The project website for that version has been staged to:
>>>> http://people.apache.org/~martyntaylor/
>>>>
>>>> The vote will remain open for 72 hours.
>>>>
>>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>>> [ ] +0 no opinion
>>>> [ ] -1 disapprove (and reason why)
>>>>
>>>> Here's my (non-binding) +1
>>>>
>>>> Regards
>>>> Martyn
>>>>
>>>
>>
>>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Jim Gomes <e....@gmail.com>.
Thanks, Clebert!
And thanks for the quick update on the default bindings.
On Thu, May 14, 2015 at 8:59 AM, Clebert Suconic <cl...@gmail.com>
wrote:
> here is the JIRA with the current progress on the renames:
>
> https://issues.apache.org/jira/browse/INFRA-9543
>
> On Thu, May 14, 2015 at 11:41 AM, Jim Gomes <e....@gmail.com> wrote:
> > Logged bug ACTIVEMQ6-106.
> >
> > And at the risk of opening a big can of worms, do we need to have
> > Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
> > something? I was very hesitant to enter a bug there, and had to
> > double-check that it was indeed the Artemis bug tracker.
> >
> > On Thu, May 14, 2015 at 8:28 AM, Jim Gomes <e....@gmail.com> wrote:
> >
> >> If it was done on purpose for security reasons, that's cool. However, it
> >> is doubtful this is the way any broker will ever be run for real. The
> whole
> >> purpose of a broker is to integrate disparate systems. It's like having
> a
> >> web server start up without the ability to server web pages by default.
> >> Kind of silly.
> >>
> >> Anyway, I will log the bug with the NMS clients, and I do think the
> >> release should be held up because of this problem. It's a show-stopper
> for
> >> NMS clients. Here's the server exception being thrown:
> >>
> >> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> >> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> >> {commandId = 0, responseRequired = false, consumerId =
> >> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> >> false, start = false, flush = false, prefetch = 32766, destination =
> >> topic://UnitTest.Status}
> >> at
> >>
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> >> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> >> at
> >>
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> >> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> >> at
> >>
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> >> [artemis-server-1.0.0.jar:1.0.0]
> >> at
> >>
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> >> [artemis-core-client-1.0.0.jar:1.0.0]
> >> at
> >>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >> at
> >>
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >> at
> >>
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >> at
> >>
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >> at
> >>
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >> at
> >>
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >> at
> >>
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >> at
> >>
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> >>
> >>
> >>
> >> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com>
> >> wrote:
> >>
> >>> IMO the broker correctly binds to localhost only and does not, by
> >>> default, allow connections from remote machines. This is a simple
> >>> security/sanity measure to prevent access to default (i.e. unsecured)
> >>> instances.
> >>>
> >>> The merit of this configuration is obviously up for debate, but it's
> >>> worth noting it was done on purpose.
> >>>
> >>>
> >>> Justin
> >>>
> >>> ----- Original Message -----
> >>> From: "Jim Gomes" <e....@gmail.com>
> >>> To: "ActiveMQ Dev" <de...@activemq.apache.org>
> >>> Sent: Thursday, May 14, 2015 10:05:55 AM
> >>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >>>
> >>> -1
> >>>
> >>> Two reasons:
> >>>
> >>> 1. The default configuration of localhost for the broker does not allow
> >>> connections from off-machine. For some reason, socket connections are
> >>> refused from non-local clients. I had to change the broker.xml config
> to
> >>> use the machine's actual IP address, and then non-local clients could
> >>> connect.
> >>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> >>> unknown response IDs from the broker. I don't think the OpenWire
> protocol
> >>> is being negotiated correctly. I am running with the latest NMS trunk
> >>> version (1.8.0).
> >>>
> >>>
> >>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> >>> wrote:
> >>>
> >>> > Hello all.
> >>> >
> >>> > I've cut a second release candidate of Apache Artemis 1.0.0
> addressing
> >>> the
> >>> > initial RC feedback from community members.
> >>> >
> >>> > This is a first release of the Artemis project with protocol support
> for
> >>> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>> >
> >>> > The release notes can be found here:
> >>> >
> >>> >
> >>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>> >
> >>> > The binary distributions can be found here:
> >>> >
> >>> >
> >>>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>> >
> >>> > The source archives can be found here:
> >>> >
> >>> >
> >>>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>> >
> >>> > The Maven repository is here:
> >>> >
> >>>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>> >
> >>> > The source tag:
> >>> >
> >>> >
> >>>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>> >
> >>> > The project website for that version has been staged to:
> >>> > http://people.apache.org/~martyntaylor/
> >>> >
> >>> > The vote will remain open for 72 hours.
> >>> >
> >>> > [ ] +1 approve the release as Apache Artemis 1.0.0
> >>> > [ ] +0 no opinion
> >>> > [ ] -1 disapprove (and reason why)
> >>> >
> >>> > Here's my (non-binding) +1
> >>> >
> >>> > Regards
> >>> > Martyn
> >>> >
> >>>
> >>
> >>
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suconic@jboss.com
> http://clebertsuconic.blogspot.com
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Clebert Suconic <cl...@gmail.com>.
here is the JIRA with the current progress on the renames:
https://issues.apache.org/jira/browse/INFRA-9543
On Thu, May 14, 2015 at 11:41 AM, Jim Gomes <e....@gmail.com> wrote:
> Logged bug ACTIVEMQ6-106.
>
> And at the risk of opening a big can of worms, do we need to have
> Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
> something? I was very hesitant to enter a bug there, and had to
> double-check that it was indeed the Artemis bug tracker.
>
> On Thu, May 14, 2015 at 8:28 AM, Jim Gomes <e....@gmail.com> wrote:
>
>> If it was done on purpose for security reasons, that's cool. However, it
>> is doubtful this is the way any broker will ever be run for real. The whole
>> purpose of a broker is to integrate disparate systems. It's like having a
>> web server start up without the ability to server web pages by default.
>> Kind of silly.
>>
>> Anyway, I will log the bug with the NMS clients, and I do think the
>> release should be held up because of this problem. It's a show-stopper for
>> NMS clients. Here's the server exception being thrown:
>>
>> ERROR [org.apache.activemq.artemis.core.server] error decoding:
>> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
>> {commandId = 0, responseRequired = false, consumerId =
>> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
>> false, start = false, flush = false, prefetch = 32766, destination =
>> topic://UnitTest.Status}
>> at
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> at
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> at
>> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
>> [artemis-server-1.0.0.jar:1.0.0]
>> at
>> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
>> [artemis-core-client-1.0.0.jar:1.0.0]
>> at
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>>
>>
>>
>> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com>
>> wrote:
>>
>>> IMO the broker correctly binds to localhost only and does not, by
>>> default, allow connections from remote machines. This is a simple
>>> security/sanity measure to prevent access to default (i.e. unsecured)
>>> instances.
>>>
>>> The merit of this configuration is obviously up for debate, but it's
>>> worth noting it was done on purpose.
>>>
>>>
>>> Justin
>>>
>>> ----- Original Message -----
>>> From: "Jim Gomes" <e....@gmail.com>
>>> To: "ActiveMQ Dev" <de...@activemq.apache.org>
>>> Sent: Thursday, May 14, 2015 10:05:55 AM
>>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>>
>>> -1
>>>
>>> Two reasons:
>>>
>>> 1. The default configuration of localhost for the broker does not allow
>>> connections from off-machine. For some reason, socket connections are
>>> refused from non-local clients. I had to change the broker.xml config to
>>> use the machine's actual IP address, and then non-local clients could
>>> connect.
>>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>>> unknown response IDs from the broker. I don't think the OpenWire protocol
>>> is being negotiated correctly. I am running with the latest NMS trunk
>>> version (1.8.0).
>>>
>>>
>>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
>>> wrote:
>>>
>>> > Hello all.
>>> >
>>> > I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>>> the
>>> > initial RC feedback from community members.
>>> >
>>> > This is a first release of the Artemis project with protocol support for
>>> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>> >
>>> > The release notes can be found here:
>>> >
>>> >
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>> >
>>> > The binary distributions can be found here:
>>> >
>>> >
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>> >
>>> > The source archives can be found here:
>>> >
>>> >
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>> >
>>> > The Maven repository is here:
>>> >
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>> >
>>> > The source tag:
>>> >
>>> >
>>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>> >
>>> > The project website for that version has been staged to:
>>> > http://people.apache.org/~martyntaylor/
>>> >
>>> > The vote will remain open for 72 hours.
>>> >
>>> > [ ] +1 approve the release as Apache Artemis 1.0.0
>>> > [ ] +0 no opinion
>>> > [ ] -1 disapprove (and reason why)
>>> >
>>> > Here's my (non-binding) +1
>>> >
>>> > Regards
>>> > Martyn
>>> >
>>>
>>
>>
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Jim Gomes <e....@gmail.com>.
Logged bug ACTIVEMQ6-106.
And at the risk of opening a big can of worms, do we need to have
Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
something? I was very hesitant to enter a bug there, and had to
double-check that it was indeed the Artemis bug tracker.
On Thu, May 14, 2015 at 8:28 AM, Jim Gomes <e....@gmail.com> wrote:
> If it was done on purpose for security reasons, that's cool. However, it
> is doubtful this is the way any broker will ever be run for real. The whole
> purpose of a broker is to integrate disparate systems. It's like having a
> web server start up without the ability to server web pages by default.
> Kind of silly.
>
> Anyway, I will log the bug with the NMS clients, and I do think the
> release should be held up because of this problem. It's a show-stopper for
> NMS clients. Here's the server exception being thrown:
>
> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> {commandId = 0, responseRequired = false, consumerId =
> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> false, start = false, flush = false, prefetch = 32766, destination =
> topic://UnitTest.Status}
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> [artemis-server-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> [artemis-core-client-1.0.0.jar:1.0.0]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>
>
> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com>
> wrote:
>
>> IMO the broker correctly binds to localhost only and does not, by
>> default, allow connections from remote machines. This is a simple
>> security/sanity measure to prevent access to default (i.e. unsecured)
>> instances.
>>
>> The merit of this configuration is obviously up for debate, but it's
>> worth noting it was done on purpose.
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jim Gomes" <e....@gmail.com>
>> To: "ActiveMQ Dev" <de...@activemq.apache.org>
>> Sent: Thursday, May 14, 2015 10:05:55 AM
>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>
>> -1
>>
>> Two reasons:
>>
>> 1. The default configuration of localhost for the broker does not allow
>> connections from off-machine. For some reason, socket connections are
>> refused from non-local clients. I had to change the broker.xml config to
>> use the machine's actual IP address, and then non-local clients could
>> connect.
>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>> unknown response IDs from the broker. I don't think the OpenWire protocol
>> is being negotiated correctly. I am running with the latest NMS trunk
>> version (1.8.0).
>>
>>
>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
>> wrote:
>>
>> > Hello all.
>> >
>> > I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the
>> > initial RC feedback from community members.
>> >
>> > This is a first release of the Artemis project with protocol support for
>> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>> >
>> > The release notes can be found here:
>> >
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>> >
>> > The binary distributions can be found here:
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>> >
>> > The source archives can be found here:
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>> >
>> > The Maven repository is here:
>> >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>> >
>> > The source tag:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>> >
>> > The project website for that version has been staged to:
>> > http://people.apache.org/~martyntaylor/
>> >
>> > The vote will remain open for 72 hours.
>> >
>> > [ ] +1 approve the release as Apache Artemis 1.0.0
>> > [ ] +0 no opinion
>> > [ ] -1 disapprove (and reason why)
>> >
>> > Here's my (non-binding) +1
>> >
>> > Regards
>> > Martyn
>> >
>>
>
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Jim Gomes <e....@gmail.com>.
If it was done on purpose for security reasons, that's cool. However, it is
doubtful this is the way any broker will ever be run for real. The whole
purpose of a broker is to integrate disparate systems. It's like having a
web server start up without the ability to server web pages by default.
Kind of silly.
Anyway, I will log the bug with the NMS clients, and I do think the release
should be held up because of this problem. It's a show-stopper for NMS
clients. Here's the server exception being thrown:
ERROR [org.apache.activemq.artemis.core.server] error decoding:
java.lang.IllegalStateException: Cannot handle command: ConsumerControl
{commandId = 0, responseRequired = false, consumerId =
ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
false, start = false, flush = false, prefetch = 32766, destination =
topic://UnitTest.Status}
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jb...@apache.com> wrote:
> IMO the broker correctly binds to localhost only and does not, by default,
> allow connections from remote machines. This is a simple security/sanity
> measure to prevent access to default (i.e. unsecured) instances.
>
> The merit of this configuration is obviously up for debate, but it's worth
> noting it was done on purpose.
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <e....@gmail.com>
> To: "ActiveMQ Dev" <de...@activemq.apache.org>
> Sent: Thursday, May 14, 2015 10:05:55 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> -1
>
> Two reasons:
>
> 1. The default configuration of localhost for the broker does not allow
> connections from off-machine. For some reason, socket connections are
> refused from non-local clients. I had to change the broker.xml config to
> use the machine's actual IP address, and then non-local clients could
> connect.
> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> unknown response IDs from the broker. I don't think the OpenWire protocol
> is being negotiated correctly. I am running with the latest NMS trunk
> version (1.8.0).
>
>
> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> wrote:
>
> > Hello all.
> >
> > I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> > initial RC feedback from community members.
> >
> > This is a first release of the Artemis project with protocol support for
> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >
> > The release notes can be found here:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >
> > The binary distributions can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The source archives can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The Maven repository is here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >
> > The source tag:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >
> > The project website for that version has been staged to:
> > http://people.apache.org/~martyntaylor/
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1 approve the release as Apache Artemis 1.0.0
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my (non-binding) +1
> >
> > Regards
> > Martyn
> >
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Timothy Bish <ta...@gmail.com>.
+1
On 05/14/2015 12:14 PM, Bruce Snyder wrote:
> +1 We debated this some time ago for ActiveMQ and opted for the current
> functionality of allowing remote connections by default.
>
> Bruce
>
> On Thu, May 14, 2015 at 9:32 AM, Hiram Chirino <hi...@hiramchirino.com>
> wrote:
>
>> I'm not sure that's a good default. ActiveMQ has traditionally
>> allowed remote access to it's ports. I think a localhost binding is
>> fine for things like management ports, but for the main service the
>> product gives it should be on the public ports.
>>
>> That would be like tomcat or jetty defaulting to binding it's http
>> ports to localhost.
>>
>> On Thu, May 14, 2015 at 11:20 AM, Justin Bertram <jb...@apache.com>
>> wrote:
>>> IMO the broker correctly binds to localhost only and does not, by
>> default, allow connections from remote machines. This is a simple
>> security/sanity measure to prevent access to default (i.e. unsecured)
>> instances.
>>> The merit of this configuration is obviously up for debate, but it's
>> worth noting it was done on purpose.
>>>
>>> Justin
>>>
>>> ----- Original Message -----
>>> From: "Jim Gomes" <e....@gmail.com>
>>> To: "ActiveMQ Dev" <de...@activemq.apache.org>
>>> Sent: Thursday, May 14, 2015 10:05:55 AM
>>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>>
>>> -1
>>>
>>> Two reasons:
>>>
>>> 1. The default configuration of localhost for the broker does not allow
>>> connections from off-machine. For some reason, socket connections are
>>> refused from non-local clients. I had to change the broker.xml config to
>>> use the machine's actual IP address, and then non-local clients could
>>> connect.
>>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>>> unknown response IDs from the broker. I don't think the OpenWire protocol
>>> is being negotiated correctly. I am running with the latest NMS trunk
>>> version (1.8.0).
>>>
>>>
>>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
>> wrote:
>>>> Hello all.
>>>>
>>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the
>>>> initial RC feedback from community members.
>>>>
>>>> This is a first release of the Artemis project with protocol support for
>>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>>
>>>> The release notes can be found here:
>>>>
>>>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>> The binary distributions can be found here:
>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>> The source archives can be found here:
>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>> The Maven repository is here:
>>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>> The source tag:
>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>> The project website for that version has been staged to:
>>>> http://people.apache.org/~martyntaylor/
>>>>
>>>> The vote will remain open for 72 hours.
>>>>
>>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>>> [ ] +0 no opinion
>>>> [ ] -1 disapprove (and reason why)
>>>>
>>>> Here's my (non-binding) +1
>>>>
>>>> Regards
>>>> Martyn
>>>>
>>
>>
>> --
>> Hiram Chirino
>> Engineering | Red Hat, Inc.
>> hchirino@redhat.com | fusesource.com | redhat.com
>> skype: hiramchirino | twitter: @hiramchirino
>>
>
>
--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.bish@redhat.com | www.redhat.com
twitter: @tabish121
blog: http://timbish.blogspot.com/
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Bruce Snyder <br...@gmail.com>.
+1 We debated this some time ago for ActiveMQ and opted for the current
functionality of allowing remote connections by default.
Bruce
On Thu, May 14, 2015 at 9:32 AM, Hiram Chirino <hi...@hiramchirino.com>
wrote:
> I'm not sure that's a good default. ActiveMQ has traditionally
> allowed remote access to it's ports. I think a localhost binding is
> fine for things like management ports, but for the main service the
> product gives it should be on the public ports.
>
> That would be like tomcat or jetty defaulting to binding it's http
> ports to localhost.
>
> On Thu, May 14, 2015 at 11:20 AM, Justin Bertram <jb...@apache.com>
> wrote:
> > IMO the broker correctly binds to localhost only and does not, by
> default, allow connections from remote machines. This is a simple
> security/sanity measure to prevent access to default (i.e. unsecured)
> instances.
> >
> > The merit of this configuration is obviously up for debate, but it's
> worth noting it was done on purpose.
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Jim Gomes" <e....@gmail.com>
> > To: "ActiveMQ Dev" <de...@activemq.apache.org>
> > Sent: Thursday, May 14, 2015 10:05:55 AM
> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >
> > -1
> >
> > Two reasons:
> >
> > 1. The default configuration of localhost for the broker does not allow
> > connections from off-machine. For some reason, socket connections are
> > refused from non-local clients. I had to change the broker.xml config to
> > use the machine's actual IP address, and then non-local clients could
> > connect.
> > 2. The basic NMS OpenWire client fails to connect at all. It is getting
> > unknown response IDs from the broker. I don't think the OpenWire protocol
> > is being negotiated correctly. I am running with the latest NMS trunk
> > version (1.8.0).
> >
> >
> > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> wrote:
> >
> >> Hello all.
> >>
> >> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> >> initial RC feedback from community members.
> >>
> >> This is a first release of the Artemis project with protocol support for
> >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>
> >> The release notes can be found here:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>
> >> The binary distributions can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The source archives can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The Maven repository is here:
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>
> >> The source tag:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>
> >> The project website for that version has been staged to:
> >> http://people.apache.org/~martyntaylor/
> >>
> >> The vote will remain open for 72 hours.
> >>
> >> [ ] +1 approve the release as Apache Artemis 1.0.0
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> Here's my (non-binding) +1
> >>
> >> Regards
> >> Martyn
> >>
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchirino@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
>
--
perl -e 'print
unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Jim Gomes <e....@gmail.com>.
+1 to Hiram's suggestion.
On Thu, May 14, 2015 at 8:32 AM, Hiram Chirino <hi...@hiramchirino.com>
wrote:
> I'm not sure that's a good default. ActiveMQ has traditionally
> allowed remote access to it's ports. I think a localhost binding is
> fine for things like management ports, but for the main service the
> product gives it should be on the public ports.
>
> That would be like tomcat or jetty defaulting to binding it's http
> ports to localhost.
>
> On Thu, May 14, 2015 at 11:20 AM, Justin Bertram <jb...@apache.com>
> wrote:
> > IMO the broker correctly binds to localhost only and does not, by
> default, allow connections from remote machines. This is a simple
> security/sanity measure to prevent access to default (i.e. unsecured)
> instances.
> >
> > The merit of this configuration is obviously up for debate, but it's
> worth noting it was done on purpose.
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Jim Gomes" <e....@gmail.com>
> > To: "ActiveMQ Dev" <de...@activemq.apache.org>
> > Sent: Thursday, May 14, 2015 10:05:55 AM
> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >
> > -1
> >
> > Two reasons:
> >
> > 1. The default configuration of localhost for the broker does not allow
> > connections from off-machine. For some reason, socket connections are
> > refused from non-local clients. I had to change the broker.xml config to
> > use the machine's actual IP address, and then non-local clients could
> > connect.
> > 2. The basic NMS OpenWire client fails to connect at all. It is getting
> > unknown response IDs from the broker. I don't think the OpenWire protocol
> > is being negotiated correctly. I am running with the latest NMS trunk
> > version (1.8.0).
> >
> >
> > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> wrote:
> >
> >> Hello all.
> >>
> >> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> >> initial RC feedback from community members.
> >>
> >> This is a first release of the Artemis project with protocol support for
> >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>
> >> The release notes can be found here:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>
> >> The binary distributions can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The source archives can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The Maven repository is here:
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>
> >> The source tag:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>
> >> The project website for that version has been staged to:
> >> http://people.apache.org/~martyntaylor/
> >>
> >> The vote will remain open for 72 hours.
> >>
> >> [ ] +1 approve the release as Apache Artemis 1.0.0
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> Here's my (non-binding) +1
> >>
> >> Regards
> >> Martyn
> >>
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchirino@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I'm not sure that's a good default. ActiveMQ has traditionally
allowed remote access to it's ports. I think a localhost binding is
fine for things like management ports, but for the main service the
product gives it should be on the public ports.
That would be like tomcat or jetty defaulting to binding it's http
ports to localhost.
On Thu, May 14, 2015 at 11:20 AM, Justin Bertram <jb...@apache.com> wrote:
> IMO the broker correctly binds to localhost only and does not, by default, allow connections from remote machines. This is a simple security/sanity measure to prevent access to default (i.e. unsecured) instances.
>
> The merit of this configuration is obviously up for debate, but it's worth noting it was done on purpose.
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <e....@gmail.com>
> To: "ActiveMQ Dev" <de...@activemq.apache.org>
> Sent: Thursday, May 14, 2015 10:05:55 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> -1
>
> Two reasons:
>
> 1. The default configuration of localhost for the broker does not allow
> connections from off-machine. For some reason, socket connections are
> refused from non-local clients. I had to change the broker.xml config to
> use the machine's actual IP address, and then non-local clients could
> connect.
> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> unknown response IDs from the broker. I don't think the OpenWire protocol
> is being negotiated correctly. I am running with the latest NMS trunk
> version (1.8.0).
>
>
> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com> wrote:
>
>> Hello all.
>>
>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing the
>> initial RC feedback from community members.
>>
>> This is a first release of the Artemis project with protocol support for
>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>
>> The release notes can be found here:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>
>> The binary distributions can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>
>> The source archives can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>
>> The Maven repository is here:
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>
>> The source tag:
>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>
>> The project website for that version has been staged to:
>> http://people.apache.org/~martyntaylor/
>>
>> The vote will remain open for 72 hours.
>>
>> [ ] +1 approve the release as Apache Artemis 1.0.0
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Here's my (non-binding) +1
>>
>> Regards
>> Martyn
>>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Justin Bertram <jb...@apache.com>.
IMO the broker correctly binds to localhost only and does not, by default, allow connections from remote machines. This is a simple security/sanity measure to prevent access to default (i.e. unsecured) instances.
The merit of this configuration is obviously up for debate, but it's worth noting it was done on purpose.
Justin
----- Original Message -----
From: "Jim Gomes" <e....@gmail.com>
To: "ActiveMQ Dev" <de...@activemq.apache.org>
Sent: Thursday, May 14, 2015 10:05:55 AM
Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
-1
Two reasons:
1. The default configuration of localhost for the broker does not allow
connections from off-machine. For some reason, socket connections are
refused from non-local clients. I had to change the broker.xml config to
use the machine's actual IP address, and then non-local clients could
connect.
2. The basic NMS OpenWire client fails to connect at all. It is getting
unknown response IDs from the broker. I don't think the OpenWire protocol
is being negotiated correctly. I am running with the latest NMS trunk
version (1.8.0).
On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com> wrote:
> Hello all.
>
> I've cut a second release candidate of Apache Artemis 1.0.0 addressing the
> initial RC feedback from community members.
>
> This is a first release of the Artemis project with protocol support for
> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>
> The release notes can be found here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>
> The binary distributions can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
> The source archives can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>
> The source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.0.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
> Martyn
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Jim Gomes <e....@gmail.com>.
Yeah, we don't have to have everything fixed, however, ACTIVEMQ6-106 is a
showstopper, because consumers are getting kicked off even when the are
sending KeepAlive and even when they are active. I attached a sample
application to the JIRA that can reproduce the item.
As far as I can tell, the destinations are getting created (at least I
could send/receive messages), but it's throwing a server side exception.
That can be put off as a fix for next release.
On Thu, May 14, 2015 at 12:52 PM, Clebert Suconic <clebert.suconic@gmail.com
> wrote:
> This is going to be the first release... and even the first with
> OpenWire... there certainly going to be other issues.
>
>
> I Think of this like a Beta... people will then have time to kick it
> out and raise issues...
>
> then this should be released very frequently...
>
>
> On Thu, May 14, 2015 at 3:29 PM, Clebert Suconic
> <cl...@gmail.com> wrote:
> > Is that what it is? just setting auto-create to true will fix it?
> >
> >
> > if that's the case... it's an easy fix?
> >
> > On Thu, May 14, 2015 at 3:06 PM, Andy Taylor <an...@gmail.com>
> wrote:
> >> Agreed. But there are lots of them. Let's get 1.0.0 out and then come up
> >> with a migration path for all of them.
> >> On 14 May 2015 20:04, "Jim Gomes" <e....@gmail.com> wrote:
> >>
> >>> It's impossible to run any of the NMS unit tests with destination
> >>> autocreate set to false. If Artemis is meant to be a drop-in
> replacement
> >>> (as much as possible) for ActiveMQ, then we should match feature
> defaults,
> >>> unless there is an definite problem that is being solved by changing
> the
> >>> defaults.
> >>>
> >>> On Thu, May 14, 2015 at 11:55 AM, Andy Taylor <an...@gmail.com>
> >>> wrote:
> >>>
> >>> > I think it's fine to release with auto create set to false. Remember
> >>> 1.0.0
> >>> > is just a starting point. We can discuss what needs changing after
> the
> >>> > release in a separate discussion. I'm sure there will be lots of
> >>> > differences like this but we shouldn't let them block this first
> release.
> >>> >
> >>> > Great job on kicking Artemis's tyres by the way Jim.
> >>> > On 14 May 2015 19:37, "Jim Gomes" <e....@gmail.com> wrote:
> >>> >
> >>> > > Another reason for not releasing this build: the destinations are
> not
> >>> > > automatically created. Server throws
> *ActiveMQNonExistentQueueException
> >>> > > *when
> >>> > > trying to create a destination. Is this a configurable feature? If
> so,
> >>> it
> >>> > > should be set to the standard ActiveMQ behavior by default (i.e.,
> >>> > > auto-create destinations). Here's the exception that gets thrown:
> >>> > >
> >>> > > ERROR [org.apache.activemq.artemis.core.server] error decoding:
> >>> > > ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
> >>> > > message=AMQ119017: Queue
> >>> > >
> jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea
> >>> does
> >>> > > not exist]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
> >>> > > [artemis-server-1.0.0.jar:1.0.0]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
> >>> > > [artemis-server-1.0.0.jar:1.0.0]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
> >>> > > [artemis-server-1.0.0.jar:1.0.0]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
> >>> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
> >>> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> >>> > > at
> >>> > >
> >>> >
> >>>
> org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
> >>> > > [activemq-client-5.10.0.jar:5.10.0]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
> >>> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> >>> > > [artemis-server-1.0.0.jar:1.0.0]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> >>> > > [artemis-core-client-1.0.0.jar:1.0.0]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> >>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> >>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> >>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> >>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>> > > at
> >>> > >
> >>> >
> >>>
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> >>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> >>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> >>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>> > > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> >>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>> > > at
> >>> > >
> >>> > >
> >>> >
> >>>
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> >>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>> > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> >>> > >
> >>> > >
> >>> > > On Thu, May 14, 2015 at 8:05 AM, Jim Gomes <e....@gmail.com>
> wrote:
> >>> > >
> >>> > > > -1
> >>> > > >
> >>> > > > Two reasons:
> >>> > > >
> >>> > > > 1. The default configuration of localhost for the broker does not
> >>> allow
> >>> > > > connections from off-machine. For some reason, socket
> connections are
> >>> > > > refused from non-local clients. I had to change the broker.xml
> config
> >>> > to
> >>> > > > use the machine's actual IP address, and then non-local clients
> could
> >>> > > > connect.
> >>> > > > 2. The basic NMS OpenWire client fails to connect at all. It is
> >>> getting
> >>> > > > unknown response IDs from the broker. I don't think the OpenWire
> >>> > protocol
> >>> > > > is being negotiated correctly. I am running with the latest NMS
> trunk
> >>> > > > version (1.8.0).
> >>> > > >
> >>> > > >
> >>> > > > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <
> mtaylor@redhat.com>
> >>> > > > wrote:
> >>> > > >
> >>> > > >> Hello all.
> >>> > > >>
> >>> > > >> I've cut a second release candidate of Apache Artemis 1.0.0
> >>> addressing
> >>> > > >> the initial RC feedback from community members.
> >>> > > >>
> >>> > > >> This is a first release of the Artemis project with protocol
> support
> >>> > for
> >>> > > >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>> > > >>
> >>> > > >> The release notes can be found here:
> >>> > > >>
> >>> > > >>
> >>> > >
> >>> >
> >>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>> > > >>
> >>> > > >> The binary distributions can be found here:
> >>> > > >>
> >>> > > >>
> >>> > >
> >>> >
> >>>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>> > > >>
> >>> > > >> The source archives can be found here:
> >>> > > >>
> >>> > > >>
> >>> > >
> >>> >
> >>>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>> > > >>
> >>> > > >> The Maven repository is here:
> >>> > > >>
> >>> > >
> >>> >
> >>>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>> > > >>
> >>> > > >> The source tag:
> >>> > > >>
> >>> > > >>
> >>> > >
> >>> >
> >>>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>> > > >>
> >>> > > >> The project website for that version has been staged to:
> >>> > > >> http://people.apache.org/~martyntaylor/
> >>> > > >>
> >>> > > >> The vote will remain open for 72 hours.
> >>> > > >>
> >>> > > >> [ ] +1 approve the release as Apache Artemis 1.0.0
> >>> > > >> [ ] +0 no opinion
> >>> > > >> [ ] -1 disapprove (and reason why)
> >>> > > >>
> >>> > > >> Here's my (non-binding) +1
> >>> > > >>
> >>> > > >> Regards
> >>> > > >> Martyn
> >>> > > >>
> >>> > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> >
> >
> >
> > --
> > Clebert Suconic
> > http://community.jboss.org/people/clebert.suconic@jboss.com
> > http://clebertsuconic.blogspot.com
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suconic@jboss.com
> http://clebertsuconic.blogspot.com
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Clebert Suconic <cl...@gmail.com>.
This is going to be the first release... and even the first with
OpenWire... there certainly going to be other issues.
I Think of this like a Beta... people will then have time to kick it
out and raise issues...
then this should be released very frequently...
On Thu, May 14, 2015 at 3:29 PM, Clebert Suconic
<cl...@gmail.com> wrote:
> Is that what it is? just setting auto-create to true will fix it?
>
>
> if that's the case... it's an easy fix?
>
> On Thu, May 14, 2015 at 3:06 PM, Andy Taylor <an...@gmail.com> wrote:
>> Agreed. But there are lots of them. Let's get 1.0.0 out and then come up
>> with a migration path for all of them.
>> On 14 May 2015 20:04, "Jim Gomes" <e....@gmail.com> wrote:
>>
>>> It's impossible to run any of the NMS unit tests with destination
>>> autocreate set to false. If Artemis is meant to be a drop-in replacement
>>> (as much as possible) for ActiveMQ, then we should match feature defaults,
>>> unless there is an definite problem that is being solved by changing the
>>> defaults.
>>>
>>> On Thu, May 14, 2015 at 11:55 AM, Andy Taylor <an...@gmail.com>
>>> wrote:
>>>
>>> > I think it's fine to release with auto create set to false. Remember
>>> 1.0.0
>>> > is just a starting point. We can discuss what needs changing after the
>>> > release in a separate discussion. I'm sure there will be lots of
>>> > differences like this but we shouldn't let them block this first release.
>>> >
>>> > Great job on kicking Artemis's tyres by the way Jim.
>>> > On 14 May 2015 19:37, "Jim Gomes" <e....@gmail.com> wrote:
>>> >
>>> > > Another reason for not releasing this build: the destinations are not
>>> > > automatically created. Server throws *ActiveMQNonExistentQueueException
>>> > > *when
>>> > > trying to create a destination. Is this a configurable feature? If so,
>>> it
>>> > > should be set to the standard ActiveMQ behavior by default (i.e.,
>>> > > auto-create destinations). Here's the exception that gets thrown:
>>> > >
>>> > > ERROR [org.apache.activemq.artemis.core.server] error decoding:
>>> > > ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
>>> > > message=AMQ119017: Queue
>>> > > jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea
>>> does
>>> > > not exist]
>>> > > at
>>> > >
>>> > >
>>> >
>>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
>>> > > [artemis-server-1.0.0.jar:1.0.0]
>>> > > at
>>> > >
>>> > >
>>> >
>>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
>>> > > [artemis-server-1.0.0.jar:1.0.0]
>>> > > at
>>> > >
>>> > >
>>> >
>>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
>>> > > [artemis-server-1.0.0.jar:1.0.0]
>>> > > at
>>> > >
>>> > >
>>> >
>>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
>>> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>>> > > at
>>> > >
>>> > >
>>> >
>>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
>>> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>>> > > at
>>> > >
>>> >
>>> org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
>>> > > [activemq-client-5.10.0.jar:5.10.0]
>>> > > at
>>> > >
>>> > >
>>> >
>>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
>>> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>>> > > at
>>> > >
>>> > >
>>> >
>>> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
>>> > > [artemis-server-1.0.0.jar:1.0.0]
>>> > > at
>>> > >
>>> > >
>>> >
>>> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
>>> > > [artemis-core-client-1.0.0.jar:1.0.0]
>>> > > at
>>> > >
>>> > >
>>> >
>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
>>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>> > > at
>>> > >
>>> > >
>>> >
>>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
>>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>> > > at
>>> > >
>>> > >
>>> >
>>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>> > > at
>>> > >
>>> > >
>>> >
>>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
>>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>> > > at
>>> > >
>>> >
>>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
>>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>> > > at
>>> > >
>>> > >
>>> >
>>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
>>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>> > > at
>>> > >
>>> > >
>>> >
>>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
>>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>> > > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
>>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>> > > at
>>> > >
>>> > >
>>> >
>>> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>> > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>>> > >
>>> > >
>>> > > On Thu, May 14, 2015 at 8:05 AM, Jim Gomes <e....@gmail.com> wrote:
>>> > >
>>> > > > -1
>>> > > >
>>> > > > Two reasons:
>>> > > >
>>> > > > 1. The default configuration of localhost for the broker does not
>>> allow
>>> > > > connections from off-machine. For some reason, socket connections are
>>> > > > refused from non-local clients. I had to change the broker.xml config
>>> > to
>>> > > > use the machine's actual IP address, and then non-local clients could
>>> > > > connect.
>>> > > > 2. The basic NMS OpenWire client fails to connect at all. It is
>>> getting
>>> > > > unknown response IDs from the broker. I don't think the OpenWire
>>> > protocol
>>> > > > is being negotiated correctly. I am running with the latest NMS trunk
>>> > > > version (1.8.0).
>>> > > >
>>> > > >
>>> > > > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
>>> > > > wrote:
>>> > > >
>>> > > >> Hello all.
>>> > > >>
>>> > > >> I've cut a second release candidate of Apache Artemis 1.0.0
>>> addressing
>>> > > >> the initial RC feedback from community members.
>>> > > >>
>>> > > >> This is a first release of the Artemis project with protocol support
>>> > for
>>> > > >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>> > > >>
>>> > > >> The release notes can be found here:
>>> > > >>
>>> > > >>
>>> > >
>>> >
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>> > > >>
>>> > > >> The binary distributions can be found here:
>>> > > >>
>>> > > >>
>>> > >
>>> >
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>> > > >>
>>> > > >> The source archives can be found here:
>>> > > >>
>>> > > >>
>>> > >
>>> >
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>> > > >>
>>> > > >> The Maven repository is here:
>>> > > >>
>>> > >
>>> >
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>> > > >>
>>> > > >> The source tag:
>>> > > >>
>>> > > >>
>>> > >
>>> >
>>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>> > > >>
>>> > > >> The project website for that version has been staged to:
>>> > > >> http://people.apache.org/~martyntaylor/
>>> > > >>
>>> > > >> The vote will remain open for 72 hours.
>>> > > >>
>>> > > >> [ ] +1 approve the release as Apache Artemis 1.0.0
>>> > > >> [ ] +0 no opinion
>>> > > >> [ ] -1 disapprove (and reason why)
>>> > > >>
>>> > > >> Here's my (non-binding) +1
>>> > > >>
>>> > > >> Regards
>>> > > >> Martyn
>>> > > >>
>>> > > >
>>> > > >
>>> > >
>>> >
>>>
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suconic@jboss.com
> http://clebertsuconic.blogspot.com
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Clebert Suconic <cl...@gmail.com>.
Is that what it is? just setting auto-create to true will fix it?
if that's the case... it's an easy fix?
On Thu, May 14, 2015 at 3:06 PM, Andy Taylor <an...@gmail.com> wrote:
> Agreed. But there are lots of them. Let's get 1.0.0 out and then come up
> with a migration path for all of them.
> On 14 May 2015 20:04, "Jim Gomes" <e....@gmail.com> wrote:
>
>> It's impossible to run any of the NMS unit tests with destination
>> autocreate set to false. If Artemis is meant to be a drop-in replacement
>> (as much as possible) for ActiveMQ, then we should match feature defaults,
>> unless there is an definite problem that is being solved by changing the
>> defaults.
>>
>> On Thu, May 14, 2015 at 11:55 AM, Andy Taylor <an...@gmail.com>
>> wrote:
>>
>> > I think it's fine to release with auto create set to false. Remember
>> 1.0.0
>> > is just a starting point. We can discuss what needs changing after the
>> > release in a separate discussion. I'm sure there will be lots of
>> > differences like this but we shouldn't let them block this first release.
>> >
>> > Great job on kicking Artemis's tyres by the way Jim.
>> > On 14 May 2015 19:37, "Jim Gomes" <e....@gmail.com> wrote:
>> >
>> > > Another reason for not releasing this build: the destinations are not
>> > > automatically created. Server throws *ActiveMQNonExistentQueueException
>> > > *when
>> > > trying to create a destination. Is this a configurable feature? If so,
>> it
>> > > should be set to the standard ActiveMQ behavior by default (i.e.,
>> > > auto-create destinations). Here's the exception that gets thrown:
>> > >
>> > > ERROR [org.apache.activemq.artemis.core.server] error decoding:
>> > > ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
>> > > message=AMQ119017: Queue
>> > > jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea
>> does
>> > > not exist]
>> > > at
>> > >
>> > >
>> >
>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
>> > > [artemis-server-1.0.0.jar:1.0.0]
>> > > at
>> > >
>> > >
>> >
>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
>> > > [artemis-server-1.0.0.jar:1.0.0]
>> > > at
>> > >
>> > >
>> >
>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
>> > > [artemis-server-1.0.0.jar:1.0.0]
>> > > at
>> > >
>> > >
>> >
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
>> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> > > at
>> > >
>> > >
>> >
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
>> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> > > at
>> > >
>> >
>> org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
>> > > [activemq-client-5.10.0.jar:5.10.0]
>> > > at
>> > >
>> > >
>> >
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
>> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> > > at
>> > >
>> > >
>> >
>> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
>> > > [artemis-server-1.0.0.jar:1.0.0]
>> > > at
>> > >
>> > >
>> >
>> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
>> > > [artemis-core-client-1.0.0.jar:1.0.0]
>> > > at
>> > >
>> > >
>> >
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> > > at
>> > >
>> > >
>> >
>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> > > at
>> > >
>> > >
>> >
>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> > > at
>> > >
>> > >
>> >
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> > > at
>> > >
>> >
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> > > at
>> > >
>> > >
>> >
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> > > at
>> > >
>> > >
>> >
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> > > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> > > at
>> > >
>> > >
>> >
>> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>> > >
>> > >
>> > > On Thu, May 14, 2015 at 8:05 AM, Jim Gomes <e....@gmail.com> wrote:
>> > >
>> > > > -1
>> > > >
>> > > > Two reasons:
>> > > >
>> > > > 1. The default configuration of localhost for the broker does not
>> allow
>> > > > connections from off-machine. For some reason, socket connections are
>> > > > refused from non-local clients. I had to change the broker.xml config
>> > to
>> > > > use the machine's actual IP address, and then non-local clients could
>> > > > connect.
>> > > > 2. The basic NMS OpenWire client fails to connect at all. It is
>> getting
>> > > > unknown response IDs from the broker. I don't think the OpenWire
>> > protocol
>> > > > is being negotiated correctly. I am running with the latest NMS trunk
>> > > > version (1.8.0).
>> > > >
>> > > >
>> > > > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
>> > > > wrote:
>> > > >
>> > > >> Hello all.
>> > > >>
>> > > >> I've cut a second release candidate of Apache Artemis 1.0.0
>> addressing
>> > > >> the initial RC feedback from community members.
>> > > >>
>> > > >> This is a first release of the Artemis project with protocol support
>> > for
>> > > >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>> > > >>
>> > > >> The release notes can be found here:
>> > > >>
>> > > >>
>> > >
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>> > > >>
>> > > >> The binary distributions can be found here:
>> > > >>
>> > > >>
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>> > > >>
>> > > >> The source archives can be found here:
>> > > >>
>> > > >>
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>> > > >>
>> > > >> The Maven repository is here:
>> > > >>
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>> > > >>
>> > > >> The source tag:
>> > > >>
>> > > >>
>> > >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>> > > >>
>> > > >> The project website for that version has been staged to:
>> > > >> http://people.apache.org/~martyntaylor/
>> > > >>
>> > > >> The vote will remain open for 72 hours.
>> > > >>
>> > > >> [ ] +1 approve the release as Apache Artemis 1.0.0
>> > > >> [ ] +0 no opinion
>> > > >> [ ] -1 disapprove (and reason why)
>> > > >>
>> > > >> Here's my (non-binding) +1
>> > > >>
>> > > >> Regards
>> > > >> Martyn
>> > > >>
>> > > >
>> > > >
>> > >
>> >
>>
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Andy Taylor <an...@gmail.com>.
Agreed. But there are lots of them. Let's get 1.0.0 out and then come up
with a migration path for all of them.
On 14 May 2015 20:04, "Jim Gomes" <e....@gmail.com> wrote:
> It's impossible to run any of the NMS unit tests with destination
> autocreate set to false. If Artemis is meant to be a drop-in replacement
> (as much as possible) for ActiveMQ, then we should match feature defaults,
> unless there is an definite problem that is being solved by changing the
> defaults.
>
> On Thu, May 14, 2015 at 11:55 AM, Andy Taylor <an...@gmail.com>
> wrote:
>
> > I think it's fine to release with auto create set to false. Remember
> 1.0.0
> > is just a starting point. We can discuss what needs changing after the
> > release in a separate discussion. I'm sure there will be lots of
> > differences like this but we shouldn't let them block this first release.
> >
> > Great job on kicking Artemis's tyres by the way Jim.
> > On 14 May 2015 19:37, "Jim Gomes" <e....@gmail.com> wrote:
> >
> > > Another reason for not releasing this build: the destinations are not
> > > automatically created. Server throws *ActiveMQNonExistentQueueException
> > > *when
> > > trying to create a destination. Is this a configurable feature? If so,
> it
> > > should be set to the standard ActiveMQ behavior by default (i.e.,
> > > auto-create destinations). Here's the exception that gets thrown:
> > >
> > > ERROR [org.apache.activemq.artemis.core.server] error decoding:
> > > ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
> > > message=AMQ119017: Queue
> > > jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea
> does
> > > not exist]
> > > at
> > >
> > >
> >
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
> > > [artemis-server-1.0.0.jar:1.0.0]
> > > at
> > >
> > >
> >
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
> > > [artemis-server-1.0.0.jar:1.0.0]
> > > at
> > >
> > >
> >
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
> > > [artemis-server-1.0.0.jar:1.0.0]
> > > at
> > >
> > >
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > > at
> > >
> > >
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > > at
> > >
> >
> org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
> > > [activemq-client-5.10.0.jar:5.10.0]
> > > at
> > >
> > >
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
> > > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > > at
> > >
> > >
> >
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> > > [artemis-server-1.0.0.jar:1.0.0]
> > > at
> > >
> > >
> >
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> > > [artemis-core-client-1.0.0.jar:1.0.0]
> > > at
> > >
> > >
> >
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> > >
> >
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> > >
> >
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> > >
> >
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> > >
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> > >
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at
> > >
> > >
> >
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> > > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> > >
> > >
> > > On Thu, May 14, 2015 at 8:05 AM, Jim Gomes <e....@gmail.com> wrote:
> > >
> > > > -1
> > > >
> > > > Two reasons:
> > > >
> > > > 1. The default configuration of localhost for the broker does not
> allow
> > > > connections from off-machine. For some reason, socket connections are
> > > > refused from non-local clients. I had to change the broker.xml config
> > to
> > > > use the machine's actual IP address, and then non-local clients could
> > > > connect.
> > > > 2. The basic NMS OpenWire client fails to connect at all. It is
> getting
> > > > unknown response IDs from the broker. I don't think the OpenWire
> > protocol
> > > > is being negotiated correctly. I am running with the latest NMS trunk
> > > > version (1.8.0).
> > > >
> > > >
> > > > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> > > > wrote:
> > > >
> > > >> Hello all.
> > > >>
> > > >> I've cut a second release candidate of Apache Artemis 1.0.0
> addressing
> > > >> the initial RC feedback from community members.
> > > >>
> > > >> This is a first release of the Artemis project with protocol support
> > for
> > > >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> > > >>
> > > >> The release notes can be found here:
> > > >>
> > > >>
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> > > >>
> > > >> The binary distributions can be found here:
> > > >>
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> > > >>
> > > >> The source archives can be found here:
> > > >>
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> > > >>
> > > >> The Maven repository is here:
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> > > >>
> > > >> The source tag:
> > > >>
> > > >>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> > > >>
> > > >> The project website for that version has been staged to:
> > > >> http://people.apache.org/~martyntaylor/
> > > >>
> > > >> The vote will remain open for 72 hours.
> > > >>
> > > >> [ ] +1 approve the release as Apache Artemis 1.0.0
> > > >> [ ] +0 no opinion
> > > >> [ ] -1 disapprove (and reason why)
> > > >>
> > > >> Here's my (non-binding) +1
> > > >>
> > > >> Regards
> > > >> Martyn
> > > >>
> > > >
> > > >
> > >
> >
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Jim Gomes <e....@gmail.com>.
It's impossible to run any of the NMS unit tests with destination
autocreate set to false. If Artemis is meant to be a drop-in replacement
(as much as possible) for ActiveMQ, then we should match feature defaults,
unless there is an definite problem that is being solved by changing the
defaults.
On Thu, May 14, 2015 at 11:55 AM, Andy Taylor <an...@gmail.com>
wrote:
> I think it's fine to release with auto create set to false. Remember 1.0.0
> is just a starting point. We can discuss what needs changing after the
> release in a separate discussion. I'm sure there will be lots of
> differences like this but we shouldn't let them block this first release.
>
> Great job on kicking Artemis's tyres by the way Jim.
> On 14 May 2015 19:37, "Jim Gomes" <e....@gmail.com> wrote:
>
> > Another reason for not releasing this build: the destinations are not
> > automatically created. Server throws *ActiveMQNonExistentQueueException
> > *when
> > trying to create a destination. Is this a configurable feature? If so, it
> > should be set to the standard ActiveMQ behavior by default (i.e.,
> > auto-create destinations). Here's the exception that gets thrown:
> >
> > ERROR [org.apache.activemq.artemis.core.server] error decoding:
> > ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
> > message=AMQ119017: Queue
> > jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea does
> > not exist]
> > at
> >
> >
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
> > [artemis-server-1.0.0.jar:1.0.0]
> > at
> >
> >
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
> > [artemis-server-1.0.0.jar:1.0.0]
> > at
> >
> >
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
> > [artemis-server-1.0.0.jar:1.0.0]
> > at
> >
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
> > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > at
> >
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
> > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > at
> >
> org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
> > [activemq-client-5.10.0.jar:5.10.0]
> > at
> >
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
> > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> > at
> >
> >
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> > [artemis-server-1.0.0.jar:1.0.0]
> > at
> >
> >
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> > [artemis-core-client-1.0.0.jar:1.0.0]
> > at
> >
> >
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> >
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> >
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> >
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at
> >
> >
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> >
> >
> > On Thu, May 14, 2015 at 8:05 AM, Jim Gomes <e....@gmail.com> wrote:
> >
> > > -1
> > >
> > > Two reasons:
> > >
> > > 1. The default configuration of localhost for the broker does not allow
> > > connections from off-machine. For some reason, socket connections are
> > > refused from non-local clients. I had to change the broker.xml config
> to
> > > use the machine's actual IP address, and then non-local clients could
> > > connect.
> > > 2. The basic NMS OpenWire client fails to connect at all. It is getting
> > > unknown response IDs from the broker. I don't think the OpenWire
> protocol
> > > is being negotiated correctly. I am running with the latest NMS trunk
> > > version (1.8.0).
> > >
> > >
> > > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> > > wrote:
> > >
> > >> Hello all.
> > >>
> > >> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> > >> the initial RC feedback from community members.
> > >>
> > >> This is a first release of the Artemis project with protocol support
> for
> > >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> > >>
> > >> The release notes can be found here:
> > >>
> > >>
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> > >>
> > >> The binary distributions can be found here:
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> > >>
> > >> The source archives can be found here:
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> > >>
> > >> The Maven repository is here:
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> > >>
> > >> The source tag:
> > >>
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> > >>
> > >> The project website for that version has been staged to:
> > >> http://people.apache.org/~martyntaylor/
> > >>
> > >> The vote will remain open for 72 hours.
> > >>
> > >> [ ] +1 approve the release as Apache Artemis 1.0.0
> > >> [ ] +0 no opinion
> > >> [ ] -1 disapprove (and reason why)
> > >>
> > >> Here's my (non-binding) +1
> > >>
> > >> Regards
> > >> Martyn
> > >>
> > >
> > >
> >
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Andy Taylor <an...@gmail.com>.
I think it's fine to release with auto create set to false. Remember 1.0.0
is just a starting point. We can discuss what needs changing after the
release in a separate discussion. I'm sure there will be lots of
differences like this but we shouldn't let them block this first release.
Great job on kicking Artemis's tyres by the way Jim.
On 14 May 2015 19:37, "Jim Gomes" <e....@gmail.com> wrote:
> Another reason for not releasing this build: the destinations are not
> automatically created. Server throws *ActiveMQNonExistentQueueException
> *when
> trying to create a destination. Is this a configurable feature? If so, it
> should be set to the standard ActiveMQ behavior by default (i.e.,
> auto-create destinations). Here's the exception that gets thrown:
>
> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
> message=AMQ119017: Queue
> jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea does
> not exist]
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
> [artemis-server-1.0.0.jar:1.0.0]
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
> [artemis-server-1.0.0.jar:1.0.0]
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
> [artemis-server-1.0.0.jar:1.0.0]
> at
>
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
>
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
> [activemq-client-5.10.0.jar:5.10.0]
> at
>
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
>
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> [artemis-server-1.0.0.jar:1.0.0]
> at
>
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> [artemis-core-client-1.0.0.jar:1.0.0]
> at
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
>
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
>
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
>
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
>
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
>
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
>
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>
> On Thu, May 14, 2015 at 8:05 AM, Jim Gomes <e....@gmail.com> wrote:
>
> > -1
> >
> > Two reasons:
> >
> > 1. The default configuration of localhost for the broker does not allow
> > connections from off-machine. For some reason, socket connections are
> > refused from non-local clients. I had to change the broker.xml config to
> > use the machine's actual IP address, and then non-local clients could
> > connect.
> > 2. The basic NMS OpenWire client fails to connect at all. It is getting
> > unknown response IDs from the broker. I don't think the OpenWire protocol
> > is being negotiated correctly. I am running with the latest NMS trunk
> > version (1.8.0).
> >
> >
> > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> > wrote:
> >
> >> Hello all.
> >>
> >> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> >> the initial RC feedback from community members.
> >>
> >> This is a first release of the Artemis project with protocol support for
> >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>
> >> The release notes can be found here:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>
> >> The binary distributions can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The source archives can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The Maven repository is here:
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>
> >> The source tag:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>
> >> The project website for that version has been staged to:
> >> http://people.apache.org/~martyntaylor/
> >>
> >> The vote will remain open for 72 hours.
> >>
> >> [ ] +1 approve the release as Apache Artemis 1.0.0
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> Here's my (non-binding) +1
> >>
> >> Regards
> >> Martyn
> >>
> >
> >
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Jim Gomes <e....@gmail.com>.
The resource clean up code for dead clients doesn't seem to work reliably.
Probably not a show-stopper for a beta release, but definitely needs to be
cleaned up for production. Basically, when Artemis detected a dead client
(it stopped responding because I hit a breakpoint in my debugger), it tried
to clean it up, but failed. The result is that I can no longer connect a
new client from that client machine, because the broker thinks I already
have a connection. This is after I killed my client app and restarted it.
I'll log a bug for this one, but here's the server log:
WARN [org.apache.activemq.artemis.core.server] AMQ222067: Connection
failure has been detected: AMQ119014: Did not receive data from
/xxx.xxx.xxx.xxx:53516. It is likely the client has exited or crashed
without closing its connection, or the network between the server and
client has failed. You also might have configured connection-ttl and
client-failure-check-period incorrectly. Please check user manual for more
information. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client
connection failed, clearing up resources for session
ID:testmachine-63273-635671999039695375-1:0:-1
WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up
resources for session ID:testmachine-63273-635671999039695375-1:0:-1
WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client
connection failed, clearing up resources for session
ID:testmachine-63273-635671999039695375-1:0:1
WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up
resources for session ID:testmachine-63273-635671999039695375-1:0:1
*INFO [org.apache.activemq.artemis.core.server] AMQ221021: failed to
remove connection*
Attempting to run a fresh client gets the following return exception on the
client:
Apache.NMS.Test.AsyncConsumeTest.TestAsynchronousConsume(Persistent):
Apache.NMS.InvalidClientIDException : Broker: mybroker - Client:
ID:AsyncConsumeTest:1:2 already connected from /xxx.xxx.xxx.xxx:53516
On Thu, May 14, 2015 at 11:37 AM, Jim Gomes <e....@gmail.com> wrote:
> Another reason for not releasing this build: the destinations are not
> automatically created. Server throws *ActiveMQNonExistentQueueException *when
> trying to create a destination. Is this a configurable feature? If so, it
> should be set to the standard ActiveMQ behavior by default (i.e.,
> auto-create destinations). Here's the exception that gets thrown:
>
> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
> message=AMQ119017: Queue
> jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea does
> not exist]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
> [artemis-server-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
> [artemis-server-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
> [artemis-server-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
> [activemq-client-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> [artemis-server-1.0.0.jar:1.0.0]
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> [artemis-core-client-1.0.0.jar:1.0.0]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>
> On Thu, May 14, 2015 at 8:05 AM, Jim Gomes <e....@gmail.com> wrote:
>
>> -1
>>
>> Two reasons:
>>
>> 1. The default configuration of localhost for the broker does not allow
>> connections from off-machine. For some reason, socket connections are
>> refused from non-local clients. I had to change the broker.xml config to
>> use the machine's actual IP address, and then non-local clients could
>> connect.
>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>> unknown response IDs from the broker. I don't think the OpenWire protocol
>> is being negotiated correctly. I am running with the latest NMS trunk
>> version (1.8.0).
>>
>>
>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
>> wrote:
>>
>>> Hello all.
>>>
>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>>> the initial RC feedback from community members.
>>>
>>> This is a first release of the Artemis project with protocol support for
>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>
>>> The release notes can be found here:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>
>>> The binary distributions can be found here:
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The source archives can be found here:
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The Maven repository is here:
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>
>>> The source tag:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>
>>> The project website for that version has been staged to:
>>> http://people.apache.org/~martyntaylor/
>>>
>>> The vote will remain open for 72 hours.
>>>
>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>> [ ] +0 no opinion
>>> [ ] -1 disapprove (and reason why)
>>>
>>> Here's my (non-binding) +1
>>>
>>> Regards
>>> Martyn
>>>
>>
>>
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Jim Gomes <e....@gmail.com>.
Another reason for not releasing this build: the destinations are not
automatically created. Server throws *ActiveMQNonExistentQueueException *when
trying to create a destination. Is this a configurable feature? If so, it
should be set to the standard ActiveMQ behavior by default (i.e.,
auto-create destinations). Here's the exception that gets thrown:
ERROR [org.apache.activemq.artemis.core.server] error decoding:
ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
message=AMQ119017: Queue
jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea does
not exist]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
[activemq-client-5.10.0.jar:5.10.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
On Thu, May 14, 2015 at 8:05 AM, Jim Gomes <e....@gmail.com> wrote:
> -1
>
> Two reasons:
>
> 1. The default configuration of localhost for the broker does not allow
> connections from off-machine. For some reason, socket connections are
> refused from non-local clients. I had to change the broker.xml config to
> use the machine's actual IP address, and then non-local clients could
> connect.
> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> unknown response IDs from the broker. I don't think the OpenWire protocol
> is being negotiated correctly. I am running with the latest NMS trunk
> version (1.8.0).
>
>
> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com>
> wrote:
>
>> Hello all.
>>
>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the initial RC feedback from community members.
>>
>> This is a first release of the Artemis project with protocol support for
>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>
>> The release notes can be found here:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>
>> The binary distributions can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>
>> The source archives can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>
>> The Maven repository is here:
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>
>> The source tag:
>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>
>> The project website for that version has been staged to:
>> http://people.apache.org/~martyntaylor/
>>
>> The vote will remain open for 72 hours.
>>
>> [ ] +1 approve the release as Apache Artemis 1.0.0
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Here's my (non-binding) +1
>>
>> Regards
>> Martyn
>>
>
>
Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Jim Gomes <e....@gmail.com>.
-1
Two reasons:
1. The default configuration of localhost for the broker does not allow
connections from off-machine. For some reason, socket connections are
refused from non-local clients. I had to change the broker.xml config to
use the machine's actual IP address, and then non-local clients could
connect.
2. The basic NMS OpenWire client fails to connect at all. It is getting
unknown response IDs from the broker. I don't think the OpenWire protocol
is being negotiated correctly. I am running with the latest NMS trunk
version (1.8.0).
On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mt...@redhat.com> wrote:
> Hello all.
>
> I've cut a second release candidate of Apache Artemis 1.0.0 addressing the
> initial RC feedback from community members.
>
> This is a first release of the Artemis project with protocol support for
> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>
> The release notes can be found here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>
> The binary distributions can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
> The source archives can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>
> The source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.0.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
> Martyn
>
[CANCEL][VOTE] Apache Artemis 1.0.0 (RC2)
Posted by Martyn Taylor <mt...@redhat.com>.
Cancelling the vote for RC2. Will follow up shortly with another RC cut
with fixes for the issues discussed in this thread.
On 13/05/15 18:12, Martyn Taylor wrote:
> Hello all.
>
> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the initial RC feedback from community members.
>
> This is a first release of the Artemis project with protocol support
> for AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>
>
> The binary distributions can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
>
> The source archives can be found here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>
>
> The source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.0.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
> Martyn