[GitHub] activemq-artemis issue #907: ARTEMIS-883 Fix OpenWire ProducerFlowControlTes...

[gaohoward]

Github user gaohoward commented on the issue:

https://github.com/apache/activemq-artemis/pull/907
  
@clebertsuconic the openwire tests all pass now. I think it's ready for 
review.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE] Apache ActiveMQ 5.14.3

[Christian Schneider]

+1 (non binding)

Christian

2016-12-20 19:17 GMT+01:00 Claus Ibsen :

> +1
>
> Tested with latest Apache Camel code
>
> On Mon, Dec 19, 2016 at 4:49 PM, Christopher Shannon
>  wrote:
> > Hi Everyone,
> >
> > I have created the ActiveMQ 5.14.3 release and it's ready for a vote.
> > This release contains 7 important fixes that didn't make it into the
> > last release.
> >
> > The list of resolved issues is here:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12311210=12338822
> >
> > You can get binary distributions here:
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1113/org/apache/activemq/apache-activemq/5.14.3/
> >
> > Source archives are here:
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1113/org/apache/activemq/activemq-parent/5.14.3/
> >
> > Maven repository is at:
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1113/
> >
> > Source tag: https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=
> commit;h=58dddb9181912bee60fec480d90e05be4ca3a044
> >
> > Please vote to approve this release.  The vote will remain open for 72
> hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.14.3
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Matt Pavlovich]

On 12/20/16 4:14 PM, Clebert Suconic wrote:


On Tue, Dec 20, 2016 at 4:42 PM, Matt Pavlovich  wrote:

I'm not trying to focus on the impl. My goal was to share how users are able
to

...configure advisories based on a group of destinations


That to me is very, very specific to ActiveMQ5
I am not sure you really need that on Artemis, do you?
Yep, its useful. IBM MQ can do the same on a per-destination basis. The 
benefit ActiveMQ 5.x has over IBM MQ is that you can apply a 
configuration based on a destination filter vs having to configure each 
queue individually.



  and that there is a

gap in Artemis from a functionality perspective.

Three different things:

1. The gap of specific Advisories/Notifications in Artemis v ActiveMQ 5

2. How Advisories/Notifications are implemented in Artemis plugin vs core
feature.

3. How Advisories/Notifications are configured in Artemis

That will be a different API, but that's totally possible to receive
notifications:

http://activemq.apache.org/artemis/docs/1.5.1/management.html

Instead of bringing a new API (Advisory) we could/should look at what
notifications are missing and implement them.
Yeah, I'm not married to a specific implementation. This management 
notification piece is new info to me. I was under the impression that 
Advisories of some sort (notifications in Artemis) were at 0% 
implemented. I need to dig into this some more.



There are a lot of cool *totally* new things I think we should/could
work on. for instance I'm trying to improve / fix message encoding
between different protocols (only re-encode a message when needed),
and making GC closer to zero by always reusing buffers... That will be
a killing feature... I'm not posting a DISCUSS about that yet as I'm
still battling over the code and how I am going to work on that. I
will post about it after my holiday's break.

+1 eliminating memory copy of payload is super valuable

I didn't mean to sidetrack the Plugins discussion to 
Advisory/Notification.. now back to the plugins discussion ...

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Clebert Suconic]

On Tue, Dec 20, 2016 at 4:42 PM, Matt Pavlovich  wrote:
> I'm not trying to focus on the impl. My goal was to share how users are able
> to

...configure advisories based on a group of destinations


That to me is very, very specific to ActiveMQ5
I am not sure you really need that on Artemis, do you?


 and that there is a
> gap in Artemis from a functionality perspective.
>
> Three different things:
>
> 1. The gap of specific Advisories/Notifications in Artemis v ActiveMQ 5
>
> 2. How Advisories/Notifications are implemented in Artemis plugin vs core
> feature.
>
> 3. How Advisories/Notifications are configured in Artemis

That will be a different API, but that's totally possible to receive
notifications:

http://activemq.apache.org/artemis/docs/1.5.1/management.html

Instead of bringing a new API (Advisory) we could/should look at what
notifications are missing and implement them.




There are a lot of cool *totally* new things I think we should/could
work on. for instance I'm trying to improve / fix message encoding
between different protocols (only re-encode a message when needed),
and making GC closer to zero by always reusing buffers... That will be
a killing feature... I'm not posting a DISCUSS about that yet as I'm
still battling over the code and how I am going to work on that. I
will post about it after my holiday's break.

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Matt Pavlovich]

I'm not trying to focus on the impl. My goal was to share how users are 
able to configure advisories based on a group of destinations and that 
there is a gap in Artemis from a functionality perspective.


Three different things:

1. The gap of specific Advisories/Notifications in Artemis v ActiveMQ 5

2. How Advisories/Notifications are implemented in Artemis plugin vs 
core feature.


3. How Advisories/Notifications are configured in Artemis

My comments were meant to be an echo of Christopher Shannon's comment 
that implementing Advisories/Notifications as a plugin in Artemis would 
allow for encapsulation, which would be handy for users/admins.


-Matt Pavlovich

On 12/20/16 3:23 PM, Clebert Suconic wrote:

Notification are also sent over topics... (they are actually sent over
Addresses, so it could be anything).

You're getting too hung on the implementation details.. why it has to
be this specific interface?

 From what I looked, the advisory API is a natural mirror of the
broker's implementation.. it fits well with AMQ5, while it will be
some work to be implemented in Artemis.

Feel free to prove me wrong.. but I would use the time into some more
compelling feature. While we battle over specific implementations...
you lose space for other servers that don't even care about the
broker's battle.

On Tue, Dec 20, 2016 at 4:14 PM, Matt Pavlovich  wrote:

Clebert-

That is a good start on the advisories. However, the real world use cases
get complicated when there is mixed configuration based on destination
names. Take the case when you need to haven different behavior for sets of
destinations queue://Billing.> vs queue://Ordering.>.

advisoryForConsumed, advisoryForDelivery, advisoryForFastProducers,
advisoryForSlowConsumers, advisoryWhenFull

Ref: http://activemq.apache.org/per-destination-policies.html

Also, given that advisories are currently sent over topics, there are a
number of use cases where you can almost never get the advisory (broker
becomes master, etc) b/c of the race condition b/w the advisory and having
to have an active topic subscriber. IIRC ActiveMQ doesn't support creating a
durable subscription for advisories, which would help those scenarios.

It'd be handy to support Advisory notification as a plugin, so we could
build advisory-to-log plugin, advisory-over-topic plugin, advisory-to-XX
plugin, etc.

