[VOTE] Apache Artemis 1.0.0 (RC2)

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

jgomes
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 <[hidden email]> 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 <[hidden email]>
> 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
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

jgomes
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

andytaylor
In reply to this post by jgomes
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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
> >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

Justin Bertram-2
In reply to this post by andytaylor
> 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" <[hidden email]>
To: [hidden email]
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" <[hidden email]> 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" <[hidden email]>
> To: [hidden email]
> 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" <[hidden email]>
> > To: "ActiveMQ Dev" <[hidden email]>
> > 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 <[hidden email]>
> 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" <[hidden email]>
> >> To: "ActiveMQ Dev" <[hidden email]>
> >> 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 <[hidden email]>
> >> 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
> >>>
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

andytaylor
I'd be happy either way.
On 14 May 2015 20:00, "Justin Bertram" <[hidden email]> 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" <[hidden email]>
> To: [hidden email]
> 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" <[hidden email]> 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" <[hidden email]>
> > To: [hidden email]
> > 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" <[hidden email]>
> > > To: "ActiveMQ Dev" <[hidden email]>
> > > 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 <[hidden email]>
> > 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" <[hidden email]>
> > >> To: "ActiveMQ Dev" <[hidden email]>
> > >> 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 <[hidden email]>
> > >> 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
> > >>>
> > >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

jgomes
In reply to this post by andytaylor
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 <[hidden email]>
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > 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
> > >>
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

andytaylor
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" <[hidden email]> 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 <[hidden email]>
> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > > 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
> > > >>
> > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

clebertsuconic
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> > > > 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@...
http://clebertsuconic.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

clebertsuconic
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
<[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> > > > 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@...
> http://clebertsuconic.blogspot.com



--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@...
http://clebertsuconic.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

jgomes
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 <[hidden email]
> 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
> <[hidden email]> 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 <[hidden email]>
> 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" <[hidden email]> 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 <[hidden email]>
> >>> 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" <[hidden email]> 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 <[hidden email]>
> 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 <
> [hidden email]>
> >>> > > > 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@...
> > http://clebertsuconic.blogspot.com
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suconic@...
> http://clebertsuconic.blogspot.com
>
Reply | Threaded
Open this post in threaded view
|

[CANCEL][VOTE] Apache Artemis 1.0.0 (RC2)

Martyn Taylor
In reply to this post by Martyn Taylor
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

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

Robbie Gemmell
In reply to this post by Martyn Taylor
On 13 May 2015 at 18:12, Martyn Taylor <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

gaohoward
+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 <[hidden email]>
wrote:

> On 13 May 2015 at 18:12, Martyn Taylor <[hidden email]> 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
>
12