-Matt Pavlovich



On 12/20/16 2:08 PM, Clebert Suconic wrote:

Artemis already has the notification listener in place:


These are the notification currently supported:


https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/CoreNotificationType.java


There are a few more that still didn't merge the core model yet:

https://github.com/apache/activemq-artemis/blob/master/artemis-jms-server/src/main/java/org/apache/activemq/artemis/jms/server/management/JMSNotificationType.java


On Tue, Dec 20, 2016 at 2:43 PM, Christopher Shannon
 wrote:

A plugin API is actually one of the big things on my list as well.  In
5.x it is very easy to add extra functionality at certain points in
the chain (on a new connection, new consumer, etc) and I think having
some mechanism to do that in Artemis will be useful as well. I use a
combination of plugins that come out of the box with 5.x as well as
custom ones that are specific to my use case.

I opened up https://issues.apache.org/jira/browse/ARTEMIS-796 for
Advisory support and it might be a good candidate as a plugin as Matt
pointed out.

On Tue, Dec 20, 2016 at 11:54 AM, Clebert Suconic
 wrote:

The inbound would transform the message before it enters the broker.


Outbound would only apply to the current delivery.


It would be a nice feature.
On Tue, Dec 20, 2016 at 11:44 AM Matt Pavlovich 
wrote:


Clebert-



I think outbound/inbound separation would be really handy for plugin

writers. Are these statements correct based on what you are thinking w/

inbound and outbound?



1. The outboundTransformer() would transform messages for one or more

client consumer(s) and across protocols. ie.. one JMS consumer, one

STOMP consumer on the same address would receive the transformed copy
of

the message.



2. The outboundTransformer would _not_  transformation messages being

sent to other brokers (replication and/or pub+sub to brokers in a
cluster)



3. For the inboundTransformer.. the message would be transformed for
all

delivery into the broker for all consumers, brokers and diverts.



Thanks,

Matt



On 12/20/16 10:33 AM, Clebert Suconic wrote:


I think we should include two options on AddressSettings:
i - inboundTransformer
ii - maybe an outboundTransformer
inboundTransformer (String address, ServerSession session,
ServerMessage message);
outboundTransformer(String address, ServerSession session,
ServerMessage message);
The trick part here is that 

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Clebert Suconic]

Notification are also sent over topics... (they are actually sent over
Addresses, so it could be anything).

You're getting too hung on the implementation details.. why it has to
be this specific interface?

>From what I looked, the advisory API is a natural mirror of the
broker's implementation.. it fits well with AMQ5, while it will be
some work to be implemented in Artemis.

Feel free to prove me wrong.. but I would use the time into some more
compelling feature. While we battle over specific implementations...
you lose space for other servers that don't even care about the
broker's battle.

On Tue, Dec 20, 2016 at 4:14 PM, Matt Pavlovich  wrote:
> Clebert-
>
> That is a good start on the advisories. However, the real world use cases
> get complicated when there is mixed configuration based on destination
> names. Take the case when you need to haven different behavior for sets of
> destinations queue://Billing.> vs queue://Ordering.>.
>
> advisoryForConsumed, advisoryForDelivery, advisoryForFastProducers,
> advisoryForSlowConsumers, advisoryWhenFull
>
> Ref: http://activemq.apache.org/per-destination-policies.html
>
> Also, given that advisories are currently sent over topics, there are a
> number of use cases where you can almost never get the advisory (broker
> becomes master, etc) b/c of the race condition b/w the advisory and having
> to have an active topic subscriber. IIRC ActiveMQ doesn't support creating a
> durable subscription for advisories, which would help those scenarios.
>
> It'd be handy to support Advisory notification as a plugin, so we could
> build advisory-to-log plugin, advisory-over-topic plugin, advisory-to-XX
> plugin, etc.
>
> -Matt Pavlovich
>
>
>
> On 12/20/16 2:08 PM, Clebert Suconic wrote:
>>
>> Artemis already has the notification listener in place:
>>
>>
>> These are the notification currently supported:
>>
>>
>> https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/CoreNotificationType.java
>>
>>
>> There are a few more that still didn't merge the core model yet:
>>
>> https://github.com/apache/activemq-artemis/blob/master/artemis-jms-server/src/main/java/org/apache/activemq/artemis/jms/server/management/JMSNotificationType.java
>>
>>
>> On Tue, Dec 20, 2016 at 2:43 PM, Christopher Shannon
>>  wrote:
>>>
>>> A plugin API is actually one of the big things on my list as well.  In
>>> 5.x it is very easy to add extra functionality at certain points in
>>> the chain (on a new connection, new consumer, etc) and I think having
>>> some mechanism to do that in Artemis will be useful as well. I use a
>>> combination of plugins that come out of the box with 5.x as well as
>>> custom ones that are specific to my use case.
>>>
>>> I opened up https://issues.apache.org/jira/browse/ARTEMIS-796 for
>>> Advisory support and it might be a good candidate as a plugin as Matt
>>> pointed out.
>>>
>>> On Tue, Dec 20, 2016 at 11:54 AM, Clebert Suconic
>>>  wrote:

 The inbound would transform the message before it enters the broker.


 Outbound would only apply to the current delivery.


 It would be a nice feature.
 On Tue, Dec 20, 2016 at 11:44 AM Matt Pavlovich 
 wrote:

> Clebert-
>
>
>
> I think outbound/inbound separation would be really handy for plugin
>
> writers. Are these statements correct based on what you are thinking w/
>
> inbound and outbound?
>
>
>
> 1. The outboundTransformer() would transform messages for one or more
>
> client consumer(s) and across protocols. ie.. one JMS consumer, one
>
> STOMP consumer on the same address would receive the transformed copy
> of
>
> the message.
>
>
>
> 2. The outboundTransformer would _not_  transformation messages being
>
> sent to other brokers (replication and/or pub+sub to brokers in a
> cluster)
>
>
>
> 3. For the inboundTransformer.. the message would be transformed for
> all
>
> delivery into the broker for all consumers, brokers and diverts.
>
>
>
> Thanks,
>
> Matt
>
>
>
> On 12/20/16 10:33 AM, Clebert Suconic wrote:
>
>> I think we should include two options on AddressSettings:
>> i - inboundTransformer
>> ii - maybe an outboundTransformer
>> inboundTransformer (String address, ServerSession session,
>> ServerMessage message);
>> outboundTransformer(String address, ServerSession session,
>> ServerMessage message);
>> The trick part here is that outboundTransformer would need to work on
>> a copy of the message. so, the API needs to return a copy of the
>> message.
>> I am working now on refactoring encoding and transformer between
>> protocols that would make this a bit 

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Matt Pavlovich]

Clebert-

That is a good start on the advisories. However, the real world use 
cases get complicated when there is mixed configuration based on 
destination names. Take the case when you need to haven different 
behavior for sets of destinations queue://Billing.> vs queue://Ordering.>.


advisoryForConsumed, advisoryForDelivery, advisoryForFastProducers, 
advisoryForSlowConsumers, advisoryWhenFull


Ref: http://activemq.apache.org/per-destination-policies.html

Also, given that advisories are currently sent over topics, there are a 
number of use cases where you can almost never get the advisory (broker 
becomes master, etc) b/c of the race condition b/w the advisory and 
having to have an active topic subscriber. IIRC ActiveMQ doesn't support 
creating a durable subscription for advisories, which would help those 
scenarios.


It'd be handy to support Advisory notification as a plugin, so we could 
build advisory-to-log plugin, advisory-over-topic plugin, advisory-to-XX 
plugin, etc.


-Matt Pavlovich


On 12/20/16 2:08 PM, Clebert Suconic wrote:

Artemis already has the notification listener in place:


These are the notification currently supported:

https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/CoreNotificationType.java


There are a few more that still didn't merge the core model yet:
https://github.com/apache/activemq-artemis/blob/master/artemis-jms-server/src/main/java/org/apache/activemq/artemis/jms/server/management/JMSNotificationType.java


On Tue, Dec 20, 2016 at 2:43 PM, Christopher Shannon
 wrote:

A plugin API is actually one of the big things on my list as well.  In
5.x it is very easy to add extra functionality at certain points in
the chain (on a new connection, new consumer, etc) and I think having
some mechanism to do that in Artemis will be useful as well. I use a
combination of plugins that come out of the box with 5.x as well as
custom ones that are specific to my use case.

I opened up https://issues.apache.org/jira/browse/ARTEMIS-796 for
Advisory support and it might be a good candidate as a plugin as Matt
pointed out.

On Tue, Dec 20, 2016 at 11:54 AM, Clebert Suconic
 wrote:

The inbound would transform the message before it enters the broker.


Outbound would only apply to the current delivery.


It would be a nice feature.
On Tue, Dec 20, 2016 at 11:44 AM Matt Pavlovich  wrote:


Clebert-



I think outbound/inbound separation would be really handy for plugin

writers. Are these statements correct based on what you are thinking w/

inbound and outbound?



1. The outboundTransformer() would transform messages for one or more

client consumer(s) and across protocols. ie.. one JMS consumer, one

STOMP consumer on the same address would receive the transformed copy of

the message.



2. The outboundTransformer would _not_  transformation messages being

sent to other brokers (replication and/or pub+sub to brokers in a cluster)



3. For the inboundTransformer.. the message would be transformed for all

delivery into the broker for all consumers, brokers and diverts.



Thanks,

Matt



On 12/20/16 10:33 AM, Clebert Suconic wrote:


I think we should include two options on AddressSettings:
i - inboundTransformer
ii - maybe an outboundTransformer
inboundTransformer (String address, ServerSession session,
ServerMessage message);
outboundTransformer(String address, ServerSession session,
ServerMessage message);
The trick part here is that outboundTransformer would need to work on
a copy of the message. so, the API needs to return a copy of the
message.
I am working now on refactoring encoding and transformer between
protocols that would make this a bit easier. I'm at the design phase
and I will post a DISCUSS thread about that when I have something more
concrete to talk about it.
On Tue, Dec 20, 2016 at 11:22 AM, Matt Pavlovich 

wrote:


I was taking a first step in implementing an existing ActiveMQ 5.x

plugin in


the Artemis source and noticed that there is a gap in the availability

of


extension points in Artemis (or plugins).
I opened ARTEMIS-898 for tracking, and thought it deserved a discussion.
This feels like a good target as a 2.x feature, since it would most

likely


be API changing. It stands to reason the extension points in Artemis

would


be very different than ActiveMQ 5.x, so I've laid it out in terms of
features and capabilities.
The big three:
1. Message header / property manipulation. Allows admins to set message
policies for things like JMSXUserId, Timestamps, Expiry, etc
2. Message body manipulation. (Clebert mentioned perhaps an extension of
Divert / Transformers?)
3. Activity tracing for audit tracing and/or triggering other activity
(extension point at PostOffice and ActiveMQServer ?)
One side benefit might be that Advisory support becomes a plugin vs an
ingrained 

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Matt Pavlovich]

+1 Having the Advisory Notification as a plugin would allow a way for 
admins to configure behavior, or completely do a full re-implementation 
as needed.


From a functional perspective perhaps it would help to split the use cases:

1. Message handling plugin(s)  (recv message / send message, manipulate 
headers-- timestamp, expiry, etc)


2. Broker object life cycle (queue created, consumer added, broker added 
to cluster, broker-becomes-master, etc)

--> Advisory plugin could live here

3. Destination Policies Behaviors (subscription retention policies, 
etc.. last message, last # messages, last messages for X period of 
time). Destination Garbage Collection


Would these need to be separate extension points In Artemis?

On 12/20/16 1:43 PM, Christopher Shannon wrote:

A plugin API is actually one of the big things on my list as well.  In
5.x it is very easy to add extra functionality at certain points in
the chain (on a new connection, new consumer, etc) and I think having
some mechanism to do that in Artemis will be useful as well. I use a
combination of plugins that come out of the box with 5.x as well as
custom ones that are specific to my use case.

I opened up https://issues.apache.org/jira/browse/ARTEMIS-796 for
Advisory support and it might be a good candidate as a plugin as Matt
pointed out.

On Tue, Dec 20, 2016 at 11:54 AM, Clebert Suconic
 wrote:

The inbound would transform the message before it enters the broker.


Outbound would only apply to the current delivery.


It would be a nice feature.
On Tue, Dec 20, 2016 at 11:44 AM Matt Pavlovich  wrote:


Clebert-



I think outbound/inbound separation would be really handy for plugin

writers. Are these statements correct based on what you are thinking w/

inbound and outbound?



1. The outboundTransformer() would transform messages for one or more

client consumer(s) and across protocols. ie.. one JMS consumer, one

STOMP consumer on the same address would receive the transformed copy of

the message.



2. The outboundTransformer would _not_  transformation messages being

sent to other brokers (replication and/or pub+sub to brokers in a cluster)



3. For the inboundTransformer.. the message would be transformed for all

delivery into the broker for all consumers, brokers and diverts.



Thanks,

Matt



On 12/20/16 10:33 AM, Clebert Suconic wrote:


I think we should include two options on AddressSettings:
i - inboundTransformer
ii - maybe an outboundTransformer
inboundTransformer (String address, ServerSession session,
ServerMessage message);
outboundTransformer(String address, ServerSession session,
ServerMessage message);
The trick part here is that outboundTransformer would need to work on
a copy of the message. so, the API needs to return a copy of the
message.
I am working now on refactoring encoding and transformer between
protocols that would make this a bit easier. I'm at the design phase
and I will post a DISCUSS thread about that when I have something more
concrete to talk about it.
On Tue, Dec 20, 2016 at 11:22 AM, Matt Pavlovich 

wrote:


I was taking a first step in implementing an existing ActiveMQ 5.x

plugin in


the Artemis source and noticed that there is a gap in the availability

of


extension points in Artemis (or plugins).
I opened ARTEMIS-898 for tracking, and thought it deserved a discussion.
This feels like a good target as a 2.x feature, since it would most

likely


be API changing. It stands to reason the extension points in Artemis

would


be very different than ActiveMQ 5.x, so I've laid it out in terms of
features and capabilities.
The big three:
1. Message header / property manipulation. Allows admins to set message
policies for things like JMSXUserId, Timestamps, Expiry, etc
2. Message body manipulation. (Clebert mentioned perhaps an extension of
Divert / Transformers?)
3. Activity tracing for audit tracing and/or triggering other activity
(extension point at PostOffice and ActiveMQServer ?)
One side benefit might be that Advisory support becomes a plugin vs an
ingrained feature. Could be handy to have all the advisory logic in one
place to allow more customization of behavior.
Thoughts?
-Matt Pavlovich

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Clebert Suconic]

IMHO We should look at the usecase instead of the implementation.
Instead of bringing Advisory Support, look what you can't do with the
current notification and expand from there.


Copying functionality from activemq just by itself might be an
unsolvable battle. It's a different codebase and it might not fit the
code between the two.  But supporting the usecases is totally doable.

usecase is: like providing knowledge when a certain event happened, or
how to intercept messages at the broker level.

Implementation would be: support the exact same API as the Advisory
Support... it might be a forever battle.


I'm not talking about any specific point here.. just pointing this for
general cases.


On Tue, Dec 20, 2016 at 3:08 PM, Clebert Suconic
 wrote:
> Artemis already has the notification listener in place:
>
>
> These are the notification currently supported:
>
> https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/CoreNotificationType.java
>
>
> There are a few more that still didn't merge the core model yet:
> https://github.com/apache/activemq-artemis/blob/master/artemis-jms-server/src/main/java/org/apache/activemq/artemis/jms/server/management/JMSNotificationType.java
>
>
> On Tue, Dec 20, 2016 at 2:43 PM, Christopher Shannon
>  wrote:
>> A plugin API is actually one of the big things on my list as well.  In
>> 5.x it is very easy to add extra functionality at certain points in
>> the chain (on a new connection, new consumer, etc) and I think having
>> some mechanism to do that in Artemis will be useful as well. I use a
>> combination of plugins that come out of the box with 5.x as well as
>> custom ones that are specific to my use case.
>>
>> I opened up https://issues.apache.org/jira/browse/ARTEMIS-796 for
>> Advisory support and it might be a good candidate as a plugin as Matt
>> pointed out.
>>
>> On Tue, Dec 20, 2016 at 11:54 AM, Clebert Suconic
>>  wrote:
>>> The inbound would transform the message before it enters the broker.
>>>
>>>
>>> Outbound would only apply to the current delivery.
>>>
>>>
>>> It would be a nice feature.
>>> On Tue, Dec 20, 2016 at 11:44 AM Matt Pavlovich  wrote:
>>>
 Clebert-



 I think outbound/inbound separation would be really handy for plugin

 writers. Are these statements correct based on what you are thinking w/

 inbound and outbound?



 1. The outboundTransformer() would transform messages for one or more

 client consumer(s) and across protocols. ie.. one JMS consumer, one

 STOMP consumer on the same address would receive the transformed copy of

 the message.



 2. The outboundTransformer would _not_  transformation messages being

 sent to other brokers (replication and/or pub+sub to brokers in a cluster)



 3. For the inboundTransformer.. the message would be transformed for all

 delivery into the broker for all consumers, brokers and diverts.



 Thanks,

 Matt



 On 12/20/16 10:33 AM, Clebert Suconic wrote:

 > I think we should include two options on AddressSettings:

 >

 > i - inboundTransformer

 > ii - maybe an outboundTransformer

 >

 > inboundTransformer (String address, ServerSession session,

 > ServerMessage message);

 > outboundTransformer(String address, ServerSession session,

 > ServerMessage message);

 >

 >

 > The trick part here is that outboundTransformer would need to work on

 > a copy of the message. so, the API needs to return a copy of the

 > message.

 >

 >

 >

 > I am working now on refactoring encoding and transformer between

 > protocols that would make this a bit easier. I'm at the design phase

 > and I will post a DISCUSS thread about that when I have something more

 > concrete to talk about it.

 >

 >

 >

 >

 > On Tue, Dec 20, 2016 at 11:22 AM, Matt Pavlovich 
 wrote:

 >> I was taking a first step in implementing an existing ActiveMQ 5.x
 plugin in

 >> the Artemis source and noticed that there is a gap in the availability
 of

 >> extension points in Artemis (or plugins).

 >>

 >> I opened ARTEMIS-898 for tracking, and thought it deserved a discussion.

 >> This feels like a good target as a 2.x feature, since it would most
 likely

 >> be API changing. It stands to reason the extension points in Artemis
 would

 >> be very different than ActiveMQ 5.x, so I've laid it out in terms of

 >> features and capabilities.

 >>

 >> 

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Clebert Suconic]

Artemis already has the notification listener in place:


These are the notification currently supported:

https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/CoreNotificationType.java


There are a few more that still didn't merge the core model yet:
https://github.com/apache/activemq-artemis/blob/master/artemis-jms-server/src/main/java/org/apache/activemq/artemis/jms/server/management/JMSNotificationType.java


On Tue, Dec 20, 2016 at 2:43 PM, Christopher Shannon
 wrote:
> A plugin API is actually one of the big things on my list as well.  In
> 5.x it is very easy to add extra functionality at certain points in
> the chain (on a new connection, new consumer, etc) and I think having
> some mechanism to do that in Artemis will be useful as well. I use a
> combination of plugins that come out of the box with 5.x as well as
> custom ones that are specific to my use case.
>
> I opened up https://issues.apache.org/jira/browse/ARTEMIS-796 for
> Advisory support and it might be a good candidate as a plugin as Matt
> pointed out.
>
> On Tue, Dec 20, 2016 at 11:54 AM, Clebert Suconic
>  wrote:
>> The inbound would transform the message before it enters the broker.
>>
>>
>> Outbound would only apply to the current delivery.
>>
>>
>> It would be a nice feature.
>> On Tue, Dec 20, 2016 at 11:44 AM Matt Pavlovich  wrote:
>>
>>> Clebert-
>>>
>>>
>>>
>>> I think outbound/inbound separation would be really handy for plugin
>>>
>>> writers. Are these statements correct based on what you are thinking w/
>>>
>>> inbound and outbound?
>>>
>>>
>>>
>>> 1. The outboundTransformer() would transform messages for one or more
>>>
>>> client consumer(s) and across protocols. ie.. one JMS consumer, one
>>>
>>> STOMP consumer on the same address would receive the transformed copy of
>>>
>>> the message.
>>>
>>>
>>>
>>> 2. The outboundTransformer would _not_  transformation messages being
>>>
>>> sent to other brokers (replication and/or pub+sub to brokers in a cluster)
>>>
>>>
>>>
>>> 3. For the inboundTransformer.. the message would be transformed for all
>>>
>>> delivery into the broker for all consumers, brokers and diverts.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>>
>>>
>>> On 12/20/16 10:33 AM, Clebert Suconic wrote:
>>>
>>> > I think we should include two options on AddressSettings:
>>>
>>> >
>>>
>>> > i - inboundTransformer
>>>
>>> > ii - maybe an outboundTransformer
>>>
>>> >
>>>
>>> > inboundTransformer (String address, ServerSession session,
>>>
>>> > ServerMessage message);
>>>
>>> > outboundTransformer(String address, ServerSession session,
>>>
>>> > ServerMessage message);
>>>
>>> >
>>>
>>> >
>>>
>>> > The trick part here is that outboundTransformer would need to work on
>>>
>>> > a copy of the message. so, the API needs to return a copy of the
>>>
>>> > message.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I am working now on refactoring encoding and transformer between
>>>
>>> > protocols that would make this a bit easier. I'm at the design phase
>>>
>>> > and I will post a DISCUSS thread about that when I have something more
>>>
>>> > concrete to talk about it.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > On Tue, Dec 20, 2016 at 11:22 AM, Matt Pavlovich 
>>> wrote:
>>>
>>> >> I was taking a first step in implementing an existing ActiveMQ 5.x
>>> plugin in
>>>
>>> >> the Artemis source and noticed that there is a gap in the availability
>>> of
>>>
>>> >> extension points in Artemis (or plugins).
>>>
>>> >>
>>>
>>> >> I opened ARTEMIS-898 for tracking, and thought it deserved a discussion.
>>>
>>> >> This feels like a good target as a 2.x feature, since it would most
>>> likely
>>>
>>> >> be API changing. It stands to reason the extension points in Artemis
>>> would
>>>
>>> >> be very different than ActiveMQ 5.x, so I've laid it out in terms of
>>>
>>> >> features and capabilities.
>>>
>>> >>
>>>
>>> >> The big three:
>>>
>>> >>
>>>
>>> >> 1. Message header / property manipulation. Allows admins to set message
>>>
>>> >> policies for things like JMSXUserId, Timestamps, Expiry, etc
>>>
>>> >>
>>>
>>> >> 2. Message body manipulation. (Clebert mentioned perhaps an extension of
>>>
>>> >> Divert / Transformers?)
>>>
>>> >>
>>>
>>> >> 3. Activity tracing for audit tracing and/or triggering other activity
>>>
>>> >> (extension point at PostOffice and ActiveMQServer ?)
>>>
>>> >>
>>>
>>> >> One side benefit might be that Advisory support becomes a plugin vs an
>>>
>>> >> ingrained feature. Could be handy to have all the advisory logic in one
>>>
>>> >> place to allow more customization of behavior.
>>>
>>> >>
>>>
>>> >> Thoughts?
>>>
>>> >>
>>>
>>> >> -Matt Pavlovich
>>>
>>> >>
>>>
>>> >>
>>>
>>> >
>>>
>>> >
>>>
>>>
>>>
>>>



-- 
Clebert Suconic

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Christopher Shannon]

A plugin API is actually one of the big things on my list as well.  In
5.x it is very easy to add extra functionality at certain points in
the chain (on a new connection, new consumer, etc) and I think having
some mechanism to do that in Artemis will be useful as well. I use a
combination of plugins that come out of the box with 5.x as well as
custom ones that are specific to my use case.

I opened up https://issues.apache.org/jira/browse/ARTEMIS-796 for
Advisory support and it might be a good candidate as a plugin as Matt
pointed out.

On Tue, Dec 20, 2016 at 11:54 AM, Clebert Suconic
 wrote:
> The inbound would transform the message before it enters the broker.
>
>
> Outbound would only apply to the current delivery.
>
>
> It would be a nice feature.
> On Tue, Dec 20, 2016 at 11:44 AM Matt Pavlovich  wrote:
>
>> Clebert-
>>
>>
>>
>> I think outbound/inbound separation would be really handy for plugin
>>
>> writers. Are these statements correct based on what you are thinking w/
>>
>> inbound and outbound?
>>
>>
>>
>> 1. The outboundTransformer() would transform messages for one or more
>>
>> client consumer(s) and across protocols. ie.. one JMS consumer, one
>>
>> STOMP consumer on the same address would receive the transformed copy of
>>
>> the message.
>>
>>
>>
>> 2. The outboundTransformer would _not_  transformation messages being
>>
>> sent to other brokers (replication and/or pub+sub to brokers in a cluster)
>>
>>
>>
>> 3. For the inboundTransformer.. the message would be transformed for all
>>
>> delivery into the broker for all consumers, brokers and diverts.
>>
>>
>>
>> Thanks,
>>
>> Matt
>>
>>
>>
>> On 12/20/16 10:33 AM, Clebert Suconic wrote:
>>
>> > I think we should include two options on AddressSettings:
>>
>> >
>>
>> > i - inboundTransformer
>>
>> > ii - maybe an outboundTransformer
>>
>> >
>>
>> > inboundTransformer (String address, ServerSession session,
>>
>> > ServerMessage message);
>>
>> > outboundTransformer(String address, ServerSession session,
>>
>> > ServerMessage message);
>>
>> >
>>
>> >
>>
>> > The trick part here is that outboundTransformer would need to work on
>>
>> > a copy of the message. so, the API needs to return a copy of the
>>
>> > message.
>>
>> >
>>
>> >
>>
>> >
>>
>> > I am working now on refactoring encoding and transformer between
>>
>> > protocols that would make this a bit easier. I'm at the design phase
>>
>> > and I will post a DISCUSS thread about that when I have something more
>>
>> > concrete to talk about it.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > On Tue, Dec 20, 2016 at 11:22 AM, Matt Pavlovich 
>> wrote:
>>
>> >> I was taking a first step in implementing an existing ActiveMQ 5.x
>> plugin in
>>
>> >> the Artemis source and noticed that there is a gap in the availability
>> of
>>
>> >> extension points in Artemis (or plugins).
>>
>> >>
>>
>> >> I opened ARTEMIS-898 for tracking, and thought it deserved a discussion.
>>
>> >> This feels like a good target as a 2.x feature, since it would most
>> likely
>>
>> >> be API changing. It stands to reason the extension points in Artemis
>> would
>>
>> >> be very different than ActiveMQ 5.x, so I've laid it out in terms of
>>
>> >> features and capabilities.
>>
>> >>
>>
>> >> The big three:
>>
>> >>
>>
>> >> 1. Message header / property manipulation. Allows admins to set message
>>
>> >> policies for things like JMSXUserId, Timestamps, Expiry, etc
>>
>> >>
>>
>> >> 2. Message body manipulation. (Clebert mentioned perhaps an extension of
>>
>> >> Divert / Transformers?)
>>
>> >>
>>
>> >> 3. Activity tracing for audit tracing and/or triggering other activity
>>
>> >> (extension point at PostOffice and ActiveMQServer ?)
>>
>> >>
>>
>> >> One side benefit might be that Advisory support becomes a plugin vs an
>>
>> >> ingrained feature. Could be handy to have all the advisory logic in one
>>
>> >> place to allow more customization of behavior.
>>
>> >>
>>
>> >> Thoughts?
>>
>> >>
>>
>> >> -Matt Pavlovich
>>
>> >>
>>
>> >>
>>
>> >
>>
>> >
>>
>>
>>
>>

Re: [VOTE] Apache ActiveMQ 5.14.3

[Claus Ibsen]

+1

Tested with latest Apache Camel code

On Mon, Dec 19, 2016 at 4:49 PM, Christopher Shannon
 wrote:
> Hi Everyone,
>
> I have created the ActiveMQ 5.14.3 release and it's ready for a vote.
> This release contains 7 important fixes that didn't make it into the
> last release.
>
> The list of resolved issues is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12338822
>
> You can get binary distributions here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1113/org/apache/activemq/apache-activemq/5.14.3/
>
> Source archives are here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1113/org/apache/activemq/activemq-parent/5.14.3/
>
> Maven repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1113/
>
> Source tag: 
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=58dddb9181912bee60fec480d90e05be4ca3a044
>
> Please vote to approve this release.  The vote will remain open for 72 hours.
>
> [ ] +1 Release the binary as Apache ActiveMQ 5.14.3
> [ ] -1 (provide specific comments)
>
> Here's my +1



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Clebert Suconic]

The inbound would transform the message before it enters the broker.


Outbound would only apply to the current delivery.


It would be a nice feature.
On Tue, Dec 20, 2016 at 11:44 AM Matt Pavlovich  wrote:

> Clebert-
>
>
>
> I think outbound/inbound separation would be really handy for plugin
>
> writers. Are these statements correct based on what you are thinking w/
>
> inbound and outbound?
>
>
>
> 1. The outboundTransformer() would transform messages for one or more
>
> client consumer(s) and across protocols. ie.. one JMS consumer, one
>
> STOMP consumer on the same address would receive the transformed copy of
>
> the message.
>
>
>
> 2. The outboundTransformer would _not_  transformation messages being
>
> sent to other brokers (replication and/or pub+sub to brokers in a cluster)
>
>
>
> 3. For the inboundTransformer.. the message would be transformed for all
>
> delivery into the broker for all consumers, brokers and diverts.
>
>
>
> Thanks,
>
> Matt
>
>
>
> On 12/20/16 10:33 AM, Clebert Suconic wrote:
>
> > I think we should include two options on AddressSettings:
>
> >
>
> > i - inboundTransformer
>
> > ii - maybe an outboundTransformer
>
> >
>
> > inboundTransformer (String address, ServerSession session,
>
> > ServerMessage message);
>
> > outboundTransformer(String address, ServerSession session,
>
> > ServerMessage message);
>
> >
>
> >
>
> > The trick part here is that outboundTransformer would need to work on
>
> > a copy of the message. so, the API needs to return a copy of the
>
> > message.
>
> >
>
> >
>
> >
>
> > I am working now on refactoring encoding and transformer between
>
> > protocols that would make this a bit easier. I'm at the design phase
>
> > and I will post a DISCUSS thread about that when I have something more
>
> > concrete to talk about it.
>
> >
>
> >
>
> >
>
> >
>
> > On Tue, Dec 20, 2016 at 11:22 AM, Matt Pavlovich 
> wrote:
>
> >> I was taking a first step in implementing an existing ActiveMQ 5.x
> plugin in
>
> >> the Artemis source and noticed that there is a gap in the availability
> of
>
> >> extension points in Artemis (or plugins).
>
> >>
>
> >> I opened ARTEMIS-898 for tracking, and thought it deserved a discussion.
>
> >> This feels like a good target as a 2.x feature, since it would most
> likely
>
> >> be API changing. It stands to reason the extension points in Artemis
> would
>
> >> be very different than ActiveMQ 5.x, so I've laid it out in terms of
>
> >> features and capabilities.
>
> >>
>
> >> The big three:
>
> >>
>
> >> 1. Message header / property manipulation. Allows admins to set message
>
> >> policies for things like JMSXUserId, Timestamps, Expiry, etc
>
> >>
>
> >> 2. Message body manipulation. (Clebert mentioned perhaps an extension of
>
> >> Divert / Transformers?)
>
> >>
>
> >> 3. Activity tracing for audit tracing and/or triggering other activity
>
> >> (extension point at PostOffice and ActiveMQServer ?)
>
> >>
>
> >> One side benefit might be that Advisory support becomes a plugin vs an
>
> >> ingrained feature. Could be handy to have all the advisory logic in one
>
> >> place to allow more customization of behavior.
>
> >>
>
> >> Thoughts?
>
> >>
>
> >> -Matt Pavlovich
>
> >>
>
> >>
>
> >
>
> >
>
>
>
>

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Matt Pavlovich]

Clebert-

I think outbound/inbound separation would be really handy for plugin 
writers. Are these statements correct based on what you are thinking w/ 
inbound and outbound?


1. The outboundTransformer() would transform messages for one or more 
client consumer(s) and across protocols. ie.. one JMS consumer, one 
STOMP consumer on the same address would receive the transformed copy of 
the message.


2. The outboundTransformer would _not_  transformation messages being 
sent to other brokers (replication and/or pub+sub to brokers in a cluster)


3. For the inboundTransformer.. the message would be transformed for all 
delivery into the broker for all consumers, brokers and diverts.


Thanks,
Matt

On 12/20/16 10:33 AM, Clebert Suconic wrote:

I think we should include two options on AddressSettings:

i - inboundTransformer
ii - maybe an outboundTransformer

inboundTransformer (String address, ServerSession session,
ServerMessage message);
outboundTransformer(String address, ServerSession session,
ServerMessage message);


The trick part here is that outboundTransformer would need to work on
a copy of the message. so, the API needs to return a copy of the
message.



I am working now on refactoring encoding and transformer between
protocols that would make this a bit easier. I'm at the design phase
and I will post a DISCUSS thread about that when I have something more
concrete to talk about it.




On Tue, Dec 20, 2016 at 11:22 AM, Matt Pavlovich  wrote:

I was taking a first step in implementing an existing ActiveMQ 5.x plugin in
the Artemis source and noticed that there is a gap in the availability of
extension points in Artemis (or plugins).

I opened ARTEMIS-898 for tracking, and thought it deserved a discussion.
This feels like a good target as a 2.x feature, since it would most likely
be API changing. It stands to reason the extension points in Artemis would
be very different than ActiveMQ 5.x, so I've laid it out in terms of
features and capabilities.

The big three:

1. Message header / property manipulation. Allows admins to set message
policies for things like JMSXUserId, Timestamps, Expiry, etc

2. Message body manipulation. (Clebert mentioned perhaps an extension of
Divert / Transformers?)

3. Activity tracing for audit tracing and/or triggering other activity
(extension point at PostOffice and ActiveMQServer ?)

One side benefit might be that Advisory support becomes a plugin vs an
ingrained feature. Could be handy to have all the advisory logic in one
place to allow more customization of behavior.

Thoughts?

-Matt Pavlovich

Re: [DISCUSS] Artemis plugins ARTEMIS-898

[Clebert Suconic]

I think we should include two options on AddressSettings:

i - inboundTransformer
ii - maybe an outboundTransformer

inboundTransformer (String address, ServerSession session,
ServerMessage message);
outboundTransformer(String address, ServerSession session,
ServerMessage message);


The trick part here is that outboundTransformer would need to work on
a copy of the message. so, the API needs to return a copy of the
message.



I am working now on refactoring encoding and transformer between
protocols that would make this a bit easier. I'm at the design phase
and I will post a DISCUSS thread about that when I have something more
concrete to talk about it.




On Tue, Dec 20, 2016 at 11:22 AM, Matt Pavlovich  wrote:
> I was taking a first step in implementing an existing ActiveMQ 5.x plugin in
> the Artemis source and noticed that there is a gap in the availability of
> extension points in Artemis (or plugins).
>
> I opened ARTEMIS-898 for tracking, and thought it deserved a discussion.
> This feels like a good target as a 2.x feature, since it would most likely
> be API changing. It stands to reason the extension points in Artemis would
> be very different than ActiveMQ 5.x, so I've laid it out in terms of
> features and capabilities.
>
> The big three:
>
> 1. Message header / property manipulation. Allows admins to set message
> policies for things like JMSXUserId, Timestamps, Expiry, etc
>
> 2. Message body manipulation. (Clebert mentioned perhaps an extension of
> Divert / Transformers?)
>
> 3. Activity tracing for audit tracing and/or triggering other activity
> (extension point at PostOffice and ActiveMQServer ?)
>
> One side benefit might be that Advisory support becomes a plugin vs an
> ingrained feature. Could be handy to have all the advisory logic in one
> place to allow more customization of behavior.
>
> Thoughts?
>
> -Matt Pavlovich
>
>



-- 
Clebert Suconic

[DISCUSS] Artemis plugins ARTEMIS-898

[Matt Pavlovich]

I was taking a first step in implementing an existing ActiveMQ 5.x 
plugin in the Artemis source and noticed that there is a gap in the 
availability of extension points in Artemis (or plugins).


I opened ARTEMIS-898 for tracking, and thought it deserved a discussion. 
This feels like a good target as a 2.x feature, since it would most 
likely be API changing. It stands to reason the extension points in 
Artemis would be very different than ActiveMQ 5.x, so I've laid it out 
in terms of features and capabilities.


The big three:

1. Message header / property manipulation. Allows admins to set message 
policies for things like JMSXUserId, Timestamps, Expiry, etc


2. Message body manipulation. (Clebert mentioned perhaps an extension of 
Divert / Transformers?)


3. Activity tracing for audit tracing and/or triggering other activity 
(extension point at PostOffice and ActiveMQServer ?)


One side benefit might be that Advisory support becomes a plugin vs an 
ingrained feature. Could be handy to have all the advisory logic in one 
place to allow more customization of behavior.


Thoughts?

-Matt Pavlovich

Re: [VOTE] Apache ActiveMQ 5.14.3

[Jim Gomes]

+1

On Tue, Dec 20, 2016, 4:24 AM Daniel Kulp  wrote:

> +1
>
> Dan
>
>
> > On Dec 19, 2016, at 10:49 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
> >
> > Hi Everyone,
> >
> > I have created the ActiveMQ 5.14.3 release and it's ready for a vote.
> > This release contains 7 important fixes that didn't make it into the
> > last release.
> >
> > The list of resolved issues is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12338822
> >
> > You can get binary distributions here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1113/org/apache/activemq/apache-activemq/5.14.3/
> >
> > Source archives are here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1113/org/apache/activemq/activemq-parent/5.14.3/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1113/
> >
> > Source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=58dddb9181912bee60fec480d90e05be4ca3a044
> >
> > Please vote to approve this release.  The vote will remain open for 72
> hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.14.3
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: ActiveMQ Upgrade

[Clebert Suconic]

Did you copy your data and settings from the ActiveMQ 5.9 to 5.14...


This is a subject that we are improving with ActiveMQ Artemis. Bennet
Schultz wrote a blog post about this:

https://dzone.com/articles/how-to-update-apache-activemq-artemis-1?utm_medium=feed_source=feedpress.me_campaign=Feed:%20dzone%2Fjava

On Tue, Dec 20, 2016 at 4:07 AM, Gulwinder  wrote:
> Hi Team,
>
> I am upgrading ActiveMQ from 5.9 to 5.14 on our Windows server. I am
> following below procedures, please correct me if I am wrong.
>
> 1) Run Uninstallservice.bat to remove old service.
> 2) Run InstallService.bat for new file.
> 3) Change the new jar file in my connector.
>
> The issue I am facing is, when I upgrade to new version, all the queue names
> gets deleted. Is there a possibility where we can retain queue names? Please
> help.
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/ActiveMQ-Upgrade-tp4720622.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



-- 
Clebert Suconic

[GitHub] activemq-artemis pull request #937: ARTEMIS-896 remove 32 bits library

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

ActiveMQ Upgrade

[Gulwinder]

Hi Team,

I am upgrading ActiveMQ from 5.9 to 5.14 on our Windows server. I am
following below procedures, please correct me if I am wrong.

1) Run Uninstallservice.bat to remove old service.
2) Run InstallService.bat for new file.
3) Change the new jar file in my connector.

The issue I am facing is, when I upgrade to new version, all the queue names
gets deleted. Is there a possibility where we can retain queue names? Please
help.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-Upgrade-tp4720622.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] distribute binary in .deb and .rpm

[Clebert Suconic]

I have asked the apache infra how we could make rpm and .deb releases
(As Robbie pointed out).

I don't really mind which way we choose. as long it's easier to maintain.


It sounds the standard way would be the second option as you suggest.
why don't you start with that? keep the scripts on a directory such
artemis-linux-distros.. and I will wait input from infra on how to
release and sign those.. we can then make more changes.

On Mon, Dec 19, 2016 at 8:08 PM, Fabio Gomes dos Santos
 wrote:
> About the packaging method...
>
> If the second way are chosen, i can contribute with the project. Putting
> the hands-on...
> For the first, all i can do, is write the test for the binary and help with
> the patterns.
>
> if we want to see Artemis officially on debian or centos, the second one is
> the best choose.
>
>
>
> 2016-12-12 18:04 GMT-02:00 Robbie Gemmell :
>
>> I know the infra team and some projects have some hosting on bintray
>> (https://bintray.com/apache/), and that can host .deb and .rpm.
>> Whether its used by projects to do that, and what any process around
>> that would be if they do, I'm not sure. Perhaps worth asking infra.
>>
>> On 12 December 2016 at 17:03, Clebert Suconic 
>> wrote:
>> > I couldn't find any information about rpms on apache.org
>> >
>> > Anyone have any information?
>> >
>> > On Thu, Dec 8, 2016 at 8:43 AM, Clebert Suconic
>> >  wrote:
>> >> Having a rpm and .deb is a great idea.
>> >>
>> >>
>> >> Anyone knows how the release and distribution process would work for
>> those
>> >> including signing?
>> >>
>> >>
>> >> I will do some research on Apache website later today.
>> >>
>> >>
>> >>
>> >> On Thu, Dec 8, 2016 at 7:16 AM Fabio Gomes dos Santos <
>> supergr...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi!
>> >>>
>> >>>
>> >>>
>> >>> We have two ways to do that:
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> 1 - Using a plugin on maven:
>> >>>
>> >>>
>> >>>
>> >>> http://www.mojohaus.org/rpm-maven-plugin/
>> >>>
>> >>> http://mojo.codehaus.org/deb-maven-plugin
>> >>>
>> >>>
>> >>>
>> >>> 2 - Using the default way of each distribution (using .spec)
>> >>>
>> >>>
>> >>>
>> >>> Fedora/RHEL: https://fedora-java.github.io/howto/latest/
>> >>>
>> >>> Debian: https://wiki.debian.org/Java/Packaging
>> >>>
>> >>>
>> >>>
>> >>> The packagecloud.io has plans to opensource project, but a simple s3
>> can
>> >>>
>> >>> provide a mirror for distribution.
>> >>>
>> >>>
>> >>>
>> >>> what you think  about?
>> >>>
>> >>> I think this will provide more visibility to the project
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Fábio Santos
>> >>>
>> >>> supergr...@gmail.com
>> >>>
>> >>> 
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Clebert Suconic
>>
>
>
>
> --
> Fábio Santos
> supergr...@gmail.com
> 



-- 
Clebert Suconic

[GitHub] activemq-artemis pull request #938: ARTEMIS-888 - default to false if header...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE] Apache ActiveMQ 5.14.3

[Daniel Kulp]

+1

Dan


> On Dec 19, 2016, at 10:49 AM, Christopher Shannon 
>  wrote:
> 
> Hi Everyone,
> 
> I have created the ActiveMQ 5.14.3 release and it's ready for a vote.
> This release contains 7 important fixes that didn't make it into the
> last release.
> 
> The list of resolved issues is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12338822
> 
> You can get binary distributions here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1113/org/apache/activemq/apache-activemq/5.14.3/
> 
> Source archives are here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1113/org/apache/activemq/activemq-parent/5.14.3/
> 
> Maven repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1113/
> 
> Source tag: 
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=58dddb9181912bee60fec480d90e05be4ca3a044
> 
> Please vote to approve this release.  The vote will remain open for 72 hours.
> 
> [ ] +1 Release the binary as Apache ActiveMQ 5.14.3
> [ ] -1 (provide specific comments)
> 
> Here's my +1

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

[GitHub] activemq-artemis issue #938: ARTEMIS-888 - default to false if header durabl...

[andytaylor]

Github user andytaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/938
  
These failures look unrelated


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #938: ARTEMIS-888 - default to false if header...

[andytaylor]

GitHub user andytaylor opened a pull request:

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

ARTEMIS-888 - default to false if header durable not set

https://issues.apache.org/jira/browse/ARTEMIS-888

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

$ git pull https://github.com/andytaylor/activemq-artemis master

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

https://github.com/apache/activemq-artemis/pull/938.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #938


commit 63f723fe8d341be47fc03c1f16abd62f7e30ec91
Author: Andy Taylor 
Date:   2016-12-20T09:32:33Z

ARTEMIS-888 - default to false if header durable not set

https://issues.apache.org/jira/browse/ARTEMIS-888




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---