Re: [VOTE] Release activemq-nms-api 2.0.0-rc1

[Martyn Taylor]

+1 (Binding).  Thanks.

On Fri, Feb 19, 2021 at 3:04 PM Clebert Suconic 
wrote:

> +1 (binding)
>
> On Fri, Feb 19, 2021 at 1:09 AM Jean-Baptiste Onofre 
> wrote:
> >
> > +1 (binding)
> >
> > Regards
> > JB
> >
> > > Le 16 févr. 2021 à 22:12, Havret  a écrit :
> > >
> > > Hi All,
> > >
> > > I have put together a release of activemq-nms-api, please check it and
> vote
> > > accordingly.
> > >
> > > This release brings NMS 2.0 support.
> > >
> > > The files can be grabbed from:
> > >
> https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-api/2.0.0-rc1
> > >
> > > Regards,
> > > KP
> >
>
>
> --
> Clebert Suconic
>

Re: [DISCUSSION] New Quorum vote pluggable implementation

[Martyn Taylor]

I think this is a great idea Franz.  The HA and replication components have
been a source of issues over the years.  Two problems I see are that 1)
there isn't a clean separation between the consensus mechanism and the
replication, and 2) the consensus algorithm used in Artemis isn't based on
any standard algorithm or a research paper.  Hence, all the issues that
were caught over the years due to various edge cases.  Integration with
ZooKeeper seems like the obvious solution (i.e. push the consensus logic
off to a third party lib).  I suspect though, this will be a considerable
amount of work and is likely to introduce new issues, so I'd proceed with
caution.

Cheers



On Mon, Mar 2, 2020 at 8:28 AM nigro_franz  wrote:

> Hi folks,
>
> especially due to the requirements of the current Artemis quorum vote
> algorithm, we've thought to re-implementing it with a different focus in
> mind:
> 1) to make it pluggable (eg by using the many Raft implementations,
> ZooKeeper or others)
> 2) to cleanly separate the election phase and cluster member states (ie it
> should be the Topology shared between them)
> 3) to simplify most common setups in both amount of configuration and
> requirements (eg "witness" nodes could be implemented to get a minimum 2*n
> +1 quorum of nodes instead of forcing 2*n + 1 master-backup pairs)
> 4) [OPTIONALLY] to reduce/eliminate implicit "good practices" in term of
> order of actions to be performed on nodes in "special states" eg proper
> restart sequence after failover or similar cases
> 5) [OPTIONALLY] to make shared-store and replication behaviour more
> similar:
> journal's presence should be the only difference between the 2s
>
> A proposal of steps to be followed to get this:
> 1) abstract away the current quorum vote: it requires extra-care because
> the
> logic is melted together with the replication/clustering behaviour
> 2) refactor it in order to separate election phase and cluster member
> states
> 3) implement a RI version of such APIs
>
> Post-actions to help people adopt it, but need to be thought upfront:
> 1) a clean upgrade path for current HA replication users
> 2) deprecate or integrate the current HA replication into the new version
>
> I've opened this here because many of the HA replication users are devs too
> and given that this isn't yet implemented: we're stull in the
> design/proposal phase, so anyone that want to express their
> ideas/opinions/POC on this, is invited to talk here ;)
>
> Cheers,
> Franz
>
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
>

Re: Artemis: AMQP create queue based on FQQN

[Martyn Taylor]

My understanding was that auto-creation of FQQN queues was always an
intention but was never implemented.  Enabling this in the AMQP (and other
protocols) *should* allow any JMS over AMQP clients to utilize this
feature.  There may be some details here in terms of order of
precedence when using topic/queue capabilities (as defined in the JMS AMQP
mapping) and what is specified in the FQQN, but could be implemented
relatively easily.

On Fri, Jan 10, 2020 at 10:47 PM Clebert Suconic 
wrote:

> Up until artemis 1.x we only had the concept of address-name / queue-name.
>
> We had to add a few hacks back then during 1.x on the server
> (specially on the JMS implementation) such as queues with forced-empty
> filters to ensure we hold the existence of the address. So, the new
> address model helped to eliminate these hacks. (Damn JMS.. as it
> requires certain semantics such as knowing when an "empty" address
> does not exist.. damn topics!)
>
> Other than that the address model I think it's pretty flexible. The
> routing type exists pretty much to differentiate empty addresses.
> Again.. damn JMS! as we require that kind of thing to satisfy topics.
>
> Martyn Taylor and Justin Bertram can speak more about that as they
> wrote the changes. I had extensive conversations with them at the
> time.. but they can speak more on that.
>
>
> On Fri, Jan 10, 2020 at 4:44 PM Krzysztof  wrote:
> >
> > @Justin
> >
> > In my humble opinion the greatest power of JMS is also its greatest
> > weakness, and it's not the fact that its Java based. It's the
> > specification, that enforces some serious constraints like requirement of
> > serial execution of consumer callbacks inside the same session, ability
> to
> > "recover" session on the client, enforcing transactions on all link
> actions
> > (acks and sends) inside the same session, session based acknowledgment
> etc.
> > that doesn't add much value from the user perspective, and at the same
> time
> > seriously degrade the overall implementation and usability.
> >
> > I think that from Artemis perspective there is no concept of AMQP
> > flexibility. As you pointed out, AMQP doesn't "know" anything about
> routing
> > types, addresses, and queues (actually it does know sth about addresses
> ;)
> > But at the same time it doesn't know anything about topics, queues,
> shared
> > durable subscriptions, non shared durable subscriptions, and all that
> > either. You do not map AMQP concepts onto the Artemis addressing model.
> You
> > are mapping qpid-jms implementation to Artemis addressing model. As a
> > result Artemis amqp provider is so tightly coupled to jms, that if you do
> > not know the internals of qpid-jms amqp protocol you are forced to either
> > pre-configure all of your messaging topology upfront on the broker, and
> use
> > FQQN, or you can use only some rudimentary features of the addressing
> > model.
> >
> > I don't want to implement the core protocol because there is already a
> > great low level library AmqpNetLite (it is the counterpart of proton in
> > java world) that I am using as a base for my Artemis client. I don't want
> > to reinvent the wheel. But at the same time I don't want to adapt JMS
> > addressing model and concepts because it simply doesn't feel right to me.
> > It doesn't have to be so complicated.
> >
> > I was talking with developers from my company for the last 6 months and
> > collecting feedback regarding NMS.AMQP implementation (that I was working
> > on) and they were all complaining about the API. Most of the teams ended
> up
> > creating their own abstractions on top of it, just to hide the nms bits.
> > And they haven't even seen jms 2.0 spec. I think in java world it is
> quite
> > similar (that's why there are bits like JmsTemplate,
> > SimpleListenerContainers and the like.
> >
> > I don't want to impose anything. I just think that Artemis is a great
> piece
> > of technology and it is a shame that it's so dramatically unpopular in
> .net
> > world. It deserves better. But without a decent client it's hard to hope
> > for it.
> >
> > I don't want to shoehorn anything. I think the concept of FQQN provides a
> > nice loophole for everything I need, besides maybe some minor changes
> > (creating queues if they aren't created upfront, and basically that's
> it).
> >
> > On Fri, Jan 10, 2020 at 12:04 AM Justin Bertram 
> wrote:
> >
> > > This seems a little strange to me.
> > >
> > > The power of JMS is that it is broker agnostic. It's just an API of
> fairly
> > >

Re: [VOTE] Release Apache NMS AMQP 1.8.0 - RC2

[Martyn Taylor]

+1 (Binding)

On Thu, Oct 31, 2019 at 3:18 PM Michael Pearce 
wrote:

> Hi All,
>
> Thanks all how reviewed rc1, hopefully all the points raised are now
> resolved.
>
> I have put together a second spin for a Apache NMS AMQP release, please
> check it and vote accordingly.
>
> This release effectively will be the first release of a NMS AMQP client..
>
> Also includes some modernisation of the project that was needed to
> make the release, updating for latest visual studio, and lastly,
> creating a nuget package, that once approved, we can publish to nuget.
>
> The files can be grabbed
> from:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-amqp/1.8.0-rc2/
>
> The JIRAs assigned for this release can be found:
>
>
> https://issues.apache.org/jira/browse/AMQNET-618?jql=project%20%3D%20AMQNET%20AND%20fixVersion%20%3D%201.8.0%20AND%20component%20%3D%20AMQP
>
>
> Regards,
> Michael
>

Re: [VOTE] Release Apache NMS 1.8.0 - Release Candidate 6

[Martyn Taylor]

+1 (Binding)

On Sat, Jun 29, 2019 at 4:47 AM Clebert Suconic 
wrote:

> +1 binding.
>
> On Fri, Jun 28, 2019 at 2:02 PM 
> wrote:
>
> > Just realised though whilst its implied as the person performing the
> > release. Here is my formal:
> >
> >
> >
> >
> > +1 (binding)
> >
> >
> >
> >
> > Get Outlook for Android
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Jun 28, 2019 at 4:08 PM +0100, "cmorgan" <
> > christopher.mor...@solace.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > +1 (non-binding)
> > Looks good to to me.
> > Adding support for netstandard 2.0 is great!
> >
> >
> >
> > -
> > Chris Morgan
> > --
> > Sent from:
> > http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
> >
> >
> >
> >
> >
> > --
> Clebert Suconic
>

Re: [VOTE] Website Update

[Martyn Taylor]

+1

On Thu, Mar 28, 2019 at 10:25 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> +1
>
> On Thu, Mar 28, 2019 at 6:12 AM Gary Tully  wrote:
>
> > +1
> >
> > great work. It looks really fresh and the style is crisp.
> >
> > On Wed, 27 Mar 2019 at 20:07, Justin Bertram 
> wrote:
> > >
> > > As most of you probably know there's been work underway to update the
> > > ActiveMQ website for the better part of a year. That work has reached a
> > > point where it makes sense to vote on whether or not it should replace
> > the
> > > existing website. The new website is available at:
> > >
> > >   http://activemq.apache.org/activemq-website/
> > >
> > > All existing links for *ActiveMQ 5.x* content should continue to work
> > as-is.
> > >
> > > The source files for the new site are hosted here:
> > >
> > >   https://github.com/apache/activemq-website/
> > >
> > > This repo includes instructions on how to modify, test, & update the
> > site.
> > >
> > >
> > > [ ] +1 approve the promotion of the new website to be the official
> > ActiveMQ
> > > website
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove (and reason why)
> > >
> > > Here's my +1
> > >
> > >
> > > Justin
> >
>

Re: Website

[Martyn Taylor]

eded to> > > > satisfy various site
> > policies:> > > > https://www.apache.org/foundation/marks/pmcs> > > >> >
> >
> > > At least some of these are checked automatically:> > > >
> > https://whimsy.apache.org/site/> > > >> > > > Robbie> > > >> > > > On
> > Mon, 4 Mar 2019 at 14:54, Clebert Suconic <> > clebert.suco...@gmail.com
> >>
> > > > > wrote:> > > > >> > > > > This looks ready! What we need to make it
> > official?> > > > >> > > > > On Fri, Mar 1, 2019 at 12:53 PM Justin
> Bertram <
> > jbert...@apache.org>> > > > wrote:> > > > > >> > > > > > I added some
> > content to the landing page and pushed it to the> > staging> > > > > >
> > website [1]. In general, I tried to highlight what was true for> >
> *both*>
> > > > > > > brokers but also distinguish them to make things clear for
> > users.> > > > I've got> > > > > > other content changes ready to push,
> but
> > I wanted to get this out> > > > first for> > > > > > review &
> discussion.>
> > > > > > >> > > > > > In case anybody wonders, I removed the big "Used By"
> > section that> > was> > > > > > supposed to be full of company logos for
> two
> > reasons:> > > > > >   1) I'm not sure we have any concrete data on
> that.> >
> > > > > >   2) It's not clear to me whether or not we need permission to
> use>
> > > > > another> > > > > > company's logo on our website and make claims
> > about their use of> > > > ActiveMQ.> > > > > >> > > > > >> > > > > >
> > Justin> > > > > >> > > > > > [1]
> > http://activemq.apache.org/activemq-website/> > > > > >> > > > > > On
> > Wed, Nov 7, 2018 at 9:59 AM Andy Taylor  > >> >
> >
> > > wrote:> > > > > >> > > > > > > I'd be happy to help with adding
> content,
> > I remember a hackathon> > was> > > > > > > mentioned at one point.> > >
> > >
> > > >> > > > > > > Any way since it's now in git it would be great if
> people
> > could> > > > contribute> > > > > > > so we can have a better website
> sooner
> > rather than later.> > > > > > >> > > > > > > Andy> > > > > > >> > > > >
> > >
> > On Tue, 6 Nov 2018 at 17:19, Martyn Taylor > > > >
> > wrote:> > > > > > >> > > > > > > > The site is uploaded and links
> added.> >
> > > > > > > >> > > > > > > > Note there's currently a sync issue with EU
> > mirrors[1], it's> > > > currently> > > > > > > > being worked on.  To
> view
> > the changes in the interim, use the> > US> > > > > > > mirror[2].> > > >
> >
> > > > >> > > > > > > > Cheers> > > > > > > > Martyn> > > > > > > >> > > >
> > >
> > > > 1. https://status.apache.org/> > > > > > > > 2.
> > http://activemq.us.apache.org/> > > > > > > >> > > > > > > > On Tue, Nov
> > 6, 2018 at 4:58 PM Martyn Taylor <> > mtay...@redhat.com>> > > > wrote:>
> > > > > > > > >> > > > > > > > > I've went ahead and populated the
> > repository, there's a> > GitHub> > > > mirror> > > > > > > > > here[1].
> > I've also generated the static content and should> > have> > > > the> >
> > >
> > > > > work> > > > > > > > > in progress hosted under a separately
> directory
> > and a> > message on> > > > the> > > > > > > > > homepage shortly.> > > >
> >
> > > > > >> > > > > > > > > Cheers> > > > > > > >

Re: Website

[Martyn Taylor]

The site is uploaded and links added.

Note there's currently a sync issue with EU mirrors[1], it's currently
being worked on.  To view the changes in the interim, use the US mirror[2].

Cheers
Martyn

1. https://status.apache.org/
2. http://activemq.us.apache.org/

On Tue, Nov 6, 2018 at 4:58 PM Martyn Taylor  wrote:

> I've went ahead and populated the repository, there's a GitHub mirror
> here[1].  I've also generated the static content and should have the work
> in progress hosted under a separately directory and a message on the
> homepage shortly.
>
> Cheers
>
> 1. https://github.com/apache/activemq-website
>
>
> On Fri, Oct 26, 2018 at 8:54 PM Bruce Snyder 
> wrote:
>
>> +1
>>
>> Bruce
>>
>> On Tue, Oct 23, 2018 at 2:26 PM Clebert Suconic <
>> clebert.suco...@gmail.com>
>> wrote:
>>
>> > What about this. WE could :
>> >
>> > - commit this on git
>> > - upload a snapshot for review under our web-site.
>> > On Mon, Oct 22, 2018 at 8:46 AM Clebert Suconic
>> >  wrote:
>> > >
>> > > +1000. We had that options discussed here a few times.  Having the old
>> > website somewhere with a link is the way to go for the migration.
>> > >
>> > > On Mon, Oct 22, 2018 at 7:47 AM michael.andre.pearce <
>> > michael.andre.pea...@me.com.invalid> wrote:
>> > >>
>> > >> Sounds good to me.
>> > >>
>> > >>
>> > >> Sent from my Samsung Galaxy smartphone.
>> > >>  Original message From: Martyn Taylor <
>> > mtay...@redhat.com> Date: 22/10/2018  12:38  (GMT+00:00) To:
>> > dev@activemq.apache.org Subject: Re: Website
>> > >> How about an equivalent message on the home page of the new website,
>> > >> directing users to the old site?
>> > >>
>> > >> On Fri, Oct 19, 2018 at 10:39 PM Bruce Snyder <
>> bruce.sny...@gmail.com>
>> > >> wrote:
>> > >>
>> > >> > Check out the Camel website and the message that they posted about
>> > their
>> > >> > website changes that are underway:
>> > >> >
>> > >> > https://camel.apache.org/
>> > >> >
>> > >> > Bruce
>> > >> >
>> > >> > On Wed, Oct 17, 2018 at 3:30 AM Martyn Taylor 
>> > wrote:
>> > >> >
>> > >> > > On Fri, Oct 12, 2018 at 8:38 PM Bruce Snyder <
>> > bruce.sny...@gmail.com>
>> > >> > > wrote:
>> > >> > >
>> > >> > > > Fair points, Martyn. I like the idea of a combination of JIRA
>> > issues
>> > >> > > plus a
>> > >> > > > list of those issues that is easily visible somewhere such as
>> the
>> > wiki.
>> > >> > > >
>> > >> > > > Seeing as how we are moving the website around completely, I
>> > believe we
>> > >> > > > need to include the docs to support the older versions in some
>> > way. So,
>> > >> > > the
>> > >> > > > first thought that came to mind is a search capability in order
>> > for
>> > >> > users
>> > >> > > > to find them easier. Another idea, we could also keep the old
>> site
>> > >> > intact
>> > >> > > > and available as a sub-domain or URL, e.g.,
>> > 5x.activemq.apache.org,
>> > >> > > > activemq.apache.org/5.x, etc. However, the advantage of a
>> search
>> > >> > feature
>> > >> > > > is
>> > >> > > > that it would be useful across the site, not just for older
>> > stuff. We
>> > >> > > might
>> > >> > > > even be able structure the search to allow users to select a
>> > version of
>> > >> > > the
>> > >> > > > docs that they would like to search. Anyway, just some
>> thoughts.
>> > >> > > >
>> > >> > > > I agree that we should try to get the new site functional ASAP,
>> > but
>> > >> > that
>> > >> > > > should not eliminate the old site entirely. We should not
>> abandon
>> > users
>> > >> > > of
>> > >> > > > older versions.
>> > >> > &g

Re: Website

[Martyn Taylor]

I've went ahead and populated the repository, there's a GitHub mirror
here[1].  I've also generated the static content and should have the work
in progress hosted under a separately directory and a message on the
homepage shortly.

Cheers

1. https://github.com/apache/activemq-website


On Fri, Oct 26, 2018 at 8:54 PM Bruce Snyder  wrote:

> +1
>
> Bruce
>
> On Tue, Oct 23, 2018 at 2:26 PM Clebert Suconic  >
> wrote:
>
> > What about this. WE could :
> >
> > - commit this on git
> > - upload a snapshot for review under our web-site.
> > On Mon, Oct 22, 2018 at 8:46 AM Clebert Suconic
> >  wrote:
> > >
> > > +1000. We had that options discussed here a few times.  Having the old
> > website somewhere with a link is the way to go for the migration.
> > >
> > > On Mon, Oct 22, 2018 at 7:47 AM michael.andre.pearce <
> > michael.andre.pea...@me.com.invalid> wrote:
> > >>
> > >> Sounds good to me.
> > >>
> > >>
> > >> Sent from my Samsung Galaxy smartphone.
> > >>  Original message From: Martyn Taylor <
> > mtay...@redhat.com> Date: 22/10/2018  12:38  (GMT+00:00) To:
> > dev@activemq.apache.org Subject: Re: Website
> > >> How about an equivalent message on the home page of the new website,
> > >> directing users to the old site?
> > >>
> > >> On Fri, Oct 19, 2018 at 10:39 PM Bruce Snyder  >
> > >> wrote:
> > >>
> > >> > Check out the Camel website and the message that they posted about
> > their
> > >> > website changes that are underway:
> > >> >
> > >> > https://camel.apache.org/
> > >> >
> > >> > Bruce
> > >> >
> > >> > On Wed, Oct 17, 2018 at 3:30 AM Martyn Taylor 
> > wrote:
> > >> >
> > >> > > On Fri, Oct 12, 2018 at 8:38 PM Bruce Snyder <
> > bruce.sny...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Fair points, Martyn. I like the idea of a combination of JIRA
> > issues
> > >> > > plus a
> > >> > > > list of those issues that is easily visible somewhere such as
> the
> > wiki.
> > >> > > >
> > >> > > > Seeing as how we are moving the website around completely, I
> > believe we
> > >> > > > need to include the docs to support the older versions in some
> > way. So,
> > >> > > the
> > >> > > > first thought that came to mind is a search capability in order
> > for
> > >> > users
> > >> > > > to find them easier. Another idea, we could also keep the old
> site
> > >> > intact
> > >> > > > and available as a sub-domain or URL, e.g.,
> > 5x.activemq.apache.org,
> > >> > > > activemq.apache.org/5.x, etc. However, the advantage of a
> search
> > >> > feature
> > >> > > > is
> > >> > > > that it would be useful across the site, not just for older
> > stuff. We
> > >> > > might
> > >> > > > even be able structure the search to allow users to select a
> > version of
> > >> > > the
> > >> > > > docs that they would like to search. Anyway, just some thoughts.
> > >> > > >
> > >> > > > I agree that we should try to get the new site functional ASAP,
> > but
> > >> > that
> > >> > > > should not eliminate the old site entirely. We should not
> abandon
> > users
> > >> > > of
> > >> > > > older versions.
> > >> > > >
> > >> > > +1 Bruce.
> > >> > >
> > >> > > I had thought that the export of the current site into the gitbook
> > had
> > >> > all
> > >> > > the info, but perhaps there are missing pieces.  I like the idea
> of
> > >> > keeping
> > >> > > the old site running and link to it from the new site.  This
> ensures
> > >> > > existing users have all the info they need, but let's us move
> > forward
> > >> > with
> > >> > > new content.  Perhaps we can switch out the exiting home page for
> > the new
> > >> > > one and add a link to old website AMQ project page ("Existing
> user

Re: Website

[Martyn Taylor]

How about an equivalent message on the home page of the new website,
directing users to the old site?

On Fri, Oct 19, 2018 at 10:39 PM Bruce Snyder 
wrote:

> Check out the Camel website and the message that they posted about their
> website changes that are underway:
>
> https://camel.apache.org/
>
> Bruce
>
> On Wed, Oct 17, 2018 at 3:30 AM Martyn Taylor  wrote:
>
> > On Fri, Oct 12, 2018 at 8:38 PM Bruce Snyder 
> > wrote:
> >
> > > Fair points, Martyn. I like the idea of a combination of JIRA issues
> > plus a
> > > list of those issues that is easily visible somewhere such as the wiki.
> > >
> > > Seeing as how we are moving the website around completely, I believe we
> > > need to include the docs to support the older versions in some way. So,
> > the
> > > first thought that came to mind is a search capability in order for
> users
> > > to find them easier. Another idea, we could also keep the old site
> intact
> > > and available as a sub-domain or URL, e.g., 5x.activemq.apache.org,
> > > activemq.apache.org/5.x, etc. However, the advantage of a search
> feature
> > > is
> > > that it would be useful across the site, not just for older stuff. We
> > might
> > > even be able structure the search to allow users to select a version of
> > the
> > > docs that they would like to search. Anyway, just some thoughts.
> > >
> > > I agree that we should try to get the new site functional ASAP, but
> that
> > > should not eliminate the old site entirely. We should not abandon users
> > of
> > > older versions.
> > >
> > +1 Bruce.
> >
> > I had thought that the export of the current site into the gitbook had
> all
> > the info, but perhaps there are missing pieces.  I like the idea of
> keeping
> > the old site running and link to it from the new site.  This ensures
> > existing users have all the info they need, but let's us move forward
> with
> > new content.  Perhaps we can switch out the exiting home page for the new
> > one and add a link to old website AMQ project page ("Existing users
> looking
> > for the original ActiveMQ website click here.").  If we are able to get
> > some stats on number of accesses to a particular page, we can use that
> info
> > to prioritise porting older content.
> >
> > Search, feature also a good idea, but I'm not sure how much effort would
> be
> > involved, there is already a search feature in the gitbook document
> (linked
> > to on the project page).
> >
> > How about we fill in the existing placeholder content and add links to
> the
> > old sites from each project page (and the home page)?  We could go live
> > with this?  Then start working through the nice to haves/criticals.  I
> > think once we're live and the code is available, the community will be
> more
> > inclined to report/fixing issues.
> >
> > Cheers
> >
> > >
> > > Bruce
> > >
> > > On Fri, Oct 12, 2018 at 2:44 AM Martyn Taylor 
> > wrote:
> > >
> > > > Cheers gents, looks like we're all set with the git repos.
> > > >
> > > > Shall we start putting together a ToDo list for what needs to happen
> to
> > > > move to the new site?  JIRA perhaps?
> > > >
> > > > Bruce you mentioned a search feature for older content.  Can you
> > > elaborate
> > > > on this.  Also, there's the actual content for the pages, key
> features,
> > > > users etc... Perhaps we can all contribute to these?  I could take
> care
> > > of
> > > > the Artemis side of things, if people with more experience in NMS,
> CMS
> > > and
> > > > 5.x could come up with some content for the project home pages?
> > > >
> > > > I agree with Michael in that it'd be good to get the new site running
> > > even
> > > > if it's not 100% perfect then iteratively improve on it.
> > > >
> > > > Cheers
> > > >
> > > > On Thu, Oct 11, 2018 at 12:56 AM Clebert Suconic <
> > > > clebert.suco...@gmail.com>
> > > > wrote:
> > > >
> > > > > How to delete one now ?
> > > > >
> > > > > On Tue, Oct 9, 2018 at 6:55 PM Bruce Snyder <
> bruce.sny...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Whoops, I just created one as well:
> > > > > >
> > > > > > https:/

Re: Website

[Martyn Taylor]

On Fri, Oct 12, 2018 at 8:38 PM Bruce Snyder  wrote:

> Fair points, Martyn. I like the idea of a combination of JIRA issues plus a
> list of those issues that is easily visible somewhere such as the wiki.
>
> Seeing as how we are moving the website around completely, I believe we
> need to include the docs to support the older versions in some way. So, the
> first thought that came to mind is a search capability in order for users
> to find them easier. Another idea, we could also keep the old site intact
> and available as a sub-domain or URL, e.g., 5x.activemq.apache.org,
> activemq.apache.org/5.x, etc. However, the advantage of a search feature
> is
> that it would be useful across the site, not just for older stuff. We might
> even be able structure the search to allow users to select a version of the
> docs that they would like to search. Anyway, just some thoughts.
>
> I agree that we should try to get the new site functional ASAP, but that
> should not eliminate the old site entirely. We should not abandon users of
> older versions.
>
+1 Bruce.

I had thought that the export of the current site into the gitbook had all
the info, but perhaps there are missing pieces.  I like the idea of keeping
the old site running and link to it from the new site.  This ensures
existing users have all the info they need, but let's us move forward with
new content.  Perhaps we can switch out the exiting home page for the new
one and add a link to old website AMQ project page ("Existing users looking
for the original ActiveMQ website click here.").  If we are able to get
some stats on number of accesses to a particular page, we can use that info
to prioritise porting older content.

Search, feature also a good idea, but I'm not sure how much effort would be
involved, there is already a search feature in the gitbook document (linked
to on the project page).

How about we fill in the existing placeholder content and add links to the
old sites from each project page (and the home page)?  We could go live
with this?  Then start working through the nice to haves/criticals.  I
think once we're live and the code is available, the community will be more
inclined to report/fixing issues.

Cheers

>
> Bruce
>
> On Fri, Oct 12, 2018 at 2:44 AM Martyn Taylor  wrote:
>
> > Cheers gents, looks like we're all set with the git repos.
> >
> > Shall we start putting together a ToDo list for what needs to happen to
> > move to the new site?  JIRA perhaps?
> >
> > Bruce you mentioned a search feature for older content.  Can you
> elaborate
> > on this.  Also, there's the actual content for the pages, key features,
> > users etc... Perhaps we can all contribute to these?  I could take care
> of
> > the Artemis side of things, if people with more experience in NMS, CMS
> and
> > 5.x could come up with some content for the project home pages?
> >
> > I agree with Michael in that it'd be good to get the new site running
> even
> > if it's not 100% perfect then iteratively improve on it.
> >
> > Cheers
> >
> > On Thu, Oct 11, 2018 at 12:56 AM Clebert Suconic <
> > clebert.suco...@gmail.com>
> > wrote:
> >
> > > How to delete one now ?
> > >
> > > On Tue, Oct 9, 2018 at 6:55 PM Bruce Snyder 
> > > wrote:
> > >
> > > > Whoops, I just created one as well:
> > > >
> > > > https://gitbox.apache.org/repos/asf?p=activemq-website.git
> > > >
> > > > Bruce
> > > >
> > > > On Tue, Oct 9, 2018 at 8:49 AM Clebert Suconic <
> > > clebert.suco...@gmail.com>
> > > > wrote:
> > > >
> > > > > New repo created:
> > > > >
> > > > > https://gitbox.apache.org/repos/asf?p=activemq-www.git
> > > > > On Tue, Oct 9, 2018 at 10:47 AM Clebert Suconic
> > > > >  wrote:
> > > > > >
> > > > > > Robbie Gemmel pointed me to https://gitbox.apache.org/
> > > > > >
> > > > > > I'm trying to create one now:
> > > > > > On Tue, Oct 9, 2018 at 10:36 AM Clebert Suconic
> > > > > >  wrote:
> > > > > > >
> > > > > > > That's for Bruce Snyder then...
> > > > > > > On Tue, Oct 9, 2018 at 10:29 AM Justin Bertram <
> > > jbert...@redhat.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > There's a "Create a new Git repository" option on
> > > > > > > > https://selfserve.apache.org/.  I clicked it and logged in,
> > but
> > > > > appa

Re: Website

[Martyn Taylor]

Cheers gents, looks like we're all set with the git repos.

Shall we start putting together a ToDo list for what needs to happen to
move to the new site?  JIRA perhaps?

Bruce you mentioned a search feature for older content.  Can you elaborate
on this.  Also, there's the actual content for the pages, key features,
users etc... Perhaps we can all contribute to these?  I could take care of
the Artemis side of things, if people with more experience in NMS, CMS and
5.x could come up with some content for the project home pages?

I agree with Michael in that it'd be good to get the new site running even
if it's not 100% perfect then iteratively improve on it.

Cheers

On Thu, Oct 11, 2018 at 12:56 AM Clebert Suconic 
wrote:

> How to delete one now ?
>
> On Tue, Oct 9, 2018 at 6:55 PM Bruce Snyder 
> wrote:
>
> > Whoops, I just created one as well:
> >
> > https://gitbox.apache.org/repos/asf?p=activemq-website.git
> >
> > Bruce
> >
> > On Tue, Oct 9, 2018 at 8:49 AM Clebert Suconic <
> clebert.suco...@gmail.com>
> > wrote:
> >
> > > New repo created:
> > >
> > > https://gitbox.apache.org/repos/asf?p=activemq-www.git
> > > On Tue, Oct 9, 2018 at 10:47 AM Clebert Suconic
> > >  wrote:
> > > >
> > > > Robbie Gemmel pointed me to https://gitbox.apache.org/
> > > >
> > > > I'm trying to create one now:
> > > > On Tue, Oct 9, 2018 at 10:36 AM Clebert Suconic
> > > >  wrote:
> > > > >
> > > > > That's for Bruce Snyder then...
> > > > > On Tue, Oct 9, 2018 at 10:29 AM Justin Bertram <
> jbert...@redhat.com>
> > > wrote:
> > > > > >
> > > > > > There's a "Create a new Git repository" option on
> > > > > > https://selfserve.apache.org/.  I clicked it and logged in, but
> > > apparently
> > > > > > it's restricted to ASF members and PMC chairs.
> > > > > >
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > On Tue, Oct 9, 2018 at 9:24 AM Clebert Suconic <
> > > clebert.suco...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I create an Infra JIRA for this:
> > > > > > >
> > > > > > >
> > > > > > > https://issues.apache.org/jira/browse/INFRA-17124
> > > > > > > On Tue, Oct 9, 2018 at 9:49 AM Clebert Suconic
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > I asked infra and no reponse.
> > > > > > > >
> > > > > > > > Does anyone know any procedure on creating a repo at apache?
> > > > > > > >
> > > > > > > >
> > > > > > > > I did ask infra about something what to do.. but so far no
> > > response. I
> > > > > > > > know they are busy.. so if anyone here knows a better way to
> > > handle
> > > > > > > > this
> > > > > > > > On Mon, Oct 8, 2018 at 9:14 AM Clebert Suconic
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > I just initiated a thread at apache infra list, asking for
> > > guidance on
> > > > > > > > > how to setup things.
> > > > > > > > >
> > > > > > > > > will keep it posted here.
> > > > > > > > > On Mon, Oct 8, 2018 at 9:01 AM Christopher Shannon
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > Thanks for getting the website discussion restarted.  I
> > > think it
> > > > > > > will be
> > > > > > > > > > quite beneficial if we can get the new website live and
> > have
> > > more
> > > > > > > clear
> > > > > > > > > > information on there such as what Artemis is, etc.
> > > > > > > > > >
> > > > > > > > > > On Sat, Oct 6, 2018 at 9:13 AM Clebert Suconic <
> > > > > > > clebert.suco...@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > I will handle it next week.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Oct 4, 2018 at 5:09 PM Bruce Snyder <
> > > > > > > bruce.sny...@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Clebert,
> > > > > > > > > > > >
> > > > > > > > > > > > It would be very helpful if you could create a git
> repo
> > > for it
> > > > > > > and get
> > > > > > > > > > > the
> > > > > > > > > > > > source code moved into there.
> > > > > > > > > > > >
> > > > > > > > > > > > Bruce
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Oct 4, 2018 at 7:58 AM Clebert Suconic <
> > > > > > > > > > > clebert.suco...@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > @Bruce: Anything I can do to expedie this? or you
> are
> > > taking
> > > > > > > care of
> > > > > > > > > > > > > the private repo?
> > > > > > > > > > > > > On Wed, Oct 3, 2018 at 1:52 AM michael.andre.pearce
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you noted because its using jekyll i could use
> > > github
> > > > > > > pages.
> > > > > > > > > > > > > > One option is you could host it on asf git, have
> > the
> > > github
> > > > > > > clone
> > > > > > > > > > > like
> > > > > > > > > > > > > we do with code and then use github pages, simply
> > > asking infra
> > > > > > > to have
> > > > > > > > > > > > the
> > > > > > > > > > > > > sub domain point to the github pages. Not sure if
> > 

Re: [VOTE] Apache ActiveMQ Artemis 2.6.3

[Martyn Taylor]

+1.

On Fri, Aug 31, 2018 at 6:08 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> +1
>
> On Fri, Aug 31, 2018 at 11:11 AM Timothy Bish  wrote:
>
> > On 08/30/2018 10:46 PM, Clebert Suconic wrote:
> > > I would like to propose an Apache ActiveMQ Artemis 2.6.3 release.
> > >
> > > This release has many bug fixes and a few performance improvements,
> > > and it contains exactly 100 commits, covering 54 JIRAs. Thanks a lot
> > > to all who contributed.
> > >
> > > A report of commits can be found here:
> > > http://activemq.apache.org/artemis/commit-report-2.6.3.html
> > >
> > > The release notes can be found here:
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12315920=12343472
> > >
> > > Source and binary distributions can be found here:
> > > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.6.3
> > >
> > >
> > > The Maven repository is here:
> > >
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1171
> > >
> > >
> > > In case you want to give it a try with the maven repo on examples:
> > >
> > http://activemq.apache.org/artemis/docs/latest/hacking-
> guide/validating-releases.html
> > >
> > >
> > > The source tag:
> > >
> > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> git;a=tag;h=refs/tags/2.6.3
> > >
> > >
> > > I will update the website after the vote has passed.
> > >
> > >
> > >
> > > [ ] +1 approve the release as Apache Artemis 2.6.3
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove (and reason why)
> > >
> > >
> > > Here's my +1
> > >
> >
> > +1
> >
> > * Validated signatures and checksums
> > * Check for license and notice files
> > * Ran mvn apache-rat:check to verify source license headers
> > * Ran broker from binary archive and checked admin console and ran some
> > examples against it
> > * Built from source and ran sanity tests and the full set of AMQP
> > integration tests
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> >
>

Re: HEADS-UP ActiveMQ Artemis 2.6.3 to be cut Friday the 10th

[Martyn Taylor]

@Clebert.  There's been a pretty serious issue discovered with the RA, in
that it's not performing fail over properly.  This results in a loss of all
availability for messaging.  It was discovered during some WildFly
testing.  I've reported the issue[1] and linked to the original.

Are we able to get this resolved in the next release?  It may require us
holding out a couple extra days to get the fix.

Cheers

1. https://issues.apache.org/jira/browse/ARTEMIS-2032

On Tue, Aug 14, 2018 at 7:29 AM, michael.andre.pearce <
michael.andre.pea...@me.com.invalid> wrote:

> Ive sent a pr to master to show the issue and fix which would need to go
> to 2.6.x branch
>
> https://github.com/apache/activemq-artemis/pull/2249
>
> Sent from my Samsung Galaxy smartphone.
>  Original message From: "michael.andre.pearce" <
> michael.andre.pea...@me.com> Date: 14/08/2018  06:04  (GMT+00:00) To:
> dev@activemq.apache.org Subject: Re: HEADS-UP ActiveMQ Artemis 2.6.3 to
> be cut Friday the 10th
> Hi Clebert
> Theres an NPE introduced in
>
> https://github.com/apache/activemq-artemis/commit/
> bf282e5e7d133e898f0dc4d08f4df87722fc5a91
> I have commented on the PR that was merged that introduced it. So needs to
> be fixed before release.
>
> Sent from my Samsung Galaxy smartphone.
>

Re: [VOTE] Apache ActiveMQ Artemis 2.6.1 (3rd respin)

[Martyn Taylor]

+1

On Wed, Jun 6, 2018 at 4:22 PM, Francesco Nigro  wrote:

> +1
>
> *built and run some tests
>
> Il giorno mer 6 giu 2018 alle ore 16:45 Timothy Bish 
> ha scritto:
>
> > On 06/04/2018 08:35 PM, Clebert Suconic wrote:
> > > I would like to propose an Apache ActiveMQ Artemis 2.6.1 release. This
> > > is the 3rd Respin and I have fixed the previous issues encountered.
> > >
> > >
> > > This is a micro release, with bug fixes only, where I would like to
> > > highlight these fixes:
> > >
> > > [ARTEMIS-1568] Expired Messages were not transversing clustering
> > redistribution.
> > >   (this could affect other queues beyond the Expiry as well)
> > >
> > > [ARTEMIS-1872]Check for queue exists before creating shared queue
> > >
> > > [ARTEMIS-1902] Message redistribution is not stopped when consumers
> > > count on remote node reaches 0 (AMQP)
> > >
> > >
> > >
> > > The full JIRA report is here:
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12315920=12343356
> > >
> > >
> > > The git commit report is here:
> > > http://activemq.apache.org/artemis/commit-report-2.6.1.html
> > >
> > > (notice this report is not indexed on the website yet, I will add a
> > > link and update the report if needed once the release is approved)
> > >
> > >
> > >
> > > Source and binary distributions can be found here:
> > > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.6.1
> > >
> > >
> > > The Maven repository is here:
> > >
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1164
> > >
> > >
> > > In case you want to give it a try with the maven repo on examples:
> > >
> > http://activemq.apache.org/artemis/docs/latest/hacking-
> guide/validating-releases.html
> > >
> > > The source tag:
> > >
> > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> git;a=tag;h=refs/tags/2.6.1
> > >
> > >
> > > I will update the website after the vote has passed.
> > >
> > >
> > > [ ] +1 approve the release as Apache Artemis 2.6.1
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove (and reason why)
> > >
> > > Here's my +1
> > >
> >
> > +1
> >
> > * Validated signatures and checksums
> > * Checked for license and notice files in the archives
> > * built from source and ran some of the integration tests
> > * used mvn apache-rat:check to scan for missing license headers
> > * Ran some external examples against a running broker from the binary
> > distribution.
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> >
>

Re: [DISCUSS] Separate commit for Test and Fix on PRs

[Martyn Taylor]

I think having test that don't compile due to code changes is an
exception.  I think we should strive for this approach.  Clebert, I follow
the same process you described, I undo the change then run the test to see
what was wrong and that the test is valid.  In my opinion this is a
positive thing to strive to.  Obviously common sense should prevail, and if
there are some reason it's not possible or very difficult then we can relax
the rule.

On Thu, Apr 19, 2018 at 10:13 PM, Clebert Suconic  wrote:

> will I sound crazy if I change my mind here?
>
> I thought it would be improving the PR process.. but on a second
> thought... it won't improve things actually and i will agree with
> Robbie here.
>
>  So. .just ignore me.. and apologize for spamming  you guys..
>
> On Thu, Apr 19, 2018 at 10:48 AM, Timothy Bish 
> wrote:
> > On 04/19/2018 10:32 AM, Robbie Gemmell wrote:
> >>
> >> I dont think its unreasonable or unexpected in many cases that a test
> >> fails to compile without the changes in relates to. It depends what
> >> type of test it is and what the changes actually are though.
> >>
> >> I agree it wont hugely change the PR though. Possibly why I prefer
> >> them being in the same commit is I tend to use the commit to look over
> >> things rather than the PR.
> >
> >
> > The other thing to keep in mind is that when two or more commits for the
> > same bit of work go in, the process of reverting changes becomes more
> error
> > prone as the person doing the reverts has to always be looking for the
> cases
> > where there was more than one related to the same scope of work.
> >
> >
> >> On 19 April 2018 at 15:10, Clebert Suconic 
> >> wrote:
> >>>
> >>> I have seen a few cases where the test would not compile.. that is the
> >>> test depends on the changes itself. What is not really Test Driven
> >>> Development.
> >>>
> >>> Both tests and fixes are part of the same PR.. so it doesn't really
> >>> change much.
> >>>
> >>> On Thu, Apr 19, 2018 at 9:41 AM, Robbie Gemmell
> >>>  wrote:
> 
>  In general I think having tests and changes in the same commit is
>  nicer, especially for looking back at later.
> 
>  I'll also often apply a test on its own or revert the non-test changes
>  to ensure tests fail, I've not really found it slow/annoying enough to
>  specifically seperate tests out in their own commits to facilitate it.
> 
>  Robbie
> 
>  On 18 April 2018 at 18:27, Clebert Suconic  >
>  wrote:
> >
> > I would appreciate if we separated fixes and tests on Pull Requests.
> >
> >
> > A lot of times i will revert the fixes to validate if the test is
> good
> > (if it fails without a fix) and how it failed. (not that I don't
> trust
> > the committer, just part of the validation as sometimes I want to see
> > what was the semantic change and fix). I may eventually play a better
> > fix in the process.. and I am sure that would apply to anyone else
> > helping on reviewing commits.
> >
> >
> > I had at some point gone back in history and needed to apply the test
> > without a fix to find a better fix.
> >
> > I know eventually it's not possible to separate these.. but if you
> > could as much as possible separate them:?
> >
> >
> > I recently did that into PR #2004...
> >
> >
> > https://github.com/apache/activemq-artemis/commit/
> a72046a0e32fd47cad988a8d71512927f74c8585
> >
> >
> > https://github.com/apache/activemq-artemis/commit/
> a72046a0e32fd47cad988a8d71512927f74c8585
> >
> >
> >
> >
> > I may update the hacking guide with this.. WDYT?
> >
> >
> > --
> > Clebert Suconic
> >>>
> >>>
> >>>
> >>> --
> >>> Clebert Suconic
> >
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
>
>
>
> --
> Clebert Suconic
>

Re: Thoughts on refactoring the ActiveMQ website

[Martyn Taylor]

Bruce, All

We organised a webex discussion on the dev list[1] where we discussed
Michael's proposal and created a bunch of JIRA[2] that we think are needed
in order to move forward with the proposal.  Unfortunately only a handful
of people attended.  There is concern that a lot of work will be put into
building a new site based on Michael's proposal only for it to get -1 at
the last minute.  For this reason, can I suggest that people take some time
to look into what has been done already by checking out the git repo as
Bruce suggested, or we schedule another webex session where Michael can
talk about his proposal.  We can then take a vote as to whether or not this
is an approach we want to move forward with and what the requirements are
to go live.

Thanks

[1] http://activemq.2283324.n4.nabble.com/Website-Discussion-td4737173.html
[2] https://issues.apache.org/jira/browse/AMQ-6912



On Fri, Mar 16, 2018 at 2:29 AM, Bruce Snyder 
wrote:

> Everyone should take a look at the gitbook that Mike put together. It's a
> great first example.
>
> https://github.com/apache/activemq-web/pull/3
>
> Please take 10 minutes to clone the repo, switch to the branch, install
> gitbook, run gitbook and peruse the docs.
>
> Bruce
>
> On Wed, Feb 7, 2018 at 10:11 AM, Bruce Snyder 
> wrote:
>
> > I'm sorry about the long delays in getting the official export from
> > Confluence, but it took this long to get some resolution on the issue.
> >
> > I now have a full HTML export from Confluence with the exception of the
> > Navigation page. You can grab the zip file of the HTML at the following
> URL:
> >
> > https://drive.google.com/file/d/1qoTC9KMw8oIzGWwBW1X-
> > oDtZxt8mFZlX/view?usp=sharing
> >
> > Bruce
> >
> > On Wed, Feb 7, 2018 at 10:06 AM, Bruce Snyder 
> > wrote:
> >
> >> +1
> >>
> >> Bruce
> >>
> >> On Sat, Feb 3, 2018 at 10:30 AM, Michael André Pearce <
> >> michael.andre.pea...@me.com> wrote:
> >>
> >>> Hi All,
> >>>
> >>> It’s been a bit quiet on the front of this effort.
> >>>
> >>> I’d like to bump this a bit to get some feedback on the current
> >>> examples, and try agree a plan going forwards and spread the work.
> >>>
> >>> I was speaking with Martyn the other week and we think maybe a brief
> >>> webex to demo what’s been done so far and then discuss.
> >>> Martyn’s offered he can host this using his bluejeans account (thanks)
> >>>
> >>> We are thinking of organising this for the week of 19th Feb.
> >>>
> >>> Any specific people who want to be involved can or cannot make? If not
> >>> I’ll sync up with Martyn to agree and then post a time and date.
> >>>
> >>> Cheers
> >>> Mike
> >>>
> >>>
> >>>
> >>> Sent from my iPhone
> >>>
> >>> > On 20 Dec 2017, at 01:26, Michael André Pearce <
> >>> michael.andre.pea...@me.com> wrote:
> >>> >
> >>> > Just FYI have sent a PR with a link to my branch of this export now
> in
> >>> a GitBook form still needs a lot of TLC but have tried to get a large
> bulk
> >>> done. To provide some skeleton for 5.x documents.
> >>> >
> >>> >
> >>> > Sent from my iPhone
> >>> >
> >>> >> On 18 Dec 2017, at 20:26, Michael André Pearce <
> >>> michael.andre.pea...@me.com> wrote:
> >>> >>
> >>> >> Yeah, unfortunately the tool i found wanted just html it blew up
> when
> >>> trying to use modified.
> >>> >>
> >>> >> Like wise there was a couple of pages it couldn’t convert due to a
> >>> css file on import issue but this wasn’t that many.
> >>> >>
> >>> >> Sent from my iPhone
> >>> >>
> >>> >>> On 18 Dec 2017, at 19:15, Bruce Snyder 
> >>> wrote:
> >>> >>>
> >>> >>> Nice job, based on my spot check of a handful of files, it looks
> much
> >>> >>> better. But we will still need to manually fix all the valid
> tables.
> >>> >>>
> >>> >>> Have you had a chance to look at the other branches that Dan Kulp
> >>> provided?
> >>> >>>
> >>> >>> Bruce
> >>> >>>
> >>> >>> On Mon, Dec 18, 2017 at 10:59 AM, Michael André Pearce <
> >>> >>> michael.andre.pea...@me.com> wrote:
> >>> >>>
> >>>  I’ve had some luck auto generating MD files.
> >>> 
> >>>  Needs some cleanup which probably the worst can be bash scripted.
> >>> 
> >>>  Have sent a PR back to the activemq-web on github for others to
> see.
> >>> 
> >>>  Mike
> >>> 
> >>>  Sent from my iPhone
> >>> 
> >>> > On 14 Dec 2017, at 16:31, Bruce Snyder 
> >>> wrote:
> >>> >
> >>> > Thanks, Dan. So far I only see the body.storage branch (the
> others
> >>> should
> >>> > propagate in time). But I see that it's already more
> comprehensive
> >>> than
> >>>  the
> >>> > HTML that I pushed because it contains all the directories. We
> >>> should
> >>> > probably wipe out the master branch and choose one of yours as
> the
> >>> new
> >>> > master branch.
> >>> >
> >>> > Bruce
> >>> >
> >>> >> On Thu, Dec 14, 2017 at 7:56 AM, Daniel Kulp 

Re: Website Discussion

[Martyn Taylor]

Cheers Michael,

Here's the link to the bluejeans session: https://bluejeans.com/6206782166

You may need to install the bluejeans app or browser plugin.  Please see:
https://www.bluejeans.com/downloads for details.

See you all in a few hours.

Thanks

On Wed, Mar 7, 2018 at 3:50 PM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> Just a reminder to all we will meeting up tonight.
>
> Martyn could you share the link?
>
> Sent from my iPhone
>
> > On 1 Mar 2018, at 10:34, Martyn Taylor <mtay...@redhat.com> wrote:
> >
> > OK, how about Wednesday same time?
> >
> > On Thu, Mar 1, 2018 at 5:24 AM, Michael André Pearce <
> > michael.andre.pea...@me.com> wrote:
> >
> >> @Martyn,
> >>
> >> I’m happy if we move this to Tuesday or Wednesday same time to better
> suit
> >> Clebert.
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On 28 Feb 2018, at 14:49, Clebert Suconic <clebert.suco...@gmail.com>
> >> wrote:
> >>>
> >>> I won't be able to do march 5th... I have a personal appointment that
> >>> I can't move at all... (government stuff) and I really want to
> >>> participate (at least listening). Can you move a day?
> >>>
> >>>> On Tue, Feb 27, 2018 at 1:25 PM, Martyn Taylor <mtay...@redhat.com>
> >> wrote:
> >>>> All,
> >>>>
> >>>> I wanted to pick up the website discussion again since it seems to
> have
> >>>> stalled.  The last conversation we had was around us setting up a
> video
> >>>> call or hackathon to get the ball rolling.  I had a conversation with
> >>>> Michael Pearce earlier in the week who's put together a potential site
> >> map
> >>>> as well as providing some initial work towards moving towards a Jekyll
> >>>> based approach.
> >>>>
> >>>> Are people still interested in a video discussion?  I propose we use
> the
> >>>> time to go over the new site design and allocate out some initial
> tasks
> >> to
> >>>> get the ball rolling.
> >>>>
> >>>> For those interested how about Monday 5th March, 20:00 UTC?
> >>>>
> >>>> Cheers
> >>>> Martyn
> >>>
> >>>
> >>>
> >>> --
> >>> Clebert Suconic
> >>
>

Re: Website Discussion

[Martyn Taylor]

OK, how about Wednesday same time?

On Thu, Mar 1, 2018 at 5:24 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> @Martyn,
>
> I’m happy if we move this to Tuesday or Wednesday same time to better suit
> Clebert.
>
>
>
> Sent from my iPhone
>
> > On 28 Feb 2018, at 14:49, Clebert Suconic <clebert.suco...@gmail.com>
> wrote:
> >
> > I won't be able to do march 5th... I have a personal appointment that
> > I can't move at all... (government stuff) and I really want to
> > participate (at least listening). Can you move a day?
> >
> >> On Tue, Feb 27, 2018 at 1:25 PM, Martyn Taylor <mtay...@redhat.com>
> wrote:
> >> All,
> >>
> >> I wanted to pick up the website discussion again since it seems to have
> >> stalled.  The last conversation we had was around us setting up a video
> >> call or hackathon to get the ball rolling.  I had a conversation with
> >> Michael Pearce earlier in the week who's put together a potential site
> map
> >> as well as providing some initial work towards moving towards a Jekyll
> >> based approach.
> >>
> >> Are people still interested in a video discussion?  I propose we use the
> >> time to go over the new site design and allocate out some initial tasks
> to
> >> get the ball rolling.
> >>
> >> For those interested how about Monday 5th March, 20:00 UTC?
> >>
> >> Cheers
> >> Martyn
> >
> >
> >
> > --
> > Clebert Suconic
>

Website Discussion

[Martyn Taylor]

All,

I wanted to pick up the website discussion again since it seems to have
stalled.  The last conversation we had was around us setting up a video
call or hackathon to get the ball rolling.  I had a conversation with
Michael Pearce earlier in the week who's put together a potential site map
as well as providing some initial work towards moving towards a Jekyll
based approach.

Are people still interested in a video discussion?  I propose we use the
time to go over the new site design and allocate out some initial tasks to
get the ball rolling.

For those interested how about Monday 5th March, 20:00 UTC?

Cheers
Martyn

[ANNOUNCE] CVE-2017-12174: Memory exhaustion via UDP and JGroups discovery

[Martyn Taylor]

CVE-2017-12174: Memory exhaustion via UDP and JGroups discovery

Severity: High

Vendor: The Apache Software Foundation

Versions Affected: 1.0.0, 1.1.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.5.1,
1.5.2, 1.5.3, 1.5.4, 1.5.5, 2.0.0, 2.1.0, 2.2.0, 2.3.0

Description:

If an Apache Artemis broker is configured with discovery enabled (either
UDP or JGroups), on receiving of a packet over a discovery endpoint, Apache
Artemis will attempt to decode the packet and as part of it an encoded
simple string.  The first four bytes of the encoded simple string represent
it's length.  During the decoding process Apache Artemis will create a byte
array of the same length.  It is possible therefore to send a manipulated
packet to Apache Artemis with a very large integer in the first four bytes
of the simple string encoding.  Upon receiving the packet the broker will
attempt to allocate a byte array of this large size.  This could result in
heap memory exhaustion, full GC or in the worst case an unrecoverable
OutOfMemoryError, resulting in loss of service.

Mitigation: Upgrade to Apache Artemis 1.5.6 or 2.4.0

Credit: This issue was discovered by Bharti Kundal of Red Hat Inc.

[ANNOUNCE] Apache Artemis 1.5.6

[Martyn Taylor]

All,

I am extremely pleased to announce the release of Apache Artemis 1.5.6

This 1.5.6  patch release contains the following fix:
https://issues.apache.org/jira/browse/ARTEMIS-1482

The project website for Apache Artemis has been updated include this
release and can be found here:
http://activemq.apache.org/artemis/

API and User documentation can be found here:
https://activemq.apache.org/artemis/docs.html

Regards
Martyn

Re: [DISCUSS] Adding Derby as a dependency

[Martyn Taylor]

Michael,

I think all Clebert is suggesting here is to have something that works out
the box to demonstrate the JDBC store.  Derby is a good candidate as it can
work in memory, and we it in a lot in our tests.  I've actually not talked
to Clebert about this, so he can confirm/deny if this was his intent, but I
don't see this being related to maintaining a connector service
implementation?  The only Derby specific thing here would be to ship the
lib as part of the distro and to configure a JDBC URL.  I guess we could
ask for a JDBC URL as part of the prompt, and tell the user to drop the lib
on the class path, but having a quick and easy way to set up and test
Artemis + JDBC sounds like a UX win to me.

Cheers







On Mon, Jan 15, 2018 at 7:24 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> Well it kind of is.
>
> are we then saying if a third party lib in this case Derby DB implements
> an interface that artemis provides in this case JDBC in the other case
> ConnectorService we are happy to depend on it and ship it with artemis?
>
> I really don’t want to upset or annoy you but at the same time I really do
> want an even playing field.
>
> As I already said I’m happy for artemis to have these. I think if someone
> is willing to support it let it be there. If it ends up being unsupportable
> remove it. Though that wasn’t the outcome from the last discussion.
>
> I really do think we need to have clear rules on this. That are generic
> about any component, for anyone.
>
> eg if a component lies without someone maintaining then after 6months it
> goes to inactive, if still after a year no one steps in it gets removed and
> moves to an attic.
>
>
>
> Sent from my iPhone
>
> > On 15 Jan 2018, at 02:14, Clebert Suconic 
> wrote:
> >
> > That’s different. We are not implementing JDBC here.
> >
> >
> > We can still provide a pluggavle interface and have the feature you wrote
> > plugging into artemis.  Even adding examples with dependencies towards
> it.
> > I think it was agreed back then.
> >
> >
> > That’s a different discussion from here though.
> >
> > On Sun, Jan 14, 2018 at 5:26 PM Michael André Pearce <
> > michael.andre.pea...@me.com> wrote:
> >
> >> Yes. And JDBC the pluggable interface point, JDBC is the api. This is
> just
> >> as ConnectorService is the pluggable interface that’s a feature.
> >>
> >> Either we have some provided implementations of the pluggable interfaces
> >> that exist within artemis or none at all.
> >>
> >> I really see this as no different. I’m happy for it to be there, but
> then
> >> I’d like this to applied in general, and to add the kafka
> ConnectorService.
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On 14 Jan 2018, at 21:05, Clebert Suconic 
> >> wrote:
> >>>
> >>> We already have jdnc as a feature.
> >>>
> >>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
> >>> michael.andre.pea...@me.com> wrote:
> >>>
>  My two cents is about consistency of either we do provide integrations
>  with other products out the box or not.
> 
>  If the arguments of people not wanting to add Kafka clients to the
> class
>  path for ability to link Artemis with Kafka, because it means having
> to
>  maintain it (see it’s thread for all discussion), I don’t see why
> >> linking
>  Artemis with a specific JDBC vendors product like Apache Derby is any
>  different here.
> 
>  Not that I’m against this, quite the contrary actually if I could add
>  Kafka integration, but I would like this ruling to be consistent.
> 
> 
> 
>  Sent from my iPhone
> 
> > On 12 Jan 2018, at 23:51, Clebert Suconic  >
>  wrote:
> >
> > I would like to add an option on artemis create to enable jdbc.
> >
> >
> > By default (if you don't provide any other configuration) it will use
> > derby by default on the properties.
> >
> >
> > And I wanted to add derby as a dependency on ./lib
> >
> >
> > Anyone against it?
> >
> >
> > so, you would do ./artemis create --jdbc
> >
> >
> > and it would configure derby as an option
> >
> >
> >
> > (JDBC is not encouraged.. the journal is the best option.. but same
> as
> > in ActiveMQ5, some people need it).
> >
> >
> >
> >
> > also: I'm trying to understand what I need to change on dep.xml under
> > artemis-distribution, but I can't make it to work... anyone can give
> > me a hand on that?
> >
> >
> >
> >
> > --
> > Clebert Suconic
> 
> >>> --
> >>> Clebert Suconic
> >>
> > --
> > Clebert Suconic
>

Re: Thoughts on refactoring the ActiveMQ website

[Martyn Taylor]

On Wed, Dec 13, 2017 at 4:00 AM, Bruce Snyder <bruce.sny...@gmail.com>
wrote:

> I had the following empty git repo created to hold the HTML from the
> current website:
>
> https://github.com/apache/activemq-web
>
> However, I have a conundrum -- content cannot be pushed directly to a
> Github ASF repo. Content can only be added via pull request but Github does
> not allow a pull request on an empty repo.
>
Bruce, have you tried pushing directly to the ASF repo.  i.e.  git://
git.apache.org/activemq-web.git

This is the workflow we currently use, we push directly to the ASF repo.
PRs are really only used for review and discussion.  I tried to push
directly this morning but looks like I don't have write permissions.

>
> Any ideas on how to get the HTML into the repo? I guess I could ask ASF
> Infra to push it.
>
> Bruce
>
> On Tue, Dec 12, 2017 at 8:17 PM, Bruce Snyder <bruce.sny...@gmail.com>
> wrote:
>
> > I'm going to address all the questions to me in this single reply.
> >
> > My original suggestion was that we export the HTML from Confluence,
> > convert to Markdown and put the Markdown and the images in a git repo.
> > Markdown is much easier to edit than raw HTML, especially the HTML
> exported
> > from Confluence (blech!). The idea was that we could use Jekyll + SAAS to
> > craft a new website. In fact, Michael Andre Pearce produced a mockup of
> > this using the Apache Metro website as an example (because it already
> makes
> > use of Jekyll + SAAS). It was enough to convince me that we should take
> > this path, so I started looking into doing a full, new export of
> Confluence
> > pages to HTML. If you have not seen Michael's mockup, you should really
> > take a look.
> >
> > So, I manually grabbed the raw HTML that is automagically exported from
> > Confluence and is hosting the current site that we see at
> > http://activemq.apache.org. I did some testing on it using text2html and
> > the conversion it does is pretty awful and would require a lot of hand
> work
> > to fix it. So, we discussed the point that there are 1600+ pages of HTML
> to
> > manually edit. But I later realized that it was only about 950 HTML pages
> > (from what I can tell so far).
> >
> > Then, Dan Kulp found a Confluence HTML to raw HTML converter built on top
> > of PanDoc. So, I have also been trying to export the HTML from Confluence
> > in order to try out the PanDoc converter (it works based on the
> Confluence
> > export function which is different from how the HTML is automagically
> > converted). Unfortunately, I am running into a NullPointerException from
> > Confluence. ASF Infra is telling me that the NPE is due to the CDATA in
> the
> > search function on the Navigation page and is suggesting that the
> solution
> > is to remove the Navigation page. The problem with this suggestion is
> that
> > it would fundamentally remove all the navigation on the right-hand side
> of
> > the site -- not what we want.
> >
> > I have also given some thought to the idea that removing the current site
> > will break all links to old site. This is something that cannot be
> > overlooked and must be prevented as we do not want to leave users who
> have
> > bookmarked a page high and dry. This is a fairly easy problem to solve
> this
> > using some mod_rewrite rules, the question is if ASF Infra is willing to
> > allow us to deploy such custom rules. This should be investigated when we
> > get to that point, but we are not there yet. First, we need to decide the
> > best path forward based on what I have described above in the preceding
> > paragraphs.
> >
> >
> > Bruce
> >
> > On Tue, Dec 12, 2017 at 11:39 AM, Martyn Taylor <mtay...@redhat.com>
> > wrote:
> >
> >> I was thinking there would be a single css file for all the pages.  But
> I
> >> haven't seen the files yet. Let's have a play around when Bruce pushes
> the
> >> export.
> >>
> >> Cheers
> >>
> >> On 12 Dec 2017 5:30 pm, "Michael André Pearce" <
> >> michael.andre.pea...@me.com>
> >> wrote:
> >>
> >> > What’s 1600 pages between friends
> >> >
> >> > I agree it will be easier to covert to md than to start doing css
> >> styles.
> >> > It’s all from a wiki anyhow so it’s can’t be that far off.
> >> >
> >> > It be good to get some samples (eg 50 pages) if not all just to try
> and
> >> > see what it is like.
> >> >
> >> >
> >> >
> &

Re: Thoughts on refactoring the ActiveMQ website

[Martyn Taylor]

I was thinking there would be a single css file for all the pages.  But I
haven't seen the files yet. Let's have a play around when Bruce pushes the
export.

Cheers

On 12 Dec 2017 5:30 pm, "Michael André Pearce" 
wrote:

> What’s 1600 pages between friends
>
> I agree it will be easier to covert to md than to start doing css styles.
> It’s all from a wiki anyhow so it’s can’t be that far off.
>
> It be good to get some samples (eg 50 pages) if not all just to try and
> see what it is like.
>
>
>
> On 12 Dec 2017, at 17:04, Clebert Suconic 
> wrote:
>
> >> Exporting to MD and creating a gitbook seems like a big task, I suspect
> any
> >> tool we use will cause a bunch of styling/content issues.
> >>
> >> At least initially, how about we just create a nice landing page that
> >> brings the ActiveMQ site and Artemis site together, and refresh/align
> the
> >> existing content with some CSS?
> >
> > I was just looking for the minimal effort task. I thought that
> > converting these pages into a doc would be easier than converting them
> > to another .css...
> >
> > if the conversion needed to be done anyways... I thought .md would be
> > easier and having a better final presentation.
>

Re: Thoughts on refactoring the ActiveMQ website

[Martyn Taylor]

On Tue, Dec 12, 2017 at 4:46 PM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> I agree, gitbook or similar would be a great way to manage the docs for
> 5.x.
>
Exporting to MD and creating a gitbook seems like a big task, I suspect any
tool we use will cause a bunch of styling/content issues.

At least initially, how about we just create a nice landing page that
brings the ActiveMQ site and Artemis site together, and refresh/align the
existing content with some CSS?

>
> @Bruce any luck with the extract of the current bits so can play around ?
>
> Sent from my iPhone
>
> > On 12 Dec 2017, at 16:19, Clebert Suconic <clebert.suco...@gmail.com>
> wrote:
> >
> > I wanted to emphasize an idea I spoke here:
> >
> >
> > Instead of converting the AMQ5 docs back into website format.. I think
> > it would be great to have the docs into a MD format so it would be
> > just a like a documentation format. gitbook convertible.
> >
> >
> > is there a requirement to keep the docs as website? we could think
> > differently here, right?
> >
> >
> >
> >
> >> On Fri, Dec 8, 2017 at 11:26 AM, Martyn Taylor <mtay...@redhat.com>
> wrote:
> >> Yes.  I had been chatting with Michael for a while about website
> updates.
> >> We had a bit of back and forth with this design.  Code is always a good
> >> place to start.  Cheers.
> >>
> >>> On Fri, Dec 8, 2017 at 2:16 PM, Bruce Snyder <bruce.sny...@gmail.com>
> wrote:
> >>>
> >>> I agree with the idea of making the site the landing page for all the
> >>> sub-projects within the overall ActiveMQ project.
> >>>
> >>> You should take a look at the message from Michael Andre Pearce to see
> his
> >>> mockup using the new logo, it's an excellent starting point for a
> >>> discussion. Be sure to follow the instructions in the BUILD.md:
> >>>
> >>> https://github.com/michaelandrepearce/activemq-
> >>> site/blob/master/site/BUILD.md
> >>>
> >>> Bruce
> >>>
> >>>> On Fri, Dec 8, 2017 at 3:48 AM, Martyn Taylor <mtay...@redhat.com>
> wrote:
> >>>>
> >>>> Some ideas to kick off design discussion.
> >>>>
> >>>> Really what I am trying to convey here is that ActiveMQ is the home
> of a
> >>>> more than just 5.x series.  And to have clear links to each project,
> >>>> clicking through would take you to landing page for the project.  This
> >>>> essentially would be the landing page for top level ActiveMQ.
> >>>>
> >>>> I realise the text in the message needs more work (it's also probably
> >>>> worth having a bit of info for each project on the landing page too).
> >>>>
> >>>> On Fri, Dec 8, 2017 at 1:23 AM, Bruce Snyder <bruce.sny...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> This looks great, Michael. It's also a great proof-of-concept, nice
> >>> work.
> >>>>> I
> >>>>> like the look of it, but I don't think we want to completely copy the
> >>>>> Metron site, so we will need to change it up.
> >>>>>
> >>>>> I'm working on getting the exported HTML from the ActiveMQ Confluence
> >>>>> space
> >>>>> and I will dump it into a new git repo.
> >>>>>
> >>>>> Bruce
> >>>>>
> >>>>> On Thu, Dec 7, 2017 at 9:55 AM, Michael André Pearce <
> >>>>> michael.andre.pea...@me.com> wrote:
> >>>>>
> >>>>>> Agree on jekyll.
> >>>>>>
> >>>>>> Here’s a sample I’ve mocked up with an activemq look and feel (and
> >>> much
> >>>>>> lighter) based around the new logo
> >>>>>>
> >>>>>> https://github.com/michaelandrepearce/activemq-
> site/tree/master/site
> >>>>>>
> >>>>>> I forked from metrons to get most of the bits like Jekyll etc which
> is
> >>>>>> already working.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Sent from my iPhone
> >>>>>>
> >>>>>>> On 7 Dec 2017, at 16:49, Bruce Snyder <bruce.sny.

Re: Thoughts on refactoring the ActiveMQ website

[Martyn Taylor]

Yes.  I had been chatting with Michael for a while about website updates.
We had a bit of back and forth with this design.  Code is always a good
place to start.  Cheers.

On Fri, Dec 8, 2017 at 2:16 PM, Bruce Snyder <bruce.sny...@gmail.com> wrote:

> I agree with the idea of making the site the landing page for all the
> sub-projects within the overall ActiveMQ project.
>
> You should take a look at the message from Michael Andre Pearce to see his
> mockup using the new logo, it's an excellent starting point for a
> discussion. Be sure to follow the instructions in the BUILD.md:
>
> https://github.com/michaelandrepearce/activemq-
> site/blob/master/site/BUILD.md
>
> Bruce
>
> On Fri, Dec 8, 2017 at 3:48 AM, Martyn Taylor <mtay...@redhat.com> wrote:
>
> > Some ideas to kick off design discussion.
> >
> > Really what I am trying to convey here is that ActiveMQ is the home of a
> > more than just 5.x series.  And to have clear links to each project,
> > clicking through would take you to landing page for the project.  This
> > essentially would be the landing page for top level ActiveMQ.
> >
> > I realise the text in the message needs more work (it's also probably
> > worth having a bit of info for each project on the landing page too).
> >
> > On Fri, Dec 8, 2017 at 1:23 AM, Bruce Snyder <bruce.sny...@gmail.com>
> > wrote:
> >
> >> This looks great, Michael. It's also a great proof-of-concept, nice
> work.
> >> I
> >> like the look of it, but I don't think we want to completely copy the
> >> Metron site, so we will need to change it up.
> >>
> >> I'm working on getting the exported HTML from the ActiveMQ Confluence
> >> space
> >> and I will dump it into a new git repo.
> >>
> >> Bruce
> >>
> >> On Thu, Dec 7, 2017 at 9:55 AM, Michael André Pearce <
> >> michael.andre.pea...@me.com> wrote:
> >>
> >> > Agree on jekyll.
> >> >
> >> > Here’s a sample I’ve mocked up with an activemq look and feel (and
> much
> >> > lighter) based around the new logo
> >> >
> >> > https://github.com/michaelandrepearce/activemq-site/tree/master/site
> >> >
> >> > I forked from metrons to get most of the bits like Jekyll etc which is
> >> > already working.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Sent from my iPhone
> >> >
> >> > > On 7 Dec 2017, at 16:49, Bruce Snyder <bruce.sny...@gmail.com>
> wrote:
> >> > >
> >> > > I would prefer to use Markdown with the Jekyll framework (
> >> > > https://jekyllrb.com/). Jekyll handles Markdown, it handles CSS
> (via
> >> > SASS)
> >> > > and it would allow the site to live in a git repo.
> >> > >
> >> > > Also, I found that other projects use Jekyll with great success,
> here
> >> is
> >> > > just one example in the Flink project:
> >> > >
> >> > > https://flink.apache.org/
> >> > >
> >> > > Nice looking site, clearly more modern and fully customizable.
> >> > >
> >> > > Bruce
> >> > >
> >> > > On Thu, Dec 7, 2017 at 9:42 AM, Clebert Suconic <
> >> > clebert.suco...@gmail.com>
> >> > > wrote:
> >> > >
> >> > >> +1
> >> > >>
> >> > >> I like the Markdown (or whatever easy format.. non xml based). We
> >> will
> >> > >> need to choose a framework for that. do you have anything in mind?
> >> > >>
> >> > >> I also think we should have a consistent look and feel.
> >> > >>
> >> > >>
> >> > >> I will be supportive on this...
> >> > >>
> >> > >>
> >> > >> First thing will be to have a framework chosen..
> >> > >> Second to have a github we collaborate...
> >> > >> Third.. maybe we could use one of those video calls to talk about
> >> how to
> >> > >> do it.
> >> > >>
> >> > >> On Wed, Dec 6, 2017 at 11:20 PM, Bruce Snyder <
> >> bruce.sny...@gmail.com>
> >> > >> wrote:
> >> > >>> Several opinions have been expressed recently that the ActiveMQ
> >> website
> >> > >>> needs some attention a

Re: Artemis Roadmap

[Martyn Taylor]

Are you specifically asking about the Core bridge?  Or clustering in
Artemis?

See the message-load-balancing policy on the cluster connection:
https://activemq.apache.org/artemis/docs/2.3.0/clusters.html

I think ON_DEMAND is what you're after.

Cheers

On Fri, Dec 8, 2017 at 12:38 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Clebert (or anyone else familiar with bridges),
>
> Does the core bridge in Artemis support demand based bridging?
>
> One feature I use in 5.x a lot to prevent unnecessary network traffic is to
> have consumers drive the message flow.  I.e. if you have multiple brokers
> bridged together it doesn't make much sense for broker A to send messages
> to broker B if there are no current consumers on broker B (especially for
> topic subscriptions or non-persistent messages)
>
> On Fri, Dec 8, 2017 at 7:20 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > https://github.com/apache/activemq-cli-tools has the main readme which
> > has some usage instructions.  Version 0.1.0 has been released already.
> >
> > On Fri, Dec 8, 2017 at 7:18 AM, Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> >> https://github.com/apache/activemq-cli-tools/tree/master/
> >> activemq-kahadb-exporter
> >>
> >> I created that tool a while back but it was my fault for not publicizing
> >> it more.  We can advertise it on the new web site and as part of the
> >> migration strategy.  It will export messages to XML from KahaDB and
> >> MultiKahaDB and can be filtered by destinations.  It will also compress
> the
> >> XML file if desired.  Artemis can then read in the messages from XML and
> >> write them to its store.  The nice thing about this is the data can be
> >> imported into any existing Artemis store (it doesn't have to be a brand
> new
> >> store).
> >>
> >> MessageId can not be retained right now because Artemis does not support
> >> OpenWire as a format for storing messages and the CORE ids are
> different.
> >> (It only supports CORE and AMQP I think)  The OpenWire messages in the
> >> KahaDB journal need to be converted to the CORE protocol in order to be
> >> imported into Artemis.  However, I believe that the original messageId
> is
> >> at least added as a property to the CORE message so it could be
> referenced
> >> later.
> >>
> >> Before creating this tool I initially looked at seeing if it made sense
> >> for Artemis to support KahaDB as a store however when I researched it
> was
> >> clear that the Artemis journal has a lot of advantages over KahaDB
> (faster,
> >> has compaction and paging, supports replication...to name a few) so it
> >> doesn't make sense to support it.
> >>
> >> On Fri, Dec 8, 2017 at 12:14 AM, Matt Pavlovich 
> >> wrote:
> >>
> >>> FWIW- An offline KahaDB export / Artemis Journal import tool was an
> idea
> >>> I added to the wiki page Bruce setup. Maintaining messageId I think is
> the
> >>> most critical element, and we could leave behind things like incomplete
> >>> transactions, message groups, etc.
> >>>
> >>>
> >>> On 12/7/17 10:00 PM, Clebert Suconic wrote:
> >>>
>  On Thu, Dec 7, 2017 at 9:57 PM Bruce Snyder 
>  wrote:
> 
>  I have suggested a similar tool that will read the ActiveMQ 5.x XML
> > configuration and convert it to an equivalent Artemis config. I think
> > this
> > would be easier to create than making Artemis read ActiveMQ 5.x
> > configs.
> >
> > For some reason I thought that Artemis supported KahaDB, but I'm not
> > sure
> > where I got this. I thought I read it somewhere. I wonder how
> > difficult it
> > would be to make Artemis support KahaDB as it is still the fastest
> > message
> > store, correct?
> >
> > Artemis journal  it’s faster.  We don’t currently support KahaDB.
> 
> 
> 
> 
>  Bruce
> >
> > On Thu, Dec 7, 2017 at 6:56 PM, Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > Thanks for getting this started Bruce.
> >>
> >> The migration portion is going to be tricky and we need to discuss
> >> more
> >>
> > how
> >
> >> to handle it.  Maybe we need to write a tool to help convert the old
> >> 5.x
> >> XML config to the Artemis config or update Artemis to be able to
> read
> >> a
> >>
> > 5.x
> >
> >> style config.  Obviously not everything will translate directly so
> >> that
> >> would need to be figured out.
> >>
> >> For the datastore we have a tool that will export KahaDB to XML that
> >> can
> >> then be imported by Artemis but this could probably be improved even
> >> more
> >> to make it more automated.
> >>
> >> On Wed, Dec 6, 2017 at 4:19 PM, Justin Bertram  >
> >> wrote:
> >>
> >> Thanks, Bruce!
> >>>
> >>>
> >>> Justin
> >>>
> >>> On Wed, 

Re: Thoughts on refactoring the ActiveMQ website

[Martyn Taylor]

Some ideas to kick off design discussion.

Really what I am trying to convey here is that ActiveMQ is the home of a
more than just 5.x series.  And to have clear links to each project,
clicking through would take you to landing page for the project.  This
essentially would be the landing page for top level ActiveMQ.

I realise the text in the message needs more work (it's also probably worth
having a bit of info for each project on the landing page too).

On Fri, Dec 8, 2017 at 1:23 AM, Bruce Snyder  wrote:

> This looks great, Michael. It's also a great proof-of-concept, nice work. I
> like the look of it, but I don't think we want to completely copy the
> Metron site, so we will need to change it up.
>
> I'm working on getting the exported HTML from the ActiveMQ Confluence space
> and I will dump it into a new git repo.
>
> Bruce
>
> On Thu, Dec 7, 2017 at 9:55 AM, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
>
> > Agree on jekyll.
> >
> > Here’s a sample I’ve mocked up with an activemq look and feel (and much
> > lighter) based around the new logo
> >
> > https://github.com/michaelandrepearce/activemq-site/tree/master/site
> >
> > I forked from metrons to get most of the bits like Jekyll etc which is
> > already working.
> >
> >
> >
> >
> >
> >
> > Sent from my iPhone
> >
> > > On 7 Dec 2017, at 16:49, Bruce Snyder  wrote:
> > >
> > > I would prefer to use Markdown with the Jekyll framework (
> > > https://jekyllrb.com/). Jekyll handles Markdown, it handles CSS (via
> > SASS)
> > > and it would allow the site to live in a git repo.
> > >
> > > Also, I found that other projects use Jekyll with great success, here
> is
> > > just one example in the Flink project:
> > >
> > > https://flink.apache.org/
> > >
> > > Nice looking site, clearly more modern and fully customizable.
> > >
> > > Bruce
> > >
> > > On Thu, Dec 7, 2017 at 9:42 AM, Clebert Suconic <
> > clebert.suco...@gmail.com>
> > > wrote:
> > >
> > >> +1
> > >>
> > >> I like the Markdown (or whatever easy format.. non xml based). We will
> > >> need to choose a framework for that. do you have anything in mind?
> > >>
> > >> I also think we should have a consistent look and feel.
> > >>
> > >>
> > >> I will be supportive on this...
> > >>
> > >>
> > >> First thing will be to have a framework chosen..
> > >> Second to have a github we collaborate...
> > >> Third.. maybe we could use one of those video calls to talk about how
> to
> > >> do it.
> > >>
> > >> On Wed, Dec 6, 2017 at 11:20 PM, Bruce Snyder  >
> > >> wrote:
> > >>> Several opinions have been expressed recently that the ActiveMQ
> website
> > >>> needs some attention and that Artemis should be made more prominent.
> > I'd
> > >>> like to discuss some ideas to see what we could achieve on this
> topic.
> > >>>
> > >>> If we are going to make Artemis more prominent, the first concern I
> > >>> identified is that the ActiveMQ website and the Artemis website are
> > >>> authored differently. The ActiveMQ website is authored in the
> > Confluence
> > >>> wiki and exported to HTML automagically whereas the Artemis website
> is
> > >>> authored in raw HTML. As a result, the two sites have a very
> different
> > >> look
> > >>> and feel to them. This presents some challenges to using the content
> > >>> between the two.
> > >>>
> > >>> But this presents other questions -- do we want the two sites to look
> > >>> similar or different? When someone looks at Artemis content, do we
> want
> > >> the
> > >>> user to immediately know that they are looking at ActiveMQ content
> vs.
> > >>> Artemis based content solely due to the look and feel of the site?
> > Should
> > >>> there even be two different sites?
> > >>>
> > >>> I would prefer to have the site authored in a language that is easier
> > to
> > >>> write than HTML (such as Markdown). I would also like the files
> > >> comprising
> > >>> the site to live in a git repo. To give the site a modern look and
> feel
> > >>> means using CSS (e.g., SASS, etc.). All these things can be achieved
> > >> using
> > >>> Jekyll, but first we would need to convert the raw HTML files to
> > Mardown
> > >> to
> > >>> put in git. I have experimented with some tools to convert HTML to
> > >> Markdown
> > >>> and they are less than ideal. Does anyone have any experience with
> > this?
> > >>>
> > >>> Sorry for the rambling. Anyone else interested to help tackle this
> > thorny
> > >>> set of issues?
> > >>>
> > >>> Bruce
> > >>>
> > >>> --
> > >>> perl -e 'print
> > >>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > );'
> > >>>
> > >>> ActiveMQ in Action: http://bit.ly/2je6cQ
> > >>> Blog: http://bsnyder.org/ 
> > >>> Twitter: http://twitter.com/brucesnyder
> > >>
> > >>
> > >>
> > >> --
> > >> Clebert Suconic
> > >>
> > >
> > >
> > >
> > > --
> > > perl -e 'print
> > > 

Re: [DISCUSS] Video call on ActiveMQ Artemis

[Martyn Taylor]

Nice idea Clebert.  I'd be happy to jump on and help out.

On Thu, Dec 7, 2017 at 4:20 PM, Matt Pavlovich  wrote:

> Clebert-
>
> I think this is a great idea. I really appreciated when you did this for
> me in the past. It was informative and helped me clarify my questions on
> feature gaps.
>
> -Matt
>
>
> On 12/7/17 9:55 AM, Clebert Suconic wrote:
>
>> Trying to be more positive here... ;)
>>
>> Would there be anyone interested on having a walk through on Artemis
>> Codebase.. how things works, hacking time... questions
>>
>> we could record it.. and post it online for a later view.
>>
>>
>> (we would focus on hacking and coding).
>>
>>
>>
>> Maybe, we could make this more often afterwards...
>>
>>
>> ... you will deal with my accent.. but I speak Java and some level of
>> C well :) that's enough
>>
>>
>> I would be able to put something together on Dec-18th... if that
>> doesn't work.. we could do next year.
>>
>>
>

Re: Thoughts on refactoring the ActiveMQ website

[Martyn Taylor]

Bruce, could you take what you have and put it up somewhere, perhaps in Git
so we can take a look?  Cheers.

On Thu, Dec 7, 2017 at 4:39 PM, Bruce Snyder  wrote:

> I have poked through some of the exported HTML pages from Confluence and
> there is so much cruft in there. E.g., large amounts of content wrapped in
> tables -- blech! I've also experimented with the text2html Python script
> and it does not convert these HTML files to Markdown very well, even if I
> skip tables. If we were to resort to hacking the HTML by hand to convert to
> Markdown, this is a *tremendous* amount of work. I grabbed the HTML, got
> rid of the duplicates that I saw and I still have 1600+ files.
>
> Bruce
>
> On Thu, Dec 7, 2017 at 9:26 AM, Matt Pavlovich  wrote:
>
> > If we can settle on a target format, I'd be up for dedicating time for a
> > hack-a-thon to just blaze through it. While painful, I believe we could
> get
> > it done quickly.
> >
> >
> >
> > On 12/6/17 10:20 PM, Bruce Snyder wrote:
> >
> >> Several opinions have been expressed recently that the ActiveMQ website
> >> needs some attention and that Artemis should be made more prominent. I'd
> >> like to discuss some ideas to see what we could achieve on this topic.
> >>
> >> If we are going to make Artemis more prominent, the first concern I
> >> identified is that the ActiveMQ website and the Artemis website are
> >> authored differently. The ActiveMQ website is authored in the Confluence
> >> wiki and exported to HTML automagically whereas the Artemis website is
> >> authored in raw HTML. As a result, the two sites have a very different
> >> look
> >> and feel to them. This presents some challenges to using the content
> >> between the two.
> >>
> >> But this presents other questions -- do we want the two sites to look
> >> similar or different? When someone looks at Artemis content, do we want
> >> the
> >> user to immediately know that they are looking at ActiveMQ content vs.
> >> Artemis based content solely due to the look and feel of the site?
> Should
> >> there even be two different sites?
> >>
> >> I would prefer to have the site authored in a language that is easier to
> >> write than HTML (such as Markdown). I would also like the files
> comprising
> >> the site to live in a git repo. To give the site a modern look and feel
> >> means using CSS (e.g., SASS, etc.). All these things can be achieved
> using
> >> Jekyll, but first we would need to convert the raw HTML files to Mardown
> >> to
> >> put in git. I have experimented with some tools to convert HTML to
> >> Markdown
> >> and they are less than ideal. Does anyone have any experience with this?
> >>
> >> Sorry for the rambling. Anyone else interested to help tackle this
> thorny
> >> set of issues?
> >>
> >> Bruce
> >>
> >>
> >
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bsnyder.org/ 
> Twitter: http://twitter.com/brucesnyder
>

Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6

[Martyn Taylor]

You continue to make more accusations, justifying yourself by accusing me
of being disingenuous.  These statements are just plain ignorant.  They
don't warrant a sensible response.

On Thu, Dec 7, 2017 at 2:12 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote:

> Martyn, you continue to misrepresent things.


> When we say RH on this thread it's pretty clear what it means. It was said
> before, we prefer to use this term to refer to a group that does have an
> agenda.

There are a few people who refuse to have conversations that ignore the
> elephant in the room.
>
> So, RH. I have nothing but respect for RedHat Software, Inc. I have
> friends over there, I know its culture, I was invited to some of its
> events, I *recommend* some of its products. Great company, friendly to open
> source, sponsor of the ASF.
>
> The RH clique in this thread refers to a group of people who, in my
> experience, are pushing an agenda. You claim that Artemis has fantastic
> technical merits. Fine. In the open source world, pay attention, value is
> given by adoption. Not by marketing materials, not by what managers say,
> *adoption*! ActiveMQ proved that, Camel did, Karaf did, CXF did. Heck,
> HTTPD did, Hadoop+Spark big data ecosystem, Maven, they all did, by getting
> adoption.
>
> HornetQ/Artemis has its chance, it's on equal footing. All this
> conversation points to a belief of the said clique that lives in an echo
> chamber that the *only* way to get adoption for Artemis is to steal the
> ActiveMQ name, buy replacing it. The only tool said clique has (and had) is
> overwhelming veto power in the PMC (Bruce mentioned it yesterday that
> technically the vote could pass, but he knows very well what would happen
> next). I asked you, and the -1s got reversed in an amusing way, if you want
> to grow Artemis inside or outside the ActiveMQ community. So you don't want
> to go TLP (I expected that) because like I was told in the past what you
> want is the ActiveMQ brand. And the more sad reason for that (I know
> outraged replies will follow), is that the issue is you promising something
> to your managers and thy bought into your ideas the hinge on stealing
> (basically) ActiveMQ. It's not RedHat Software, Inc's fault, it's all on
> you. And now you're in a bind. Even scarier is that the market, see AWS
> seems, to validate the value of ActiveMQ (the real one, 5.x).
>
> So, I dare you to prove me wrong, and prove the Artemis value by
> increasing adoption. Bonus points for doing it without abusing the ActiveMQ
> brand. Or you can try abusing of your voting power. But you'd gain more
> respect from building technology of undeniable value, like many of the ASF
> projects.
>
> Hadrian
>
>
>
>
> On 12/07/2017 06:26 AM, Martyn Taylor wrote:
>
>> To be quite frank, I'm offended by some of the accusations made in this
>> thread.
>>
>> After the last round of accusations of Red Hat are pushing through their
>> own agenda, I'm sad to see it happening again.  I continue to use my Red
>> Hat email address in public discussions, in my PR requests and review.
>> I've nothing to hide nor am I ashamed to be employed by a company like Red
>> Hat.  My legions lie with ActiveMQ and making the project and community a
>> better place.  I've put so much personal and emotional effort into this
>> project.  To have my votes and opinions abrogated just because I work for
>> a
>> certain company I find shocking and not at all democratic.
>>
>> Actually, looking back through this vote thread to the people who voted
>> +1,
>> who were accused of pushing an alternate agenda are actually the same
>> people who I see involved in the community on a day to day basis.  The
>> same
>> people fixing bugs, answering user questions and doing releases.  And
>> they're not all employed by the same company.
>>
>> If people want to vote -1 to this, fair enough you're entitled to your
>> vote
>> and I have no issue.  But, all this talk about companies pushing an
>> agenda,
>> seems to me to be a bit of a guise to detract away from the actual subject
>> in hand.  TBH, I am sick of hearing about it.
>>
>> I respect the result of the vote.
>>
>> I am -1 on the idea of making Artemis TLP.
>> I am +1  on Bruce's suggestion on creating a Roadmap.  I think this is
>> really what we need right now.
>>
>>
>> On Thu, Dec 7, 2017 at 3:41 AM, Michael André Pearce <
>> michael.andre.pea...@me.com> wrote:
>>
>> On the website front I’m happy to stick my hand up, giving it an overhaul
>>> and design inline with the new logo.
>>>
>>> Mike
>>>
>>> Sent

Re: [DISCUSS] Graduate Artemis as TLP

[Martyn Taylor]

-1.  I'm not even going to add weight to this discussion by giving a
reason.  I find the thread a ridiculous reaction to the vote email, in it
there are more inaccurate claims of the opinions of members of the
community.

On Thu, Dec 7, 2017 at 11:28 AM, Gary Tully  wrote:

> I don't agree with the premise of this discussion at all. It seems to be
> born out of a your replies to your self in an echo chamber.
>
> What are the adverse consequences in providing a robust migration path for
> 5.x users to activemq 6 *within* the ActiveMQ project?
>
> The preceding vote did not have an implicit "now" in the title, it was
> future focused.
> In hind sight the title could have been:
>
>  "When it's ready, Artemis becomes ActiveMQ 6"
>
> I think there is consensus forming around that.
>
> On Thu, 7 Dec 2017 at 02:05 Hadrian Zbarcea  wrote:
>
> > Since Artemis has a kernel of developers had a few releases, and
> > hard-core Artemis believers want to be in control of their own destiny
> > and they believe the project can be sustained on its own merits and have
> > it's own awesome site, I propose that Artemis form its own PMC and start
> > a vote to graduate as TLP.
> >
> > Thoughts?
> > Hadrian
> >
> >
> >
>

Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6

[Martyn Taylor]

To be quite frank, I'm offended by some of the accusations made in this
thread.

After the last round of accusations of Red Hat are pushing through their
own agenda, I'm sad to see it happening again.  I continue to use my Red
Hat email address in public discussions, in my PR requests and review.
I've nothing to hide nor am I ashamed to be employed by a company like Red
Hat.  My legions lie with ActiveMQ and making the project and community a
better place.  I've put so much personal and emotional effort into this
project.  To have my votes and opinions abrogated just because I work for a
certain company I find shocking and not at all democratic.

Actually, looking back through this vote thread to the people who voted +1,
who were accused of pushing an alternate agenda are actually the same
people who I see involved in the community on a day to day basis.  The same
people fixing bugs, answering user questions and doing releases.  And
they're not all employed by the same company.

If people want to vote -1 to this, fair enough you're entitled to your vote
and I have no issue.  But, all this talk about companies pushing an agenda,
seems to me to be a bit of a guise to detract away from the actual subject
in hand.  TBH, I am sick of hearing about it.

I respect the result of the vote.

I am -1 on the idea of making Artemis TLP.
I am +1  on Bruce's suggestion on creating a Roadmap.  I think this is
really what we need right now.


On Thu, Dec 7, 2017 at 3:41 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> On the website front I’m happy to stick my hand up, giving it an overhaul
> and design inline with the new logo.
>
> Mike
>
> Sent from my iPhone
>
> > On 6 Dec 2017, at 22:57, Bruce Snyder  wrote:
> >
> > I agree that the website needs an overhaul and I'm interested to take on
> > this task. I also agree that Artemis should somehow be made more
> prominent
> > on the website, but how to do this is more debatable. I will start a
> > separate discussion around this.
> >
> > More discussions on the dev list is *always* a good thing.
> >
> > Bruce
> >
> > On Wed, Dec 6, 2017 at 3:43 PM, Clebert Suconic <
> clebert.suco...@gmail.com>
> > wrote:
> >
> >> Ok... so, consider this a CANCEL on this vote...
> >>
> >>
> >>
> >> I think we have things settled.. and some positive factors from this
> >> thread:
> >>
> >> - All agreed to make Artemis more prominent on the website.
> >> - Refactor the website... like.. now...  with Artemis being brought
> >> forward.. (the website needs a facelift regardless)
> >>   ... any volunteers here?
> >>   ... we will need a discuss here... Honestly I don't like the confluent
> >> wiki.
> >> - Have more discussions on the dev list
> >>
> >
> >
> >
> > --
> > perl -e 'print
> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E >
> > ActiveMQ in Action: http://bit.ly/2je6cQ
> > Blog: http://bsnyder.org/ 
> > Twitter: http://twitter.com/brucesnyder
>

Re: Thoughts on refactoring the ActiveMQ website

[Martyn Taylor]

Thanks for starting this thread.

On Thu, Dec 7, 2017 at 4:20 AM, Bruce Snyder  wrote:

> Several opinions have been expressed recently that the ActiveMQ website
> needs some attention and that Artemis should be made more prominent. I'd
> like to discuss some ideas to see what we could achieve on this topic.
>
> If we are going to make Artemis more prominent, the first concern I
> identified is that the ActiveMQ website and the Artemis website are
> authored differently. The ActiveMQ website is authored in the Confluence
> wiki and exported to HTML automagically whereas the Artemis website is
> authored in raw HTML. As a result, the two sites have a very different look
> and feel to them. This presents some challenges to using the content
> between the two.
>
> But this presents other questions -- do we want the two sites to look
> similar or different?

I would prefer the site to have a consistent look and feel.

> When someone looks at Artemis content, do we want the
> user to immediately know that they are looking at ActiveMQ content vs.
> Artemis based content solely due to the look and feel of the site

Should
> there even be two different sites?
>
I think we need to direct users to a single place for all things ActiveMQ,
Artemis being part of that.  And have a clear message on the home page
about the projects and how things are related.  We could then offer links
to Artemis, ActiveMQ or NMS client etc..

>
> I would prefer to have the site authored in a language that is easier to
> write than HTML (such as Markdown). I would also like the files comprising
> the site to live in a git repo. To give the site a modern look and feel
> means using CSS (e.g., SASS, etc.). All these things can be achieved using
> Jekyll, but first we would need to convert the raw HTML files to Mardown to
> put in git.

Don't care too much about the specific technologies used, but it would be
good to have this managed in Git so we can follow workflows used for other
projects.

> I have experimented with some tools to convert HTML to Markdown
> and they are less than ideal. Does anyone have any experience with this?
>
> Sorry for the rambling. Anyone else interested to help tackle this thorny
> set of issues?
>
I'm happy to get involved and do some of the work here.

The current website is almost embarrassing, let's get it fixed up :)

>
> Bruce
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bsnyder.org/ 
> Twitter: http://twitter.com/brucesnyder
>

Re: [DISCUSS] Move PR discussions to another list...

[Martyn Taylor]

+0.  I manage just fine using filters and also use the dev list to conduct
PR discussions.  I am not against the idea of using separate lists, if
others think it'd be useful.

On Thu, Dec 7, 2017 at 1:08 AM, Clebert Suconic 
wrote:

> It seems to me that we should then move it... people who need can
> still follow up... it would be a nice compromise for everybody...
>
> Would we be ok to move github comments to the commit list? ( I think
> that't the list we should use).
>
> On Wed, Dec 6, 2017 at 7:45 PM, John D. Ament 
> wrote:
> > From the VP Incubator's standpoint (as well as infrequent ActiveMQ
> > contributor)
> >
> > I see a lot of new projects coming on board, starting off with a dev@
> list,
> > getting the notifications there.  With tools like github, since you're
> > getting the notification personally (when it involves you) as well as on
> > list, it becomes noise.  You have the option to subscribe where you want
> to
> > on github, and as a result many of those podlings eventually create a
> > separate notifications@ or commits@ list that receive the messages.  So
> > there is actual precedence for creating lists dedicated to those
> messages.
> >
> > It satisfies all of the foundation level requirements (discussions on
> list,
> > archived) while giving developers clear separation of which lists do
> what.
> >
> > Since Artemis is a subproject, you may even want to entertain creating a
> > separate artemis-dev@activemq.a.o list for development discussions
> specific
> > to Artemis.
> >
> > John
> >
> > On Wed, Dec 6, 2017 at 6:05 PM Clebert Suconic <
> clebert.suco...@gmail.com>
> > wrote:
> >
> >> @Daniel: that's a general issue at apache.. not just activemq... just
> >> looked now.. it's the same pattern everywhere...
> >>
> >>
> >> It would be nice if we could fix this rule in apache... PRs is a new
> >> thing.. and the rules needs to be updated... how/where do we go to
> >> have a wider discussion?
> >>
> >> On Wed, Dec 6, 2017 at 5:51 PM, Daniel Kulp  wrote:
> >> > They are different though… A PR discussion is exactly that… a
> >> discussion.   If there are things in the PR discussions like code
> >> suggestions and back and forth about opinions on how something is done
> and
> >> such, they SHOULD be on the dev list as they are dev discussions.   The
> >> commit is more “final”.
> >> >
> >> > That is also the reason that the “reply-to” field on the commit list
> is
> >> the dev list.   If you reply to a commit, it’s starting a discussion
> which
> >> goes to the dev list. Thus, if we wanted to completely mimic the
> >> commits, it would be that the “Open PR” and “Close PR" emails would go
> to a
> >> different list, but any discussion/replys would go to the dev list.
>  I’m
> >> not sure that buys much.
> >> >
> >> > Dan
> >> >
> >> >
> >> >> On Dec 6, 2017, at 5:44 PM, Clebert Suconic <
> clebert.suco...@gmail.com>
> >> wrote:
> >> >>
> >> >> You could use the same argument to have committs being fed here...
> >> >> it's too noisy!
> >> >>
> >> >> On Wed, Dec 6, 2017 at 5:35 PM, Timothy Bish 
> >> wrote:
> >> >>> -1
> >> >>>
> >> >>> Unless PR discussions can exist on the dev list I'm against moving
> >> that to
> >> >>> another list as that is part of the development process.
> >> >>>
> >> >>>
> >> >>> On 12/06/2017 05:34 PM, Clebert Suconic wrote:
> >> 
> >>  in my view... and in my plan... going forward now I plan to make
> more
> >>  discussions on the dev list.. especially around this Roadmap idea.
> >> 
> >> 
> >>  What if:
> >> 
> >>  - We move github traffic to another list.. (commit perhaps)?
> >>  - We can still use github to talk about spot on issues.. such as..
> the
> >>  format here sucks... the logic here is not accurate.. etc.. etc...
> >>  which this is the kind of noise that's feeding this list like
> crazy.
> >>   . You could use the same argument to bring JIRA comments to
> the
> >>  dev list.. it would be too noise.. I believe that's been the case
> at
> >>  some point
> >> 
> >>  But if there is a meaningful discussion... then we would refer the
> >>  dev-list... just like as we do in other places. (JIRA, private
> list..
> >>  etc.. etc)
> >> 
> >> 
> >>  That seems a reasonable thing to me. It would help us to be more
> >>  active on the dev list.. which is what we need now.
> >> 
> >> 
> >>  On Wed, Dec 6, 2017 at 5:20 PM, jgenender 
> >> wrote:
> >> >
> >> > Daniel Kulp wrote
> >> >>
> >> >> I’m -0.5 on moving them.  PR’s (and the conversations in them)
> are
> >> part
> >> >> of
> >> >> the development process and should be on the dev list.
> >> >
> >> > But the deluge often loses the discussion which is why some
> projects
> >> have
> >> > commit lists.  This is the difference between projects that work
> 

Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6

[Martyn Taylor]

+1.

>From my understanding, this vote is outlining the intent going forward, not
necessarily the details of how we get there.  I agree there are some
discussions to be had over the details, e.g. what this might look and what
needs to be done in order to facilitate our existing user base.  But I
think we need a clear vision before we can set out a road map of how to get
there.

On Wed, Dec 6, 2017 at 7:08 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> Based on the Dev discussion linked I believe this vote was more making the
> direction and future clearer for users, its not deprecating overnight 5.x,
> but simply clearing up what is ActiveMQ 6 going to be.
>
>
> On your commends about JBoss.
>
> I don’t think vendor versions should come in here. Apache projects and its
> versions should have their own lifecycle not influenced by what vendors
> re-packing and supporting apache projects are doing. This is an Apache
> Project, NOT a RedHat/JBoss project.
>
> Many other apache products which have vendors releasing their own
> versions, such as:
>
> Apache Hadoop (HDFS) with Hortonwork, Cloudera, MAPR
> Apache Kafka with Confluent
> Apache Ignite with GridGain
>
> They all have versions that conflict and/or are different with the
> upstream Apache projects.
>
> On that note re your comment ""JBoss AMQ 6" is Apollo" whilst I’m not a
> RedHat person/employee so I cannot be an official source (I work for a
> company that uses both ActiveMQ as some of its message brokers), but from
> their documentation available publicly on their site, JBOSS AMQ 6 is based
> on ActiveMQ 5.X.
>
> Saying this and re-iterating my previous comment, Apache versioning should
> be agnostic to what vendors are versioning and shouldn’t come into this
> discussion IMO.
>
> On that note to the same cord, i think it may answer a little your
> question re adoption if RH are releasing their vendor product based on it
> switching from it seems 5.X to Artemis shows that the maturity/adoptions of
> Artemis, they would obviously have customers using it, and others
> transitioning from their previous version.
>
> Whilst on Adoption, I’m aware that:
>
> * Spring Framework already has support for ActiveMQ Artemis, its one of
> the options within Spring Boot, along side Rabbit, Kafka and ActiveMQ 5.X (
> https://docs.spring.io/spring-boot/docs/current/
> reference/html/boot-features-messaging.html)
> * WildFly is using it reading their docs (https://docs.jboss.org/
> author/display/WFLY10/Messaging+configuration)
> * Other open source projects are building / adopting on it:
>  * OpenIoE -> https://github.com/scorelab/OpenIoE
>  * Enmasse.io -> http://enmasse.io
>
> Cheers
> Mike
>
>
>
>
>
>
>
>
>
>
> > On 6 Dec 2017, at 03:51, artnaseef  wrote:
> >
> > -1  I think we need to slow down.
> >
> > While the referenced discussion opened the possibility of unifying on a
> > single broker, there's a lot more to discuss before that decision is
> made.
> > Naming Artemis as ActiveMQ 6 implies to the community that we are
> > deprecating AMQ 5 now.
> >
> > For example, the assertion that "I think all the features are covered at
> > this point" shows a lack of clarity itself.  If we were truly methodical,
> > then we would have a list of criteria needed for Artemis to take the name
> > ActiveMQ 6.
> >
> > ActiveMQ is an important asset to the communities it serves, and it
> deserves
> > the greatest of attention and care.
> >
> > Questions coming to mind for making this decision:
> > * What is the full list of features needed?
> > * How much adoption does Artemis have?
> > * How stable is Artemis?
> > * What features will be dropped?  Scheduler?  HTTP endpoints?  ...
> >
> > Just today I ran into the following bug the hard way:
> > https://issues.apache.org/jira/browse/ARTEMIS-1022.
> >
> > Notice it's still open after more than 8 months.  It impacts OpenWire
> > support, which is critical to me as we want the most straight-forward
> > transition for customers as possible.
> >
> > Please start to enumerate these points.
> >
> > BTW, on the confusion front, since "JBoss AMQ 6" is Apollo and "JBoss
> AMQ 7"
> > is Artemis, I think renaming Artemis to ActiveMQ 6 will create even more
> > confusion.
> >
> > ALSO - one big point.  This DEV list is hard to follow now thanks to the
> > vast majority of messages being commit messages, and while I 100% agree
> with
> > having this discussion on the DEV list, the PMC needs to be made aware of
> > these discussions and votes on the PMC list.
> >
> > I'll post the link there now.
> >
> >
> >
> >
> >
> > --
> > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-
> f2368404.html
>
>

Re: Contribute a properties-based SQL Provider

[Martyn Taylor]

Hi Jeff,

I think I much prefer this approach of keeping the database specific logic
(i.e. the SQL statements) separate from the implementation.  This would
allow us to have a pure JDBC API + SQL implementation, and adding support
for a new vendor would just be a case of dropping in a new properties
file.  I've taken a look at what you've done and I much prefer it to our
generic SQL provider implementation.

I'd still like to be able to extend the properties impl, as some vendors do
offer their own APIs to manage things like large objects, which I assume,
are highly optimised over the JDBC API.  How about we replace all our impls
(expect the postgres file impl) with what you have here and make the
properties based driver the default?  We can then override this with
implementations that use the optimised APIs by passing the driver class to
the config?  We still need to ensure that our connections are managed in
the same way, but other than that I think it should be relatively straight
forward.  Let me know if you need any help with this.

Nice work!
Martyn



On Thu, Nov 30, 2017 at 2:59 PM, Jeff Mesnil  wrote:

> Hi,
>
> We have integrated Artemis 1.x in WildFly application server with a
> different SQLProvider implementation to support Artemis JDBC store.
> The issue we had at the time with Artemis SQLProvider was that
> supporting a new databases required to add a new class to specify its
> specific JDBC statements and ultimately require new releases for each
> new DB we wanted to test & support.
>
> To circumvent this issue, we wrote a SQLProvider[1] to use for Artemis
> JDBC store that is using a Properties file[2] and a simple overridding
> mechanism to provide DB-specific statements.
> For example to support Oracle DB, Artemis mechanism required to write
> (and maintain) this class:
> https://github.com/apache/activemq-artemis/blob/master/
> artemis-jdbc-store/src/main/java/org/apache/activemq/
> artemis/jdbc/store/drivers/oracle/Oracle12CSQLProvider.java
>
> Using our property-based implementation, we only need to add 2 lines
> to the properties file:
>
> https://github.com/wildfly/wildfly/blob/master/feature-
> pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/
> messaging-activemq/main/database/journal-sql.properties#L43-L45
>
> When the SQLProvider will be queried for a SQL statement, it will
> first searched for a DB-specific dialect and falls back to a generic
> one else:
>
> https://github.com/wildfly/wildfly/blob/master/messaging-
> activemq/src/main/java/org/wildfly/extension/messaging/activemq/
> PropertySQLProviderFactory.java#L249
>
> The dialect itself is determined used DataSource properties and metadata:
>
> https://github.com/wildfly/wildfly/blob/master/messaging-
> activemq/src/main/java/org/wildfly/extension/messaging/activemq/
> PropertySQLProviderFactory.java#L85
>
> In addition, this properties file can be easily modified by users
> without requiring a new release to support another database.
>
> We have started development on WildFly 12 and I am looking to
> integrate Artemis 2.4.x.
> I don't want to have to maintain a 2nd implementation of the SQL
> provider in WildFly codebase and I really think that our
> properties-based approach is sounder than the current Artemis
> implementation.
>
> I'd like to propose to contribute back this properties-based SQL
> provider to Artemis codebase in replacement to its current
> implementation. I think this would be beneficial for Artemis as it
> would reduce the amount of work to support a new DB, reduce the number
> of classes for a better maintainability and, of course, ease the
> integration of Artemis into WildFly.
>
> What do you think?
>
> jeff
>
> [1] https://github.com/wildfly/wildfly/blob/master/messaging-
> activemq/src/main/java/org/wildfly/extension/messaging/activemq/
> PropertySQLProviderFactory.java
> [2] https://github.com/wildfly/wildfly/blob/master/feature-
> pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/
> messaging-activemq/main/database/journal-sql.properties
> --
> Jeff Mesnil
> jmes...@gmail.com
> http://jmesnil.net/weblog/
>

Re: [DISCUSS] AMQP Large Messages

[Martyn Taylor]

On Thu, Nov 16, 2017 at 2:01 PM, Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> On Thu, Nov 16, 2017 at 6:10 AM, Martyn Taylor <mtay...@redhat.com> wrote:
> > Clebert,
> >
> > We need to distinguish between streamed messages and large messages.  For
> > the basic large message case, i.e. a single large message sent to the
> > broker.  I agree with what you have here.
> >
> > Streamed large messages (i.e. messages that are received in chunks)
> allows
> > us to store the message without having to keep the whole thing in broker
> > memory.  This get's complicated with cross protocol as:
> >
> > 1. Not all protocols support streamed messages.
> Exactly.. right now in Stomp.. we read the whole body in memory before
> sending. Just like what is in master now for AMQP.
>
> > 2. Cross protocol may require message conversions
> Just like in Stomp... we read the whole message in memory
>
> >
> > Both 1. and 2. would likely mean that we'd likely need to read the whole
> > message into memory and I'm not sure we really want to do this?  It
> defeats
> > one of the main purposes of streamed messages.  (The others being saving
> > client memory and reducing the amount of data to resend on connection
> drop.)
>
> Most times the user will have no control over this. Say you sent a
> 100K + 1 byte over the configured limit, String messages in Core.  the
> client will stream it as it being large

This is why I think we need to distinguish between broker large messages
and streamed messages.  This configuration option is really for streaming
messages.  In our docs we talk about the ability to send messages that are
larger than the broker memory using streaming.  What happens if I do this
and try to consume it via STOMP or another protocol that doesn't support
streaming?

> .
>
>
> >
> > For 1. I wonder whether or not we want to support this at all, or if we
> do,
> > make it configurable.
> > For 2. Is it possible to transform the message via a stream?  If not then
> > perhaps we treat this as a raw bytes message?
>
> It is possible as I said.. I think it's a separate task. I may try to
> do it within this scope.
>
OK sounds good.

Re: [DISCUSS] AMQP Large Messages

[Martyn Taylor]

Clebert,

We need to distinguish between streamed messages and large messages.  For
the basic large message case, i.e. a single large message sent to the
broker.  I agree with what you have here.

Streamed large messages (i.e. messages that are received in chunks) allows
us to store the message without having to keep the whole thing in broker
memory.  This get's complicated with cross protocol as:

1. Not all protocols support streamed messages.
2. Cross protocol may require message conversions

Both 1. and 2. would likely mean that we'd likely need to read the whole
message into memory and I'm not sure we really want to do this?  It defeats
one of the main purposes of streamed messages.  (The others being saving
client memory and reducing the amount of data to resend on connection drop.)

For 1. I wonder whether or not we want to support this at all, or if we do,
make it configurable.
For 2. Is it possible to transform the message via a stream?  If not then
perhaps we treat this as a raw bytes message?

Cheers

On Wed, Nov 15, 2017 at 11:33 PM, Clebert Suconic  wrote:

> It would be possible... look at
> https://github.com/apache/activemq-artemis/pull/1655
>
> I will keep the same current semantic. That is.. you would read the
> whole body.. and convert in memory.
> That's because I wouldn't know how to convert the body without having
> it into memory.. for things like string reading.
>
> Possible to do it without using memory.. but not very practical at
> this point... we could make this a separate task.. to convert large
> messages without requiring full memory read.
>
>
>
> I would add a note to docs saying that large messages will be read
> into memory before converting protocol barriers.
>
> On Wed, Nov 15, 2017 at 6:24 PM, Michael André Pearce
>  wrote:
> > Looks good for AMQP to AMQP client.
> >
> > One question is in a poly protocol supported setup. Eg senders and
> receivers one uses Core and AMQP.
> >
> > It’s not clear if this should now be possible with the new
> LargeMessageBody abstraction you discuss.
> >
> > Cheers
> > Mike
> >
> > Sent from my iPhone
> >
> >> On 16 Nov 2017, at 02:10, Clebert Suconic 
> wrote:
> >>
> >> I am currently implementing Large Message support for AMQP Messages.
> >>
> >> There's currently no support for Large Messages in AMQP, although I
> >> have recently implemented a dum copy and convert, but if you send a
> >> large message, say with 1 G, the whole body would be read into memory
> >> before a conversion to AMQP.. what won't fit in most cases of course.
> >> (even so I can always make a case where it wouldn't fit).
> >>
> >> LargeMessages are always converted as Core currently. With this change
> >> they will be kept as AMQP all the way through, adding full support for
> >> large messages, which is nice!
> >>
> >>
> >> Anyway... the design I got so far is the following:
> >>
> >>
> >> - LargeServerMessageImpl will delegate its implementation to another
> >> class called LargeMessageBody
> >>
> >> - LargeMessageBody would then be used by AMQPMessage when incomplete
> >> messages are sent through the wire.
> >>
> >> - When sending messages on the server, I will use sender.send multiple
> >> times until the whole buffer is read. I'm not 100% sure qpid.Proton
> >> will work fine with that approach. I will start with that, and deal
> >> with further bugs if they come along.
> >>
> >>
> >> - When receiving messages on the server. Messages are marked as
> >> incomplete. So, I will create the file using the LargeMessageBody. on
> >> that case I will just use the current recv method we already have
> >> available on Proton multiple times. This seems to work fine already.
>
>
>
> --
> Clebert Suconic
>

Re: [HEADS-UP] 1.5.6 release in a week

[Martyn Taylor]

Hi Mohamed,

Yes, the 1.5.x client is compatible with 2.4.0.  There were previously a
couple of issues in the broker.  These have now been resolved.

Cheers
Martyn

On Wed, Nov 8, 2017 at 10:32 AM, Mohamed Badri  wrote:

> hi,
>
> after 2.4.0 release, is a 1.5.X still planned ?
>
> Wildfly 11 includes 1.5 branch.
> in order to get rid of artemis 1.5,
> is 1.5 client compatible with a 2.x standalone artemis server ?
>
> I had somme issues, in the past, while trying  to connec tto an artemis 2.x
> server
> using the embedded client from wildfly 10, which
> is an artemis 1.1.0.
>
> thanks a lot.
>
>
>
> On 26 September 2017 at 20:00, Clebert Suconic 
> wrote:
>
> > See the $subject.. I'm planning to make a 1.5.6 release in a week.
> >
> > I have just pushed many cherry-picks from master into 1.x branch...
> >
> > Even though we recommend 2.x for users.. I know there are a few users
> > still using the 1.x branch.. That update will be a nice maintenance
> > release for anyone still on that branch.
> >
> >
> >
> > --
> > Clebert Suconic
> >
>

Re: Twitter

[Martyn Taylor]

+1 from me

On Thu, Nov 2, 2017 at 12:43 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> I think lazy concensus is ok.  As long as no one has any objections I would
> think it's ok to move ahead with it under PMC control as Tim pointed out.
> But Tim is right that should give it 72 hours for people to see the thread
> and comment.
>
> On Wed, Nov 1, 2017 at 7:28 PM, Clebert Suconic  >
> wrote:
>
> > Do we a vote even for that? It seemed a no brainer.
> >
> > On Wed, Nov 1, 2017 at 6:56 PM Michael André Pearce <
> > michael.andre.pea...@me.com> wrote:
> >
> > > Should be deactivated now.
> > >
> > >
> > >
> > > > On 1 Nov 2017, at 22:51, Michael André Pearce <
> > > michael.andre.pea...@me.com> wrote:
> > > >
> > > > That would be my apologies on that i was setting up to make sure it
> > > would work. I didn’t realise the ramifications I will disable it whilst
> > we
> > > await the time to elapse.
> > > >
> > > > Please accept my apologies
> > > >
> > > >
> > > >
> > > > Sent from my iPhone
> > > >
> > > >>> On 1 Nov 2017, at 22:49, Timothy Bish  wrote:
> > > >>>
> > > >>> On 11/01/2017 06:40 PM, Michael André Pearce wrote:
> > > >>> Agreed PMC ultimately will have overall control.
> > > >>>
> > > >>> This is why the mail before about the “owner” account to be the
> PMC.
> > > >>>
> > > >>
> > > >> Problem being that there is now a "official" ActiveMQ twitter
> account
> > > that is not currently owned or controlled by the PMC that was created
> > from
> > > a discussion that did not give the standard 72 hours for discussion and
> > > either consensus or lazy consensus to occur.
> > > >>
> > > >>> Sent from my iPhone
> > > >>>
> > > > On 1 Nov 2017, at 22:24, Timothy Bish 
> wrote:
> > > >
> > > > On 11/01/2017 06:13 PM, Michael André Pearce wrote:
> > > > Also a shout out for committers and pmc, if you want to be added
> as
> > > we set this up we will need your twitter handles (I have some peoples
> but
> > > not all)
> > >  Ultimately the PMC needs to decide which committers would be given
> > > access as per the Apache social media policy.
> > > 
> > > > Cheers
> > > > Mike
> > > >
> > > > Sent from my iPhone
> > > >
> > > >> On 1 Nov 2017, at 22:11, Michael André Pearce <
> > > michael.andre.pea...@me.com> wrote:
> > > >>
> > > >> I have sent a mail to the PMC. But in the interest of being
> open,
> > > will share on the Dev mail list also.
> > > >>
> > > >> We are slowly setting this up to check all would work etc etc.
> > > >>
> > > >> We have set the “owner” account to the private pmc mail address
> as
> > > per Apache guidelines, it seems there might be some filter on the
> private
> > > mail list as it seems the verify email from twitter is not received.
> > > >>
> > > >> I have such asked for advice from the PMC.
> > > >>
> > > >> Incase anyone has done this for other Apache projects and have
> > some
> > > advice how they handled this or get the verify email, it is welcome.
> > > >>
> > > >> Cheers
> > > >> Mike
> > > >>
> > > >> Sent from my iPhone
> > > >>
> > > >>> On 1 Nov 2017, at 16:34, Michael André Pearce <
> > > michael.andre.pea...@me.com> wrote:
> > > >>>
> > > >>> Twitter for a group account has a nice level of owner, admin
> and
> > > user, that means committers can login with their own accounts and no
> one
> > > need the master/owners password for day to day, the owner account just
> > > needed to reset bits if ever needed.
> > > >>>
> > > >>> Owner = private pmc email (once we’ve setup all, this is easy
> to
> > > transfer)
> > > >>>
> > > >>>
> > > >>>
> > > >>> Sent from my iPhone
> > > >>>
> > >  On 1 Nov 2017, at 16:19, Michael André Pearce <
> > > michael.andre.pea...@me.com> wrote:
> > > 
> > >  Yes, I would set it up sort it out then finally transfer the
> > > owner to private mail list so pmc have control
> > > 
> > >  Sent from my iPhone
> > > 
> > > > On 1 Nov 2017, at 13:36, Timothy Bish 
> > > wrote:
> > > >
> > > > Any official project social media account needs to be under
> > > control the project PMC, refer to
> > > > https://www.apache.org/foundation/marks/socialmedia
> > > >
> > > >> On 11/01/2017 09:22 AM, Christopher Shannon wrote:
> > > >> +1
> > > >>
> > > >> On Wed, Nov 1, 2017 at 9:14 AM, Clebert Suconic <
> > > clebert.suco...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> +1
> > > >>>
> > > >>> On Wed, Nov 1, 2017 at 2:40 AM, Jean-Baptiste Onofré <
> > > j...@nanthrax.net>
> > > >>> wrote:
> > >  No objection from my side.
> > > 
> > >  Regards
> > >  JB
> > > 
> > > 

Re: Kafka ServiceConnector

[Martyn Taylor]

Looking at the Kafka Connect example.  I see that the integration
components are all maintained outside of the Kafka project.  They're listed
here: https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem

How about we do something similar and create a wiki/web page linking the
integration projects.  I realise our website isn't the most accessible atm
but going forward this should be improved.

On Thu, Oct 26, 2017 at 5:42 PM, Robbie Gemmell 
wrote:

> The related PR is https://github.com/apache/activemq-artemis/pull/1607
> for anyone not following along thus far, or later reference.
>
> My main view there was that such an extension would be better
> maintained seperate from the main broker repository+distribution for a
> variety of reasons. After that I didn't have a strong view on where it
> lives, but I would say that I don't actually see any issue at all with
> it being outwith the ActiveMQ project. To me thats just a key thing
> enabled by such plugin points existing, and not uncommon with other
> projects/components.
>
> Robbie
>
> On 26 October 2017 at 16:46, Michael André Pearce
>  wrote:
> > As noted on the PR part of the PR discussion is should Service
> Connectors exist with the broker code.
> >
> > Service Connectors / Extensions are ActiveMQ Artemis specific.
> >
> > I think having them within the project space is good so we can grow an
> eco system of some,  people can just use will aid in having better broker
> adoption as tools people look for would be available if contributed.
> >
> > As stated above it seems the general consensus on the PR is though liked
> is the broker code base best for them to live?
> >
> > If we don’t wish them to exist with broker code so they can have their
> own release cycle, and don’t murky the water of the broker, I would like to
> discuss if we could make a sub project for these to live, and possibly
> propose a sub project be setup called “ActiveMQ Artemis Integrations” ?
> >
> > If setup I would also propose maybe moving the spring integration there
> also.
> >
> > Cheers
> > Mike
> >
> >
> >
> >
> >
> >
> >
> > Sent from my iPhone
> >
> >> On 6 Oct 2017, at 12:20, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
> >>
> >> Yes and no, it would be same as arguing that core bridge between
> artemis clusters could also be separated components.
> >>
> >> The idea is to effectively have similar to a core bridge but to kafka.
> >>
> >> Some key parts why are (and probably similar to why core bridge is
> implemented within the broker)
> >>
> >> Latency
> >> Extra processes and hops
> >> Out the box in broker support
> >>
> >> Cheers
> >> Mike
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On 6 Oct 2017, at 12:14, Andy Taylor  wrote:
> >>>
> >>> I think https://github.com/ppatierno/kafka-connect-amqp is an example
> of
> >>> this
> >>>
> >>> On 6 October 2017 at 12:07, Christopher Shannon <
> >>> christopher.l.shan...@gmail.com> wrote:
> >>>
>  Why not use Kafka's Connect framework?  Seems like building a source
>  connector here would make the most sense.  This is not to say I'm
> against
>  the idea I'm just wondering the benefits of doing it from the Artemis
> side
>  of things when Kafka already has a framework that can be used to
>  import/export data.
> 
>  On Fri, Oct 6, 2017 at 6:16 AM, Michael André Pearce <
>  michael.andre.pea...@me.com> wrote:
> 
> > Hi Andy,
> >
> > As you may be aware or not we run both activemq and kafka each has a
> > specific plus point to it, use the right tool for the right job.
> >
> > We use activemq as our feature rich, fully jms compliant and
> performant
> > broker.
> >
> > And use kafka more for post processing and data streaming, with
>  historical
> > feed also.
> >
> > Idea here is that producers and consumers bind into our activemq
> where
>  jms
> > api is wanted or needed, lower per message latencies etc. but then
> we can
> > bridge messages from a core queue into kafka so that the data can
> flow to
> > it as fast as possible and consumed from there also.
> >
> > Idea is to try make a hybrid taking best of both.
> >
> > Cheers
> > Mike
> >
> > Sent from my iPhone
> >
> >> On 6 Oct 2017, at 09:37, Andy Taylor 
> wrote:
> >>
> >> Whats the use case here Michael, sounds like a cool idea and
> something
> > that
> >> has been mentioned by different people but I am yet to understand
> how
> > this
> >> could be used.
> >>
> >> On 6 October 2017 at 07:48, Michael André Pearce <
> >> michael.andre.pea...@me.com> wrote:
> >>
> >>> Hi All,
> >>>
> >>> I am looking to contribute an artemis ServiceConnector that would
> > leverage
> >>> the existing service connector interface to bridge from a queue
> into a
> 

Re: [DISCUSS] release process improvements

[Martyn Taylor]

I don't think the responses were negative.  I don't think the benefit was
made clear and people are questioning whether it's worth the effort.  How
much time are we talking about saving here?  Seconds, minutes or hours?
Would a reviewer script be helpful for some of this?

IMO the Artemis release process seems to be working fine, there are quite a
few steps to remember as a release manager and it's easy to make mistakes,
so I would prefer not to change the process unless there's a clear benefit
that warrants it.

On Wed, Sep 13, 2017 at 10:42 AM, Robbie Gemmell 
wrote:

> I'm a bit surprised by the negative responses if I'm honest.
>
> There isn't really any significant difference in the amount of work
> for the release manager here. The suggestion mainly just moves the
> step of populating the dist repo to before the vote rather than after,
> using the dev area rather than release area. As part of that entirely
> scriptable action, the checksums could be improved by running some
> commands, simplifying their eventual use both for testers and for end
> users to apply them toward the purpose they exist in verifying
> releases downloaded from the mirrors. Using the dev repo lets folks
> test what is actually going to be released to the dist mirrors later,
> much like the nexus staging repo allows testing the precise maven
> artifacts before they are promoted to release. After the vote there is
> then less moving parts with the release manger (or someone else if
> ever needed) just doing "svn cp  " to complete
> things, much like clicking the release button in Nexus.
>
> For what its worth, I based the suggestions on having followed similar
> process at Qpid for several years as either release manager or a
> tester. I've release managed a roughly similar number of releases in
> recent years as all the ActiveMQ components combined have had in that
> time, and don't find the suggestions in any way a burden, if anything
> I think they make life easier for everyone including me.
>
> Robbie
>
> On 12 September 2017 at 22:43, Michael André Pearce
>  wrote:
> > I'm -0 on this.
> >
> > I'm not against it if people want it, but also I don't see if it adds
> that much to warrant the effort.
> >
> >  e.g. If I had to do the work I prob wouldn't want to have the extra
> burden. At most I would just update the checksum (though I don't think this
> is end of the world right now either, I know plenty of org/projects still
> using md5 hash only still)
> >
> > As someone who's been active since the new year and tested now a few
> releases it hasn't been difficult getting binaries or artifacts and
> validating them.
> >
> >
> > Cheers
> > Mike
> >
> >
> >
> >
> >
> > Sent from my iPhone
> >
> >> On 12 Sep 2017, at 22:03, Clebert Suconic 
> wrote:
> >>
> >> What is the point on adding extra steps on verifying signatures and
> hashes?
> >> Nexus won't let us deploy anything if it has a bad hash?
> >>
> >> It seems additional burecractics that could be automated in Nexus. Or
> >> whatever ever replaces it if you are concerned about the future.
> >>
> >> I have been following other projects and their processes are even leaner
> >> than ours.
> >>
> >> On Tue, Sep 12, 2017 at 4:41 PM Clebert Suconic <
> clebert.suco...@gmail.com>
> >> wrote:
> >>
> >>> -1 to change the process.
> >>>
> >>> +1 to add scripts to the reviewer.
> >>>
> >>> That is we improve the process of reviews. But I don't think we need to
> >>> change how this is released.
> >>>
> >>>
> >>>
> >>>
>  On Tue, Sep 12, 2017 at 12:36 PM Daniel Kulp 
> wrote:
> 
>  Just to be clear…
> 
>  This proposal creates more work for the release manager prior to
> starting
>  the vote but in hopes of reducing the work for the reviewers.   It’s
> a bit
>  more than a “mvn release:prepare ; man release:perform”.  Some of the
> extra
>  work can obviously be scripted, but it is still a bit more to do.
> 
>  That said,  script provided to the reviewer could accomplish the same
>  things using the current staging location/setup.
> 
>  Anyway, I’m -0 to the idea.Getting folks to actually be a release
>  manager is hard enough, why make it even more work.Since I
> haven’t been
>  a release manager for an ActiveMQ release in a while, I certainly
> wouldn’t
>  hold up the idea though.
> 
>  Dan
> 
> 
> 
> > On Sep 12, 2017, at 9:49 AM, Robbie Gemmell <
> robbie.gemm...@gmail.com>
>  wrote:
> >
> > Hi folks,
> >
> > I mentioned on the recent Artemis 2.3.0 vote that I had some
> suggested
> > changes for the release process improvements, not just for Artemis
> but
> > for other components too, and would send a mail later.
> >
> > The short version is there are three main things I'd like to suggest
> > as improvements, both for folks testing+voting, and end 

Re: [VOTE] Apache ActiveMQ Artemis 2.3.0

[Martyn Taylor]

-1.

I managed to reproduce this.  In Firefox (which I rarely use), I loaded up
the console to be only to be greeted by the HawtIO branding... sigh...
After checking the localStorage settings from Michael's commit, I could see
that they were set to:

theme="default"
branding="hawtio"

A bit of digging shows that this is part of HawtIO proper:
https://github.com/hawtio/hawtio/blob/master/hawtio-web/src/main/webapp/app/themes/js/themesPlugin.ts#L57-L58

If anyone has used any HawtIO plugin previously there's a potential this
issue can surface for them.  Clebert, we will need to fix and rebuild.

Michael I tested your patch and it solves the problem.  I have some
comments, I will post on the PR.

Thanks



On Fri, Sep 1, 2017 at 8:47 AM, Martyn Taylor <mtay...@redhat.com> wrote:

> Tim,
>
> Are you sure your browser has not cached a previous version of the HawtIO
> branding?  What happens if you run inside of private browse mode?
>
> On Fri, Sep 1, 2017 at 6:19 AM, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
>
>> Hi Guys,
>>
>> Like Clebert I cannot reproduce.
>>
>> I have a hunch I think what's going on, and have made a PR to address
>> that if it is the case.
>>
>> But I really need a reproducer to test it, Tim I'm hoping you can help us
>> here? I have tagged you both in the PR.
>>
>> Cheers
>> Mike
>>
>> Sent from my iPhone
>>
>> On 1 Sep 2017, at 02:05, Clebert Suconic <clebert.suco...@gmail.com>
>> wrote:
>>
>> >> /Users/clebertsuconic/Downloads/apache-artemis-2.3.0 foo
>> > worked on my mac, and two different linuxes I have access.. perhaps it
>> > was something else on your box?
>> >
>> > You must be doing something wrong there.
>> >
>> >> FireFox v55.0.2 on my Linux machine shows Hawt.io branding, the site
>> does
>> >> show the ActiveMQ branding in Chromium though but I'd suggest trying a
>> range
>> >> of browsers and platforms.
>> >
>> > I tried that and it worked...
>> > You must be doing something wrong there :)
>> > lets talk tomorrow over IRC.
>>
>
>

Re: [VOTE] Apache ActiveMQ Artemis 2.3.0

[Martyn Taylor]

Tim,

Are you sure your browser has not cached a previous version of the HawtIO
branding?  What happens if you run inside of private browse mode?

On Fri, Sep 1, 2017 at 6:19 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> Hi Guys,
>
> Like Clebert I cannot reproduce.
>
> I have a hunch I think what's going on, and have made a PR to address that
> if it is the case.
>
> But I really need a reproducer to test it, Tim I'm hoping you can help us
> here? I have tagged you both in the PR.
>
> Cheers
> Mike
>
> Sent from my iPhone
>
> On 1 Sep 2017, at 02:05, Clebert Suconic 
> wrote:
>
> >> /Users/clebertsuconic/Downloads/apache-artemis-2.3.0 foo
> > worked on my mac, and two different linuxes I have access.. perhaps it
> > was something else on your box?
> >
> > You must be doing something wrong there.
> >
> >> FireFox v55.0.2 on my Linux machine shows Hawt.io branding, the site
> does
> >> show the ActiveMQ branding in Chromium though but I'd suggest trying a
> range
> >> of browsers and platforms.
> >
> > I tried that and it worked...
> > You must be doing something wrong there :)
> > lets talk tomorrow over IRC.
>

Re: [VOTE] Apache Artemis 2.2.0

[Martyn Taylor]

+1

On Wed, Jul 26, 2017 at 8:28 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> +1
>
> On Wed, Jul 26, 2017 at 1:26 PM, nigro_franz  wrote:
>
> > +1
> >
> > * Built from source and ran tests
> > * Ran from binary vs a load generator
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> > nabble.com/VOTE-Apache-Artemis-2-2-0-tp4728886p4728940.html
> > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> >
>

Re: [DISCUSSS] Web Management Console for Artemis.

[Martyn Taylor]

Perhaps a bad description of what I meant.  To clarify, I didn't see any
powered by logo when I was browsing the console.  A point that was on the
check list and was raised by a community member.  When I've seen these
types of "powered by" logos before, they've been included in a page footer
along with other site information.  I'd need to go digging to find it in
the about page.  I presume the intent of including the powered by logo, is
to draw traction to the HawtIO project, imo a reasonable request, but
perhaps not fulfilled by having it hidden away.

I don't think it's a blocker for the PR.  Just something I wanted to call
out.  We can discuss further on a JIRA.

On Thu, Jul 27, 2017 at 4:28 PM, Justin Bertram <jbert...@redhat.com> wrote:

> I'm confused.  Did Martyn say that a "Powered By" needs to be on the main
> page of the console?
>
>
> Justin
>
> On Thu, Jul 27, 2017 at 9:38 AM, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
>
> > As Dan says there is a reference to being powered by in the about page.
> >
> > I was under the impression it shouldn't be up front an centre, but in the
> > about area would suffice.
> >
> >
> >
> > Sent from my iPhone
> >
> > > On 27 Jul 2017, at 13:11, Daniel Kulp <dk...@apache.org> wrote:
> > >
> > >
> > >
> > >> On Jul 27, 2017, at 6:56 AM, Martyn Taylor <mtay...@redhat.com>
> wrote:
> > >>
> > >> No third party / propriety other products should be mentioned apart
> > from a
> > >> powered by.
> > >>  * I don't see any powered by on the main screens.  We can open a JIRA
> > to
> > >> track it once this is merged.
> > >
> > > It shouldn’t be on the main screen…. There is information on the
> “About”
> > page (at least last time I looked at it) which is enough.
> > >
> > >
> > > Dan
> > >
> > >
> > >
> > >>
> > >> This should be able to expand over time
> > >> * Met. It's extendable.
> > >>
> > >> License/Notice files and any legal requirements are updated/met
> > >> * I've been through each source, license and notice file.  Both in
> this
> > >> project and the original project this is imported from.  The original
> > >> project was not properly licensed, which caused some concern.
> However,
> > >> I've sent a PR which was merged.  I think we're all good here.
> > >>
> > >> In summary, I think it's a great first start and something users can
> use
> > >> pretty much straight away.
> > >>
> > >> +1 from me.  Great work Michael.
> > >>
> > >> Thanks
> > >>
> > >>
> > >>> On Tue, Jul 18, 2017 at 5:22 PM, Justin Bertram <jbert...@redhat.com
> >
> > wrote:
> > >>>
> > >>> I just reviewed the new console via the PR.  I really like it.  Nice
> > work!
> > >>>
> > >>>
> > >>> Justin
> > >>>
> > >>> On Thu, Jul 13, 2017 at 2:30 PM, Clebert Suconic <
> > >>> clebert.suco...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> That's fair guys.. I was just tempted to do it.. but won't to it.
> > >>>>
> > >>>> On Thu, Jul 13, 2017 at 2:04 PM, Michael André Pearce
> > >>>> <michael.andre.pea...@me.com> wrote:
> > >>>>> I would agree, we should stick to the plan.
> > >>>>>
> > >>>>> Merging straight after release and releasing again won't delay in
> > >>>> reality the time people can use it. Apart from a few days at most.
> > >>>>>
> > >>>>> But will address/de risks any concerns.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Sent from my iPhone
> > >>>>>
> > >>>>>>> On 13 Jul 2017, at 17:23, Timothy Bish <tabish...@gmail.com>
> > wrote:
> > >>>>>>>
> > >>>>>>> On 07/13/2017 12:10 PM, Clebert Suconic wrote:
> > >>>>>>> I am tempted to merge it now actually
> > >>>>>>>
> > >>>>>>> Anyone opposed to this? it would be cool to have a console on
> this
> > >>>>>>> next release.. if it's all good.
&

Re: [DISCUSSS] Web Management Console for Artemis.

[Martyn Taylor]

I've taken some time to review the console.  I don't think we're quite
there yet in terms of meeting all of the goals outlined in the original
email.  However, I don't think we need to hold up merging the PR.
Improvements can be made iteratively.  Couple of comments:

Must be ActiveMQ Branded
   * Met.  Looks good, particularly with the new logo ;).

No third party / propriety other products should be mentioned apart from a
powered by.
   * I don't see any powered by on the main screens.  We can open a JIRA to
track it once this is merged.

This should be able to expand over time
  * Met. It's extendable.

License/Notice files and any legal requirements are updated/met
  * I've been through each source, license and notice file.  Both in this
project and the original project this is imported from.  The original
project was not properly licensed, which caused some concern.  However,
I've sent a PR which was merged.  I think we're all good here.

In summary, I think it's a great first start and something users can use
pretty much straight away.

+1 from me.  Great work Michael.

Thanks


On Tue, Jul 18, 2017 at 5:22 PM, Justin Bertram  wrote:

> I just reviewed the new console via the PR.  I really like it.  Nice work!
>
>
> Justin
>
> On Thu, Jul 13, 2017 at 2:30 PM, Clebert Suconic <
> clebert.suco...@gmail.com>
> wrote:
>
> > That's fair guys.. I was just tempted to do it.. but won't to it.
> >
> > On Thu, Jul 13, 2017 at 2:04 PM, Michael André Pearce
> >  wrote:
> > > I would agree, we should stick to the plan.
> > >
> > > Merging straight after release and releasing again won't delay in
> > reality the time people can use it. Apart from a few days at most.
> > >
> > >  But will address/de risks any concerns.
> > >
> > >
> > >
> > >
> > > Sent from my iPhone
> > >
> > >> On 13 Jul 2017, at 17:23, Timothy Bish  wrote:
> > >>
> > >>> On 07/13/2017 12:10 PM, Clebert Suconic wrote:
> > >>> I am tempted to merge it now actually
> > >>>
> > >>> Anyone opposed to this? it would be cool to have a console on this
> > >>> next release.. if it's all good.
> > >>
> > >> Please stick to the original plan.  I guessing there's other folks
> like
> > myself who haven't had time to even look at this new console yet.
> > >>
> > >>>
> > >>> On Mon, Jul 10, 2017 at 3:30 PM, Michael André Pearce
> > >>>  wrote:
> >  Hi All,
> > 
> >  I would like to start a fresh discussion to keep things cleaner, and
> > to provide more of a notification/update. (also to better name the
> subject)
> > 
> >  The requirement for such a tool comes from many end users (including
> > myself) which keep requesting such a feature of a web management console
> (a
> > small selection of a much larger list i can supply many more), and so
> > becomes more and more pressing to resolve.
> > 
> >  http://activemq.2283324.n4.nabble.com/How-to-monitor-
> > artemis-td4727071.html  > nabble.com/How-to-monitor-artemis-td4727071.html>
> >  https://softwarerecs.stackexchange.com/questions/
> > 39052/administration-console-for-artemis-jms-broker <
> https://softwarerecs.
> > stackexchange.com/questions/39052/administration-console-
> > for-artemis-jms-broker>
> >  https://stackoverflow.com/questions/37162532/how-to-
> > monitor-apache-artemis  > questions/37162532/how-to-monitor-apache-artemis>
> > 
> > 
> >  Based off the discussion here:
> > 
> >  http://activemq.2283324.n4.nabble.com/DISCUSS-Removing-
> > the-Web-Console-td4717136i40.html#a4728199  > nabble.com/DISCUSS-Removing-the-Web-Console-td4717136i40.html#a4728199>
> > 
> >  We have some key requirements as noted were (not exhaustive but a
> > small summary of noted in the above thread):
> > 
> >  Must be ActiveMQ Branded
> >  No third party / propriety other products should be mentioned apart
> > from a powered by.
> >  Help and about pages should be ActiveMQ Artemis focussed
> >  Provide functionality to manage the broker
> >  This should be able to expand over time
> >  License/Notice files and any legal requirements are updated/met
> >  The war size should be kept to a minimum
> >  Login/Security should be integrated to the broker roles/users
> >  Plugins/customisation specific to AcitveMQ Artemis to reside in
> > ActiveMQ Artemis project.
> > 
> >  Also we had some good early feedback in the community on the missing
> > bits in our early PR, of bits that needed/must be addressed. (thanks to
> > Dan, Clebert, Martyn).
> > 
> >  We believe we have a viable “agreeable" solution to provide a web
> > console admin for Apache ActiveMQ Artemis.
> > 
> >  As such we don’t see any reason to hold off and would like to bring
> > your attention (again) to the PR please make any standard review 

Re: Non Durable Queue Cleanup

[Martyn Taylor]

Michael,

As Andy mentioned it's protocol specific.

With CORE protocol, the client sends a DELETE QUEUE packet.
https://github.com/apache/activemq-artemis/blob/master/
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/core/
ServerSessionPacketHandler.java#L376

In AMQP, the queue is deleted on link remote close PACKET:
https://github.com/apache/activemq-artemis/blob/master/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/ProtonServerSenderContext.java#L492

We also have failure handlers that take care of clean up if the client
disconnects unexpectedly.

Cheers

On Tue, Jul 11, 2017 at 7:50 PM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> Ignore the last comment, its not true, i just can’t read a simple log
> line. but alas still stumped.
>
> > On 11 Jul 2017, at 19:47, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
> >
> > Just a little more digging, it seems when two separate topic
> subscriptions are made, one of the queues is made durable, and the other is
> not, even so both should be not durable, seems to occur on both core and
> amqp client.
> > No idea how this could be still, any pointers of code to check or put
> breakpoints in much appreciated.
> >
> >> On 11 Jul 2017, at 18:05, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
> >>
> >> We have been connecting both amqp (jms) and core clients connected to
> the address.
> >>
> >> We have shutdown all, yet an amount of queues remain. We have checked
> the connected consumers = 0 and the queues that remain are def non durables.
> >>
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On 11 Jul 2017, at 17:28, Andy Taylor  wrote:
> >>>
> >>> Depends on the protocol Michael, which client are you using when you
> see
> >>> this occur?
> >>>
> >>> On 11 July 2017 at 16:35, Michael André Pearce <
> michael.andre.pea...@me.com>
> >>> wrote:
> >>>
>  Hi All,
> 
>  I'm trying to find the logic that cleans up non durable queues (jms
> topic
>  subscription).
> 
>  I can find logic with regards to auto created and auto delete where
>  message count == 0.
> 
>  But nothing with regards to specific logic to clear up non durables.
> 
>  Reason I'm asking is we are seeing non durable queues hang about
> after the
>  jms topic subscriber is gone.
> 
>  Cheers
>  Mike
> 
>  Sent from my iPhone
> >
>
>

Re: [DISCUSS] Removing the Web Console

[Martyn Taylor]

Michael,

If people think this is the way to go then I can't see there being any
problem with 3).

Cheers

On Mon, Jul 3, 2017 at 11:52 PM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> Ok,
>
> So i think we can do this. From a local build.
>
> Please see screenshots.
>
>  https://gist.github.com/michaelandrepearce/98b4be98d20f407c2d745a41df9cef
> 03  98b4be98d20f407c2d745a41df9cef03>
>
> For 1) I think we have managed to completely skin it, with all hawtio
> references removed, even the favicon.
> For 2) Only the artemis plugin and base jvm plugins, no extras for any
> other products.
> For 3) Im hoping we can come to agreement on this gets contributed in from
> the rh-messaging project @clebert @martyn @andy?, if not we can probably
> code up a simpler version of it for now without bells and whistles, and add
> in the future features later.
>
> So if we sort point three, i think we can make this “acceptable”
>
> Cheers
> Mike
>
> > On 29 Jun 2017, at 19:17, Daniel Kulp  wrote:
> >
> >>
> >> On Jun 29, 2017, at 1:59 PM, Michael André Pearce <
> michael.andre.pea...@me.com > wrote:
> >>
> >> I believe we could make a simple activemq branding jar/war with the
> selected new logo ;) once decided without too much trouble.
> >>
> >> I'd be happy to step up to try do this if no objectors.
> >
> > I discussed previously, what would NEED to be done for this to be
> “acceptable”:
> >
> > 1) All branding/links/etc… in the console need to be re-skinned or
> whatever to be “ActiveMQ”.  All mentions of hawtio and links off to other
> sites other than a possible small “powered by” type thing would need to be
> removed.
> >
> > 2) All “plugins” and functionality that don’t pertain to things related
> to ActiveMQ would need to be removed.
> >
> > 3) The “plugin" that presents ActiveMQ related stuff to the user MUST
> live here at Apache and part of the ActiveMQ community.   We cannot use the
> one they provide (unless you can convince them to donate it to Apache).
> >
> > Unless all three happen, it’s a no-go.
> >
> > Dan
> >
> >
> >>
> >>> On 29 Jun 2017, at 16:51, Clebert Suconic 
> wrote:
> >>>
> >>> Speaking the plain truth... The issue is that the hawtio console that
> >>> was used years ago.. looked like a commercial product outside of
> >>> apache
> >>>
> >>> I think that if we clear that now.. if it looks an apache look &
> >>> feel.. people wouldn't have an issue with it.
> >>>
> >>>
> >>> That would require some cleanup.. move to a newer hawtio plugin maybe?
> >>> that's when we thought about trying new routes if we would need to do
> >>> a lot of work anyways.
> >>>
> >>> On Thu, Jun 29, 2017 at 11:42 AM, Michael André Pearce
> >>>  wrote:
>  I don't think this is a blocker, for example artemis uses jboss
> logging, this doesn't have a notice file
> 
>  I think we just have to preserve them if present and for asf projects
> themselves eg artemis itself it's policy to provide one for the asf work.
> 
>  Sent from my iPhone
> 
> > On 29 Jun 2017, at 01:09, W B D  wrote:
> >
> > I've been using hawtio alongside the classic web console in ActiveMQ
> 5.x
> > and have been quite happy with it. I find it easier to use for many
> common
> > operations as well as for general monitoring, and it is definitely a
> gap in
> > the current Artemis distribution, so I would certainly welcome
> built-in
> > hawtio support as a good addition.
> >
> > Although the source code already contains the standard license
> assignment
> > to ASF, it does not include a NOTICE file. We could ask Redhat for
> one, or
> > construct one crediting them with the original work, or add a stanza
> to the
> > top-level NOTICE file if that is more appropriate. IMO, the package
> and
> > class name org.jboss.plugin.PluginContextListener could probably be
> changed
> > in our copy, both to establish custody and to give a clearer name.
> >
> > On Wed, Jun 28, 2017 at 9:27 AM, MichaelAndrePearce <
> > michael.andre.pea...@me.com> wrote:
> >
> >> Hi Guys,
> >>
> >> It's been some time since this discussion thread without seemingly
> any
> >> movement.
> >>
> >> Artemis Project is really suffering from having any kind of
> management
> >> console. With continued questions and calls from users especially
> as it's
> >> picking up traction and deployment.
> >>
> >> As such could I propose, that as lack of movement on any other
> solution and
> >> Hawtio is pretty much in a usable state, with a plugin also out
> there in
> >> the
> >> wild. (It's ASL)
> >>
> >> That for the interim on artemis project we build and release with
> Hawtio
> >> and
> >> an artemis plugin (if RH would donate their plugin to 

Re: org.apache.activemq.artemis.core.journal.impl.JournalImpl

[Martyn Taylor]

There's no way to explicitly limit the number of page files.  However, you
can set the "max-disk-usage" parameter[1][2].  Once this limit is reached,
the broker will use flow control to stop the clients sending more messages
(this is the same as BLOCK policy).  If the protocol being used does not
support flow control. e.g. MQTT, the client will be disconnected.

1. https://activemq.apache.org/artemis/docs/2.1.0/paging.html
2. https://activemq.apache.org/artemis/docs/2.1.0/paging.html#max-disk-usage

On Thu, Jun 22, 2017 at 1:43 PM, nigro_franz  wrote:

> Hi,
>
> I've just rolled out a couple of improvements on Paging: right now are on
> the latest master so you could try if it works for you...
>
> regards,
> Franz
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/org-apache-activemq-artemis-core-journal-impl-JournalImpl-
> tp4726923p4727745.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [DISCUSS] Custom Object Serialisation Support

[Martyn Taylor]

;>>>>
> > >>>>> Yes we can do converter.convert(object) in code, this is just
> manual
> > code in the app space.
> > >>>>>
> > >>>>> but like with kafka and I have to stress it's successfulness is
> that
> > that converter is in it's api of the product. Which means a lot of
> > companies reuse a few single implementations and a good eco system occurs
> > like with schema registry (Eg we use confluents serdes we don't code out
> > own)
> > >>>>
> > >>>> Which is exactly what camel can solve and without starting down the
> > slippery slop of packing the same data format conversions Camel can
> already
> > handle into the Artemis code base as will happen as each user wants their
> > own preferred data format.
> > >>>>
> > >>>> Similar things were tried in the ActiveMQ 5.x code and abandoned
> over
> > time so I'd like to avoid that if possible.
> > >>>>
> > >>>> Anyway, I've raised my objection.
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Sent from my iPhone
> > >>>>>
> > >>>>>>> On 1 Jun 2017, at 17:39, Timothy Bish <tabish...@gmail.com>
> wrote:
> > >>>>>>>
> > >>>>>>> On 06/01/2017 12:19 PM, Michael André Pearce wrote:
> > >>>>>>> Agreed it does as an EAI pattern or flow, But I have to
> > code/define into Camel's dsl, it does JMS as much as our custom app code
> > would it consumes the JMS api.
> > >>>>>> So you still need to code / define the serialization then and
> > include that in you application which means the difference between some
> > connection.setSerializationThing() vs
> > producer.send(Converter.convert(payload)); so I don't see how that is a
> > real value add to the JMS client.
> > >>>>>>
> > >>>>>>> What we propose here is just providing a clean way to define the
> > JMS ObjectMessage internal serialisation. If Java serialisation isn't
> your
> > cup of tea. (Which for many reasons isn't for us, and I'm sure it's
> similar
> > for others)
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>>> On 1 Jun 2017, at 16:58, Timothy Bish <tabish...@gmail.com>
> > wrote:
> > >>>>>>>>>
> > >>>>>>>>> On 06/01/2017 11:50 AM, Michael André Pearce wrote:
> > >>>>>>>>> Really this is much more about how an ObjectMessage serializes
> > the Object. As we have C++ clients etc that obviously won't be able to
> > understand Java serialized object.
> > >>>>>>>>>
> > >>>>>>>>> We use Avro and a schema repo for our dto transfer over the
> > wire, it's been a real performance boost , and removed some core data
> > issues, and really like to use it over the JMS land.
> > >>>>>>>>>
> > >>>>>>>>> One can argue that you could manually code this that you
> > serialize the data manually first and then just manually send a
> > BytesMessage.
> > >>>>>>>>>
> > >>>>>>>>> But I think taking some inspiration from other places where a
> > serdes pattern is done has really helped (Kafka), from a corporation user
> > approach wiring some prebuilt serdes into a factory is very easy, having
> > duplicated code in many many apps leaves for issues, and implementation
> > divergence.
> > >>>>>>>>>
> > >>>>>>>>> The one downside of Kafka is it's lack of spec api, this is one
> > big sell of artemis as it's JMS compliant. Coding against JMS api for
> Java
> > estate is a huge win, this is suggesting taking some of the good bits :).
> > >>>>>>>>>
> > >>>>>>>>> Does camel expose this as some sort of JMS API wrapper? I
> > thought it was much more an EAI solution.
> > >>>>>>>>>
> > >>>>>>>>> Cheers
> > >>>>>>>>> Mike
> > >>>>>>>> Camel does JMS transport: http://camel.apache.org/sjms.html
> > >>>>>>>> Camel does AVRO: http://camel.apache.org/avro.html
&

Re: [DISCUSS] Custom Object Serialisation Support

[Martyn Taylor]

On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish <tabish...@gmail.com> wrote:

> On 06/01/2017 09:34 AM, Martyn Taylor wrote:
>
>> On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish <tabish...@gmail.com> wrote:
>>
>> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
>>>
>>> I get the use case for using JSON/XML, particularly for cross language
>>>> communication.
>>>>
>>>> One way users get around this problem right now is just to serialize
>>>> to/from XML/JSON at the client application level and just use JMS
>>>> TextMessages to send the data. I guess the idea here to remove that
>>>> complexity from the client application and into the client via these
>>>> pluggable serializer objects?  Removing the serizliation logic out of
>>>> code
>>>> and into configuration.
>>>>
>>>> Providing I've understood this properly, it seems like a good idea to
>>>> me.
>>>>so +1.
>>>>
>>>> This problem has already been solved via frameworks like Apache Camel,
>>> putting such complexity into the JMS client is solving a problem that's
>>> already been solved and in much more flexible and configurable ways.
>>>
>>
>> Thanks Tim.  I am not a Camel expert in any shape or form, how much
>> additional complexity/configuration would be required to do something
>> similar with Camel?  My understanding of the proposal here is really just
>> to give control back to the user in terms of how their objects are
>> serialized.  I'd expect this to be pretty light weight, just allow a user
>> to configure a class to do the serialization.
>>
>
> Camel offers conversions for a number of data formats

Sure.   Though, one of the drivers (mentioned in this thread) for having
control over the de/serialization process was for performance.  Converting
to another format is going to obviously make this much worse.

> as well as routing amongst numerous protocols, have a look at the
> supported data formats page: http://camel.apache.org/data-format.html and
> the transports http://camel.apache.org/transport.html


>
> This doesn't seem to be doing much more for the user than moving the work
> they need to do around,

Well, it abstracts the de/serialization process out of application code.

> they still have to implement or configure the mechanics of the
> transformation of the data format to the appropriate JMS message type and
> back again.  Even if you bake in something to the client to handle some
> common formats you will quickly find that it doesn't meet everyone's needs
> and you'll end up implementing a poor mans Camel inside a JMS API
> restricted client which seems less than ideal.

I agree reinventing the wheel (badly) is not a good idea.  So, if Camel is
able to provide us with a solution to the problem, that addresses the
issues outlined here.  Then, we should certainly look into it.

Cheers.

>
>
>
>>
>> On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <
>>>> michael.andre.pea...@me.com> wrote:
>>>>
>>>> I think i might be getting the problem, use case you want to go for,
>>>> which
>>>>
>>>>> is to possible serialise to JSON or XML, because they're supported well
>>>>> in
>>>>> other languages like c++, which won't read a java serialised object,
>>>>> and
>>>>> say for XML you generate objects via an XSD which by default aren't
>>>>> serialisable, so you cannot simply add Serializable to the object, as
>>>>> its
>>>>> generated at build.
>>>>>
>>>>> Is this the problem we need to solve? If so:
>>>>>
>>>>> To get around this normally the tools that generate objects for
>>>>> serialisation from schema such as XSD do support a way to toggle or
>>>>> change
>>>>> the generation slightly for some common use cases.
>>>>>
>>>>> In case of XSD, where using jaxb it would be to add something like the
>>>>> below to jaxb global bindings:
>>>>>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>
>>>>> like wise if you are generating POJO's from a jsonschema using for say
>>>>> the
>>>>> tool jsonschema2pojo  there is a toggle in the maven plugin
>>>>> serializable
>>>>> which you can switch to true.
>>>>>
>>>>> Obviousl

Re: [DISCUSS] Custom Object Serialisation Support

[Martyn Taylor]

On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish <tabish...@gmail.com> wrote:

> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
>
>> I get the use case for using JSON/XML, particularly for cross language
>> communication.
>>
>> One way users get around this problem right now is just to serialize
>> to/from XML/JSON at the client application level and just use JMS
>> TextMessages to send the data. I guess the idea here to remove that
>> complexity from the client application and into the client via these
>> pluggable serializer objects?  Removing the serizliation logic out of code
>> and into configuration.
>>
>> Providing I've understood this properly, it seems like a good idea to me.
>>   so +1.
>>
>
> This problem has already been solved via frameworks like Apache Camel,
> putting such complexity into the JMS client is solving a problem that's
> already been solved and in much more flexible and configurable ways.


Thanks Tim.  I am not a Camel expert in any shape or form, how much
additional complexity/configuration would be required to do something
similar with Camel?  My understanding of the proposal here is really just
to give control back to the user in terms of how their objects are
serialized.  I'd expect this to be pretty light weight, just allow a user
to configure a class to do the serialization.


>
>> On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <
>> michael.andre.pea...@me.com> wrote:
>>
>> I think i might be getting the problem, use case you want to go for, which
>>> is to possible serialise to JSON or XML, because they're supported well
>>> in
>>> other languages like c++, which won't read a java serialised object, and
>>> say for XML you generate objects via an XSD which by default aren't
>>> serialisable, so you cannot simply add Serializable to the object, as its
>>> generated at build.
>>>
>>> Is this the problem we need to solve? If so:
>>>
>>> To get around this normally the tools that generate objects for
>>> serialisation from schema such as XSD do support a way to toggle or
>>> change
>>> the generation slightly for some common use cases.
>>>
>>> In case of XSD, where using jaxb it would be to add something like the
>>> below to jaxb global bindings:
>>>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>> like wise if you are generating POJO's from a jsonschema using for say
>>> the
>>> tool jsonschema2pojo  there is a toggle in the maven plugin serializable
>>> which you can switch to true.
>>>
>>> Obviously if you hand crank your DTO Pojo's then it's a case of simply
>>> add
>>> implement  Serializable to the class.
>>>
>>> Cheers
>>> Mike
>>>
>>> Sent from my iPhone
>>>
>>> On 1 Jun 2017, at 06:57, Michael André Pearce <
>>>>
>>> michael.andre.pea...@me.com> wrote:
>>>
>>>> we could but then it wouldn't work via jms api. Typically if using jms
>>>>
>>> the only custom or specific broker object is the connection factory the
>>> rest you code to Jms.
>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 1 Jun 2017, at 04:10, Clebert Suconic <clebert.suco...@gmail.com>
>>>>>
>>>> wrote:
>>>
>>>> On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <
>>>>> michael.andre.pea...@me.com> wrote:
>>>>>
>>>>> Jms api dictates class set in object message to be serializable.
>>>>>>
>>>>>
>>>>> We could make an extension. It could be an extra message this actually.
>>>>>
>>>>>
>>>>>>
>>>>>> On 31 May 2017, at 22:37, Timothy Nodine <timgnod...@gmail.com>
>>>>>>>
>>>>>> wrote:
>>>
>>>> Should the interface require the underlying class to be Serializable?
>>>>>>>
>>>>>> One use case might be to provide serialization to classes that aren't
>>>>>> natively serializable.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Michael André Pearce wrote:
>>>>>>>
>>>>>>>> To help discussion,
>>>>>>>> A very very basic implementation just to simulate the idea.
>>>>>>>>
>>>>>>> https://github.com/michaelandrepearce/activemq-artemis/tree/
>>>>>>
>>>>> CustomSerialisation
>>>
>>>> <
>>>>>> https://github.com/michaelandrepearce/activemq-artemis/tree/
>>>>>>
>>>>> CustomSerialisation
>>>
>>>> n.b. doesn’t fully compile is just pseudo impl, nor doesn’t include
>>>>>>>>
>>>>>>> bits as discussed below like map/change type to a byte message for
>>>>>> compatibility, nor media type idea.
>>>>>>
>>>>>>> Cheers
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> --
>>>>> Clebert Suconic
>>>>>
>>>>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [DISCUSS] Custom Object Serialisation Support

[Martyn Taylor]

I get the use case for using JSON/XML, particularly for cross language
communication.

One way users get around this problem right now is just to serialize
to/from XML/JSON at the client application level and just use JMS
TextMessages to send the data. I guess the idea here to remove that
complexity from the client application and into the client via these
pluggable serializer objects?  Removing the serizliation logic out of code
and into configuration.

Providing I've understood this properly, it seems like a good idea to me.
 so +1.


On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> I think i might be getting the problem, use case you want to go for, which
> is to possible serialise to JSON or XML, because they're supported well in
> other languages like c++, which won't read a java serialised object, and
> say for XML you generate objects via an XSD which by default aren't
> serialisable, so you cannot simply add Serializable to the object, as its
> generated at build.
>
> Is this the problem we need to solve? If so:
>
> To get around this normally the tools that generate objects for
> serialisation from schema such as XSD do support a way to toggle or change
> the generation slightly for some common use cases.
>
> In case of XSD, where using jaxb it would be to add something like the
> below to jaxb global bindings:
>
> 
> 
> 
> 
> 
> 
> 
>
> like wise if you are generating POJO's from a jsonschema using for say the
> tool jsonschema2pojo  there is a toggle in the maven plugin serializable
> which you can switch to true.
>
> Obviously if you hand crank your DTO Pojo's then it's a case of simply add
> implement  Serializable to the class.
>
> Cheers
> Mike
>
> Sent from my iPhone
>
> > On 1 Jun 2017, at 06:57, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
> >
> > we could but then it wouldn't work via jms api. Typically if using jms
> the only custom or specific broker object is the connection factory the
> rest you code to Jms.
> >
> >
> >
> > Sent from my iPhone
> >
> >> On 1 Jun 2017, at 04:10, Clebert Suconic 
> wrote:
> >>
> >> On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <
> >> michael.andre.pea...@me.com> wrote:
> >>
> >>> Jms api dictates class set in object message to be serializable.
> >>
> >>
> >> We could make an extension. It could be an extra message this actually.
> >>
> >>>
> >>>
> >>>
>  On 31 May 2017, at 22:37, Timothy Nodine 
> wrote:
> 
>  Should the interface require the underlying class to be Serializable?
> >>> One use case might be to provide serialization to classes that aren't
> >>> natively serializable.
> 
> 
> 
>  Michael André Pearce wrote:
> > To help discussion,
> > A very very basic implementation just to simulate the idea.
> >>> https://github.com/michaelandrepearce/activemq-artemis/tree/
> CustomSerialisation
> >>> <
> >>> https://github.com/michaelandrepearce/activemq-artemis/tree/
> CustomSerialisation
> 
> >
> > n.b. doesn’t fully compile is just pseudo impl, nor doesn’t include
> >>> bits as discussed below like map/change type to a byte message for
> >>> compatibility, nor media type idea.
> >
> > Cheers
> > Mike
> >
> 
> >>>
> >> --
> >> Clebert Suconic
>

Re: [DISCUSS] Use pooled buffers on message body

[Martyn Taylor]

@Clebert It's been added as a configuration option on the InVM
 acceptor/connector.  Take a look at those classes.

On Fri, May 26, 2017 at 4:26 PM, Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> @Martyn: you recently added some configuration on InVM to make pooled
> or Not.. where is that? Where is the pool right now after your
> changes?
>
> I can read the code. but it's easier to ask... :) Perhaps we should
> make a class with a PoolServer for such things?
>
>
> Like, I'm looking into perhaps add a ClientTransaction retry, and i
> would use the pool there as well. it would be best to have such class
> somewhere.
>
> On Fri, May 26, 2017 at 11:22 AM, Matt Pavlovich <mattr...@gmail.com>
> wrote:
> > +1 having the memory pool/allocator be a configurable strategy or
> policy-type deal would be bonus level 12. Esp. for embedded / kiosk /
> Raspberry Pi and linux host container scenarios as Martyn mentioned.
> >
> >> On May 26, 2017, at 9:50 AM, Clebert Suconic <clebert.suco...@gmail.com>
> wrote:
> >>
> >> Perhaps we need a place to set the allocator.. Pooled versus Unpooled..
> >>
> >>
> >> PooledRepository.getPool()...
> >>
> >>
> >>
> >> Regarding the ref counts.. we will need to add a new reference
> >> counting.. the current one is a bit complex to be used because of
> >> delivering.. DLQs.. etc... it's a big challenge for sure!
> >>
> >> On Fri, May 26, 2017 at 4:04 AM, Martyn Taylor <mtay...@redhat.com>
> wrote:
> >>> We've had using buffer pools throughout on the backlog for a long
> time, so
> >>> +1 on this.  The only thing I'd say here is that retrofitting the
> reference
> >>> counting (i.e. releasing the buffers) can sometimes lead to leaks, if
> we
> >>> don't catch all cases, so we just need to be careful here.
> >>>
> >>> One other thing to consider, we do have users that run Artemis in
> >>> constrained environments, where memory is limited.  Allocating a chunk
> of
> >>> memory upfront for the buffers may not be ideal for that use case.
> >>>
> >>> Cheers
> >>>
> >>> On Thu, May 25, 2017 at 5:53 PM, Matt Pavlovich <mattr...@gmail.com>
> wrote:
> >>>
> >>>> +1 this all sounds great
> >>>>
> >>>>> On May 12, 2017, at 12:02 PM, Michael André Pearce <
> >>>> michael.andre.pea...@me.com> wrote:
> >>>>>
> >>>>> I agree iterative targeted steps is best.
> >>>>>
> >>>>> So if even just pooling messages and keep the copying of the buffer
> as
> >>>> today it's a step in the right direction.
> >>>>>
> >>>>>
> >>>>> Sent from my iPhone
> >>>>>
> >>>>>> On 12 May 2017, at 15:52, Clebert Suconic <
> clebert.suco...@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>> I'm not sure we can keep the message body as a native buffer...
> >>>>>>
> >>>>>> I have seen it being expensive. Especially when dealing with
> >>>>>> clustering and paging.. a lot of times I have seen memory
> exaustion...
> >>>>>>
> >>>>>> for AMQP, on qpid Proton though.. that would require a lot more
> >>>>>> changes.. it's not even possible to think about it now  unless we
> make
> >>>>>> substantial changes to Proton.. Proton likes to keep its own
> internal
> >>>>>> pool and make a lot of copies.. so we cannot do this yet on AMQP. (I
> >>>>>> would like to though).
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> But I'm always in advocating of tackling one thing at the time...
> >>>>>> first thing is to have some reference counting in place to tell us
> >>>>>> when to deallocate the memory used by the message, in such way it
> >>>>>> works with both paging and non paging... anything else then will be
> >>>>>> "relatively' easier.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, May 12, 2017 at 2:56 AM, Michael André Pearce
> >>>>>> <michael.andre.pea...@me.com> wrote:
> >>>>>>>
> >>>>>>> Hi Clebert.
>

Re: [DISCUSS] Use pooled buffers on message body

[Martyn Taylor]

We've had using buffer pools throughout on the backlog for a long time, so
+1 on this.  The only thing I'd say here is that retrofitting the reference
counting (i.e. releasing the buffers) can sometimes lead to leaks, if we
don't catch all cases, so we just need to be careful here.

One other thing to consider, we do have users that run Artemis in
constrained environments, where memory is limited.  Allocating a chunk of
memory upfront for the buffers may not be ideal for that use case.

Cheers

On Thu, May 25, 2017 at 5:53 PM, Matt Pavlovich  wrote:

> +1 this all sounds great
>
> > On May 12, 2017, at 12:02 PM, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
> >
> > I agree iterative targeted steps is best.
> >
> > So if even just pooling messages and keep the copying of the buffer as
> today it's a step in the right direction.
> >
> >
> > Sent from my iPhone
> >
> >> On 12 May 2017, at 15:52, Clebert Suconic 
> wrote:
> >>
> >> I'm not sure we can keep the message body as a native buffer...
> >>
> >> I have seen it being expensive. Especially when dealing with
> >> clustering and paging.. a lot of times I have seen memory exaustion...
> >>
> >> for AMQP, on qpid Proton though.. that would require a lot more
> >> changes.. it's not even possible to think about it now  unless we make
> >> substantial changes to Proton.. Proton likes to keep its own internal
> >> pool and make a lot of copies.. so we cannot do this yet on AMQP. (I
> >> would like to though).
> >>
> >>
> >>
> >>
> >> But I'm always in advocating of tackling one thing at the time...
> >> first thing is to have some reference counting in place to tell us
> >> when to deallocate the memory used by the message, in such way it
> >> works with both paging and non paging... anything else then will be
> >> "relatively' easier.
> >>
> >>
> >>
> >> On Fri, May 12, 2017 at 2:56 AM, Michael André Pearce
> >>  wrote:
> >>>
> >>> Hi Clebert.
> >>>
> >>> +1 from me definitely.
> >>>
> >>> Agreed this def should target the server not the clients.
> >>>
> >>> Having the message / buffer used my message pooled would be great, as
> will reduce GC pressure.
> >>>
> >>> I would like to take that one step further and question if we could
> actually avoid copying the buffer contents at all on passing from/to netty.
> The zero-copy nivana.
> >>>
> >>> I know you state to have separate buffer pools. But if we could use
> the same memory address we can avoid the copy, reducing latency also. This
> could be done by sharing the buffer and the pool, or by using
> slice/duplicate retained.
> >>>
> >>> Cheers
> >>> Mike
> >>>
> >>>
> >>>
>  On 11 May 2017, at 23:13, Clebert Suconic 
> wrote:
> 
>  One thing I couldn't do before without some proper thinking was to use
>  a Pooled Buffer on the message bodies.
> 
>  It would actually rock out the perf numbers if that could be
> achieved...
> 
> 
>  I'm thinking this should be done on the server only. Doing it on the
>  client would mean to give some API to users to tell when the message
>  is gone and no longer needed.. I don't think we can do this with JMS
>  core, or any of the qpid clients... although we could think about an
>  API in the future for such thing.
> 
> 
> 
>  For the server: I would need to capture when the message is released..
>  the only pitfal for this would be paging as the Page read may come and
>  go... So, this will involve some work on making sure we would call the
>  proper places.
> 
> 
>  We would still need to copy from Netty Buffer into another
>  PooledBuffer as the Netty buffer would need to be a Native buffer
>  while the message a regular Buffer (non Native).
> 
> 
>  I am thinking of investing my time on this (even if my spare time if
>  needed be) after apache con next week.
> 
> 
>  This will certainly attract Francesco and Michael Pierce's attention..
>  but this would be a pretty good improvement towards even less GC
>  pressure.
> 
> 
> 
> 
> 
>  --
>  Clebert Suconic
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
>
>

Re: [DISCUSS] New logo discussion

[Martyn Taylor]

On Thu, May 25, 2017 at 1:03 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> Agree PNG / Vector is fairly a must. +1 that one
>
> Def need a logo / icon +1 that idea
>
> I'm not so sure we need to say the text and icon when togeather have to be
> separate, but should be seperatable , so can just use the icon or just text
> where needed
>
> Also suggest adding some starter ones so people don't feel like being the
> first.
>
> Here's my 5min circles and text starter to maybe help (you can tell it's
> not my day job ;) )
>
Your design skills are far superior to mine... ;).

>
> https://gist.github.com/michaelandrepearce/1dfc56f863db1cea20424c63733f64
> 70

Already a vast improvement on the current logo.


>
>
> Sent from my iPhone
>
> > On 24 May 2017, at 21:21, John D. Ament  wrote:
> >
> > Clebert,
> >
> > You may want to reach out to Sally as well to see what she can do to help
> > you guys get some traction in this area.  We just did this for incubator
> > and it looks pretty nice.
> >
> > John
> >
> > On Wed, May 24, 2017 at 4:00 PM Clebert Suconic <
> clebert.suco...@gmail.com>
> > wrote:
> >
> >> I talked to the PMC private list and we have consensus that starting
> >> this would be a good idea.
> >>
> >> Before we start a call for logo,  We need to define the requirements
> >> for the logo and what we will ask:
> >>
> >> I'm thinking of defining these as requirements:
> >>
> >> - vector based file (.svg) and .png images
> >> - an abstract image representing ActiveMQ would be awesome (we don't
> have
> >> one)
> >> - (in case of an abstract image, it would be nice to have the image
> >> and the name separated, like camel)
> >> - minimalistic and modern design.
> >>
> >>
> >>
> >> thoughts?
> >>
>

Re: [DISCUSS] New logo discussion

[Martyn Taylor]

On Wed, May 24, 2017 at 8:59 PM, Clebert Suconic 
wrote:

> I talked to the PMC private list and we have consensus that starting
> this would be a good idea.
>
> Before we start a call for logo,  We need to define the requirements
> for the logo and what we will ask:
>
> I'm thinking of defining these as requirements:
>
> - vector based file (.svg) and .png images
> - an abstract image representing ActiveMQ would be awesome (we don't have
> one)
> - (in case of an abstract image, it would be nice to have the image
> and the name separated, like camel)
> - minimalistic and modern design.
>
+1.

>
>
>
> thoughts?
>
Also, I'd say we want the new logo to be recognisable as ActiveMQ (and not
something completely new), so imo the new logo needs to at least nod toward
the existing ActiveMQ branding (perhaps this can be achieved using a
similar font, layout or colour scheme)?

Re: [DISCUSS] Artemis FQQN(Full Qualified Queue Name) implementation

[Martyn Taylor]

Hi Howard,

I was going to reply in line, but I think there's a fundamental assumption
you've made that's caused some confusion], so I'll reply here.

The purpose of FQQN is not to change the uniqueness of queue names across
addresses.  Each queue must have a globally unique name.  Instead, the
change is required as we've adopted a new addressing model, that creates
consistency across all the protocols.  In order to make this happen, a
client wanting to connect to a queue with name "foo" with address
"address", no longer subscribes to the queue name, it actually subscribes
to the "address".  This is where the ANYCAST and MULTICAST routing types
fit in.  To define queue like behaviour on the broker for an address
"address".  You define the following:



 1
queue), we require that the queue name match the address.  So for JMS you
currently need to define you queue like this:



 
 
   


There are other use cases in the documentation, so I'll not repeat here.

Long story short, you don't need to add any complex logic to handle the
"non uniqueness" of queue names.  Just parse the FQQN in the OpenWire
protocol, get the queue and address part, then do normal queue lookup on
the broker.  This has already been implemented for AMQP, look at the
ProtonServerSender/ReceiverContext for examples.

Cheers

On Thu, Apr 6, 2017 at 4:41 AM, Howard Gao  wrote:

> So I've been doing this FQQN support (ARTEMIS-1093) and I'd like
> to share my thoughts and current implementations of key functionalities,
> as well as some concerns. I'd appreciate any comments
> and adivces to make it better.
>
> More details about FQQN concepts please see official doc:
> https://github.com/apache/activemq-artemis/blob/master/
> docs/user-manual/en/address-model.md#fully-qualified-queue-names
>
> Simply put, a FQQN takes form of ::. It uniquely
> and explicitly identifies a 'queue' entity within a broker. With FQQN
> any clients can have access to any 'core' queues, so long as the addresses
> and queue names are known to them.
>
> For example, if a core queue "q1" is deployed on address "address1", its
> FQQN would be "address1::q1". A JMS consumer can receive messages that
> routed
> to "q1" by referencing the queue directly using its FQQN, as illustrated
> in the following code snippet:
>
> ...
> Queue q1 = session.createQueue("address1::q1");
> MessageConsumer consumer1 = session.createConsumer(q1);
> Message m = consumer1.receive(2000);
> ...
>
> Before FQQN, clients using any protocols only can access a queue by its
> name, which must be unique across all addresses within a broker. If we
> implement FQQN based on this uniqueness restriction, we don't need change
> any internal bindings management code. Simply removing the address prefix
> (like "address1::" in FQQN "address1::q1") from client requests and every
> thing would work just fine.
>
> However, with FQQN in place it is possible that queues of same names can be
> created on different addresses while still won't lose their uniqueness.
> For example, "address1::q1" and "address2::q1" are two distinct queues and
> can perfectly live within a broker together.

In this case, a client trying
> to access one of the queues can't just simply specify the queue name "q1".
> Because the broker wouldn't know which queue it refers to (ambiguity).
>
> To solve this issue, I need to add some 'extra' logic to the existing
> binding management. Here is what I do:
> (PR: https://github.com/apache/activemq-artemis/pull/1172 )


> 1. Inside broker it used a map (SimpleAddressManager.nameMap) to store
> bindings (queues) and the keys are queue names. As queue names will no
> longer be guaranteed to be unique with FQQN, a composite key (BindingKey)
> is introduced so that the address part of the queues will paticipate in
> key 'hash' and 'equals' calculation.


> 2. In order to detect 'ambiguous' binding queries, a new map called
> uniqueNameMap is added to SimpleAddressManager to keep the number of
> addresses a binding is bound to. For example if a queue "q1" is bound to
> both addresses "address1" and "address2", the number stored in this map for
> "q1" is 2 ("q1"->2).
>
> When a binding is added these two maps gets updated.
> To understand how it works consider the following scenarios:
>
> In all of the scenarios below suppose the broker have 3 queues
> "address1::q1", "address1::q2", "address2::q1"
>
> [Scenario 1] A client comes in requesting access to a queue by its name
> "q2".
> Broker first checks the uniqueNameMap and finds that there is only
> one binding for this queue name, no ambiguity, and it goes ahead to
> get the binding from nameMap and returns it.
>
> [Scenario 2] A client comes in requesting access to a queue by its FQQN
> "address2::q1". Because FQQN is used we don't need to check ambiguity
> this time. it therefore goes directly to find the binding in nameMap
> and returns it.
>
> [Scenario 3] A client comes in 

Re: [DISCUSS] Smoke tests

[Martyn Taylor]

OK let's move under tests/smoke in a subsequent patch (this PR has a lot of
code change and will probably result in conflicts if we hold out).

Cheers.

On Mon, Apr 3, 2017 at 12:43 PM, Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> We can move under tests/smoke.
>
> But we can do that later.  Please merge the current one.
>
>
> On Mon, Apr 3, 2017 at 7:39 AM Clebert Suconic <clebert.suco...@gmail.com>
> wrote:
>
> > I have a folder smoke.  A Readme saying it's intended as test on a real
> > life system.
> >
> >
> > If y don't like it there and care that much.   Please merge my current PR
> > and change it any way you like.
> >
> >
> >
> > On Mon, Apr 3, 2017 at 5:54 AM Martyn Taylor <mtay...@redhat.com> wrote:
> >
> > When I said "it shouldn't be part of the release", what I meant was that
> it
> > shouldn't be part of the built released examples.
> >
> > Unless of course it's written up as a proper example with a proper readme
> > with context and is appropriately named like all the other examples.
> What
> > I don't want to do is confuse users by having integration tests mixed in
> > with examples aimed for end users.  It's just going to cause confusion.
> >
> > On Mon, Apr 3, 2017 at 10:24 AM, nigro_franz <nigro@gmail.com>
> wrote:
> >
> > > Agree! It is a good idea indeed!
> > >
> > >
> > >
> > > --
> > > View this message in context: http://activemq.2283324.n4.
> > > nabble.com/DISCUSS-Smoke-tests-tp4724485p4724492.html
> > > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> > >
> >
> > --
> > Clebert Suconic
> >
> --
> Clebert Suconic
>

Re: [DISCUSS] Smoke tests

[Martyn Taylor]

When I said "it shouldn't be part of the release", what I meant was that it
shouldn't be part of the built released examples.

Unless of course it's written up as a proper example with a proper readme
with context and is appropriately named like all the other examples.  What
I don't want to do is confuse users by having integration tests mixed in
with examples aimed for end users.  It's just going to cause confusion.

On Mon, Apr 3, 2017 at 10:24 AM, nigro_franz  wrote:

> Agree! It is a good idea indeed!
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/DISCUSS-Smoke-tests-tp4724485p4724492.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [DISCUSS] Smoke tests

[Martyn Taylor]

Good idea Clebert.  We probably don't want to include these smoke tests as
part of the release, so can you ensure you don't include it in the examples
pom :)

Cheers

On Mon, Apr 3, 2017 at 1:56 AM, Clebert Suconic 
wrote:

> We always had the examples on Artemis playing a double thingy... being
> both an educational and documentational resource, and that has also
> saved us a few times from making changes that would invalidate
> configurations and the manual.
>
>
> However, to replicate ARTEMIS-1089 now, I couldn't easily produce a
> testcase for it.. Instead I wrote an example like code (using the same
> maven framework, and everything else).. but this time it doesn't have
> the purpose of documentation.
>
>
> for that reason I am creating a new folder ./smoke under examples, and
> I'm adding a readme.md as part of it.
>
>
>
> I'm mainly adding this discuss thread to suggest other people to do
> the same in certain cases where a testcase is hard to reproduce a
> production life scenario. Testcases are still the preferable way to
> replicate bugs.. but in certain cases this will help us eat our own
> dog food. (it certainly helped me).
>
> --
> Clebert Suconic
>

[ANNOUNCE] Apache Artemis 2.0.0

[Martyn Taylor]

All,

I am extremely pleased to announce the release of Apache Artemis 2.0.0.

This 2.0.0 release represents a major milestone for Apache Artemis and
contains a bunch of new features and performance enhancements.  See the
release notes for details.

The project website for Apache Artemis has been updated include this
release and can be found here:
http://activemq.apache.org/artemis/

A list of issues fixed in Apache Artemis 2.0.0 is available here:
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12338813
*

API and User documentation can be found here:
https://activemq.apache.org/artemis/docs.html

Regards
Martyn

[RESULT][VOTE] Apache Artemis 2.0.0

[Martyn Taylor]

Results of the Apache Artemis 2.0.0 release vote.

Vote passes with 4 +1 binding votes.

The following votes were received:

Binding:
+1 Timothy Bish
+1 Clebert Suconic
+1 Martyn Taylor
+1 Christopher Shannon

Non Binding:
+1 John Ament
+1 Francesco Nigro
+1 Howard Gao

Thank you to everyone who contributed and took the time to review the
release candidates and vote.

I'll move forward with the getting the release out and updating the
relevant documentation.

Regards
Martyn

Re: [DISCUSS] Single version docs on Artemis

[Martyn Taylor]

I'd prefer to keep the latest versions of docs for each minor release.  I'd
squash all the 1.5.x into just 1.5, but keep 1.0, 1.1 etc...  The 1.5 docs
may not be applicable to 1.4 due to the introduction of new features.  1.0
for example, is very different from 1.5, but we I feel we should still
provide docs for those users who have not been able to upgrade.

On a related note, (I can start a separate DISCUSS thread on this if people
prefer).

I'd like to also suggest that we stop distributing the documentation as
part of the release distribution and instead just provide links to the
latest versions.  Having the docs released as part of the binary and source
distribution, means that we need to do a full Artemis release just to get
doc changes out.  Instead I'd like to see docs either on their own release
cycle or just built periodically, housed somewhere and linked to from the
distribution.  Thoughts?

Regards
Martyn
On Mon, Mar 13, 2017 at 9:11 PM, Clebert Suconic 
wrote:

> Let's make the links 2.x and 1.x.  Immutable links makes it easier on
> google?
> On Mon, Mar 13, 2017 at 4:47 PM Timothy Bish  wrote:
>
> > On 03/13/2017 04:44 PM, Clebert Suconic wrote:
> > > Right now we have 10. And going up.
> > >
> > > 1.0, 1.1,   1.5.0 1.5.11.5.4. 2.0
> >
> > I think John is saying the same thing I said earlier, only keep 1.5.4
> > and 2.0.0 as those are the latest supported releases, when 1.5.5 ships
> > then drop 1.5.4 ...
> >
> > >
> > > On Mon, Mar 13, 2017 at 4:37 PM Timothy Bish 
> > wrote:
> > >
> > >> On 03/13/2017 04:07 PM, Clebert Suconic wrote:
> > >>> Sure.   Latest 1.x and latest 2.x.
> > >>>
> > >>>
> > >>>
> > >>> Just that it seems too much now.
> > >> Isn't that just two instances?  That doesn't seem like to much.
> > >>
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Mar 13, 2017 at 1:42 PM Jiri Danek 
> wrote:
> > >>>
> >  On Mon, Mar 13, 2017 at 6:27 PM, Clebert Suconic <
> >  clebert.suco...@gmail.com>
> >  wrote:
> > 
> > > I was wondering if we could / should update the docs page to only
> > > include the latest version (that is 2.0.0)... The docs are still
> > > maintained at the git, so you can always refer to the doc of the
> > > version you're using when you download.. or you can use links from
> > > github.
> > >
> >  It seems strange to maintain the 1.x release stream and not have
> >  documentation for it on the site. There should be at least the
> latest
> > >> 1,x
> >  and the latest 2.0 version.
> > 
> >  The projects whose documentation I often browse online all have
> > previous
> >  doc versions on the site, be it https://www.postgresql.org/docs/,
> > >> Python
> >  or
> >  readthedocs.io hosted sites like http://docs.pachyderm.io/en/
> stable/
> > >> (see
> >  the version picker at the bottom left).
> > 
> >  readthedocs.io sites also have a noticebar that alerts users that
> > they
> > >> are
> >  browsing documentation for older release; I once raised this as
> > feature
> >  request https://issues.apache.org/jira/browse/ARTEMIS-615
> > 
> > 
> > > That would also make it easier for web robots (google, etc)  to
> index
> > >> it.
> >  http://www.example.com/canonical-version-of-page/;
> >  rel="canonical" />
> > 
> >  in the HTML head section should take care of that. This is what
> >  readthedocs.io does.
> >  --
> >  Jiří Daněk
> >  Messaging QA
> > 
> > >>
> > >> --
> > >> Tim Bish
> > >> twitter: @tabish121
> > >> blog: http://timbish.blogspot.com/
> > >>
> > >> --
> > > Clebert Suconic
> > >
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> > --
> Clebert Suconic
>

Re: [RESULT] (was Re: [VOTE] Release ActiveMQ Artemis 1.5.4 (RC1))

[Martyn Taylor]

On Mon, Mar 13, 2017 at 12:55 PM, John D. Ament <johndam...@apache.org>
wrote:

> On Mon, Mar 13, 2017 at 8:37 AM Timothy Bish <tabish...@gmail.com> wrote:
>
> > On 03/13/2017 06:02 AM, Martyn Taylor wrote:
> > > John,
> > >
> > > The release artifacts have been uploaded dist.apache.org.  It'll
> > probably
> > > take a couple of days for the mirrors to catch up.
> >
> > 24 hours is usually more than enough time.
> >
> >
> The docs are uploaded.  I'll commit the landing page changes this evening.
>
Thanks.

>
> BTW, are the HTML files really hand edited?  E.g. this page
> http://activemq.apache.org/artemis/download.html

Unfortunately... yes.  It's a bit of a pain, but with a with of copy and
paste shouldn't take too long :).

The website needs a major overhaul imo and it'd be great to have these
pages automatically generated as part of that.

>
>
> John
>
>
> > > Thanks
> > >
> > >
> > >
> > > On Sat, Mar 11, 2017 at 5:44 PM, Clebert Suconic <
> > clebert.suco...@gmail.com>
> > > wrote:
> > >
> > >> Nice one.
> > >>
> > >>
> > >> Please do not send the Announce until the mirrors are updated.  Just a
> > >> friendly reminder.
> > >>
> > >>
> > >>
> > >>
> > >> On Sat, Mar 11, 2017 at 11:25 AM Martyn Taylor <mtay...@redhat.com>
> > wrote:
> > >>
> > >>> Thanks John.  I'll take care of moving the distributions on Monday
> > >> morning.
> > >>> Cheers.
> > >>>
> > >>> On Sat, Mar 11, 2017 at 2:35 PM, John D. Ament <
> johndam...@apache.org>
> > >>> wrote:
> > >>>
> > >>>> All,
> > >>>>
> > >>>> The vote passes with the following:
> > >>>>
> > >>>> +1 bindings from Clebert Suconic, Timothy Bish, Christopher Shannon,
> > >>> Martyn
> > >>>> Taylor
> > >>>> +1 non-binding from John D. Ament, Howard Gao, Francesco Nigro
> > >>>>
> > >>>> I'll release within maven, and update the website.  If someone can
> > take
> > >>>> care of moving the source release over.
> > >>>>
> > >>>> John
> > >>>>
> > >>>> On Tue, Mar 7, 2017 at 10:14 PM John D. Ament <
> johndam...@apache.org>
> > >>>> wrote:
> > >>>>
> > >>>>> Hello all,
> > >>>>>
> > >>>>> I'd like to propose an Apache Artemis 1.5.4 release (RC1).
> > >>>>>
> > >>>>> This revision release of Apache Artemis 1.5 contains a number of
> bug
> > >>>> fixes
> > >>>>> and improvements including:
> > >>>>>
> > >>>>> Bug
> > >>>>>   - [ARTEMIS-919] - Issues creating jms queues in core config in
> > >>>> broker.xml
> > >>>>> when hot reloading configuration
> > >>>>>   - [ARTEMIS-932] - 2 brokers can be started using the same store
> > >>>>>   - [ARTEMIS-950] - Change log level from INFO to WARN for "Invalid
> > >>> "host"
> > >>>>> value "0.0.0.0" detected for..." when Artemis is bound to 0.0.0.0
> > >>>>>   - [ARTEMIS-963] - ClassCastException in ActiveMQChannelHandler
> > >>>>>   - [ARTEMIS-969] - ReceiveMessage will expand unecessarily on core
> > >>>> protocol
> > >>>>>   - [ARTEMIS-974] - MQTT Will messages are not retained
> > >>>>>   - [ARTEMIS-976] - PostgresSequentialSequentialFileDriver
> > >> SQLProvider
> > >>>> NPE
> > >>>>>   - [ARTEMIS-982] - Deadlock on AMQP Close versus Delivery on AMQP
> > >>>>>   - [ARTEMIS-989] - Individual Acknowledge:
> > >>>>> ActiveMQConnectionFactory.createContext(final int sessionMode)
> > >> throws
> > >>>>> exception for ActiveMQJMSConstants.INDIVIDUAL_ACKNOWLEDGE
> > >>>>>   - [ARTEMIS-991] - Null dereference after hitting Ctrl+d when
> > >> prompted
> > >>>> for
> > >>>>> password in `artemis create`
> > >>>>>   - [ARTEMIS-992] - NPE and other trouble when cluster-connection
> has
> > >&g

Re: [RESULT] (was Re: [VOTE] Release ActiveMQ Artemis 1.5.4 (RC1))

[Martyn Taylor]

John,

The release artifacts have been uploaded dist.apache.org.  It'll probably
take a couple of days for the mirrors to catch up.

Thanks



On Sat, Mar 11, 2017 at 5:44 PM, Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> Nice one.
>
>
> Please do not send the Announce until the mirrors are updated.  Just a
> friendly reminder.
>
>
>
>
> On Sat, Mar 11, 2017 at 11:25 AM Martyn Taylor <mtay...@redhat.com> wrote:
>
> > Thanks John.  I'll take care of moving the distributions on Monday
> morning.
> >
> > Cheers.
> >
> > On Sat, Mar 11, 2017 at 2:35 PM, John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > All,
> > >
> > > The vote passes with the following:
> > >
> > > +1 bindings from Clebert Suconic, Timothy Bish, Christopher Shannon,
> > Martyn
> > > Taylor
> > > +1 non-binding from John D. Ament, Howard Gao, Francesco Nigro
> > >
> > > I'll release within maven, and update the website.  If someone can take
> > > care of moving the source release over.
> > >
> > > John
> > >
> > > On Tue, Mar 7, 2017 at 10:14 PM John D. Ament <johndam...@apache.org>
> > > wrote:
> > >
> > > > Hello all,
> > > >
> > > > I'd like to propose an Apache Artemis 1.5.4 release (RC1).
> > > >
> > > > This revision release of Apache Artemis 1.5 contains a number of bug
> > > fixes
> > > > and improvements including:
> > > >
> > > > Bug
> > > >  - [ARTEMIS-919] - Issues creating jms queues in core config in
> > > broker.xml
> > > > when hot reloading configuration
> > > >  - [ARTEMIS-932] - 2 brokers can be started using the same store
> > > >  - [ARTEMIS-950] - Change log level from INFO to WARN for "Invalid
> > "host"
> > > > value "0.0.0.0" detected for..." when Artemis is bound to 0.0.0.0
> > > >  - [ARTEMIS-963] - ClassCastException in ActiveMQChannelHandler
> > > >  - [ARTEMIS-969] - ReceiveMessage will expand unecessarily on core
> > > protocol
> > > >  - [ARTEMIS-974] - MQTT Will messages are not retained
> > > >  - [ARTEMIS-976] - PostgresSequentialSequentialFileDriver
> SQLProvider
> > > NPE
> > > >  - [ARTEMIS-982] - Deadlock on AMQP Close versus Delivery on AMQP
> > > >  - [ARTEMIS-989] - Individual Acknowledge:
> > > > ActiveMQConnectionFactory.createContext(final int sessionMode)
> throws
> > > > exception for ActiveMQJMSConstants.INDIVIDUAL_ACKNOWLEDGE
> > > >  - [ARTEMIS-991] - Null dereference after hitting Ctrl+d when
> prompted
> > > for
> > > > password in `artemis create`
> > > >  - [ARTEMIS-992] - NPE and other trouble when cluster-connection has
> > bad
> > > > connector-ref
> > > >  - [ARTEMIS-998] - NPE when using JDBCFileDriver when Blob is null
> > > >  - [ARTEMIS-1017] - Wrong error message when default destination for
> > > > producer is not specified
> > > >  - [ARTEMIS-1020] - CDI Extension doesn't discover Configuration via
> > CDI
> > > > producers
> > > >
> > > > Improvement
> > > >  - [ARTEMIS-1002] - ActiveMQBuffers creates a new netty pool
> increasing
> > > > memory footprint
> > > >  - [ARTEMIS-1006] - JDBC Storage Manager to show SQLExceptions on
> logs
> > > >
> > > > New Feature
> > > >  - [ARTEMIS-999] - Support Oracle12C for Artemis JDBC Store
> > > >
> > > > Task
> > > >  - [ARTEMIS-995] - Cleanup test suite
> > > >
> > > > The release notes can be found here:
> > > > *
> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > projectId=12315920=12339158
> > > > <
> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > projectId=12315920=12339158
> > > > >*
> > > >
> > > > The binary distributions can be found here:
> > > >
> > > > https://repository.apache.org/content/repositories/
> > > orgapacheactivemq-1119/org/apache/activemq/apache-artemis/1.5.4/
> > > >
> > > > The source archives can be found here:
> > > >
> > > > https://repository.apache.org/content/repositories/
> > > orgapacheactivemq-1119/org/apache/activemq/apache-artemis/1.5.4/
> > > >
> > > > The Maven repository is here:
> > > > https://repository.apache.org/content/repositories/
> > > orgapacheactivemq-1119/
> > > >
> > > > The source tag:
> > > > *
> > > > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> > > git;a=tag;h=refs/tags/1.5.4
> > > > <
> > > > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> > > git;a=tag;h=refs/tags/1.5.4
> > > > >*
> > > >
> > > > As this is only a revision release, only doc and download links needs
> > to
> > > be
> > > > updated in the website.  Either I will perform the updates, or ask
> > > someone
> > > > with appropriate karma to do so.
> > > >
> > > > The vote will remain open for 72 hours.
> > > >
> > > > [ ] +1 approve the release as Apache Artemis 1.5.4
> > > > [ ] +0 no opinion
> > > > [ ] -1 disapprove (and reason why)
> > > >
> > > > Here's my (non-binding) +1
> > > >
> > > > Regards,
> > > >
> > > > John
> > > >
> > > > PS - Please check prior mail for my key.
> > > >
> > >
> >
> --
> Clebert Suconic
>

Re: [RESULT] (was Re: [VOTE] Release ActiveMQ Artemis 1.5.4 (RC1))

[Martyn Taylor]

Thanks John.  I'll take care of moving the distributions on Monday morning.

Cheers.

On Sat, Mar 11, 2017 at 2:35 PM, John D. Ament <johndam...@apache.org>
wrote:

> All,
>
> The vote passes with the following:
>
> +1 bindings from Clebert Suconic, Timothy Bish, Christopher Shannon, Martyn
> Taylor
> +1 non-binding from John D. Ament, Howard Gao, Francesco Nigro
>
> I'll release within maven, and update the website.  If someone can take
> care of moving the source release over.
>
> John
>
> On Tue, Mar 7, 2017 at 10:14 PM John D. Ament <johndam...@apache.org>
> wrote:
>
> > Hello all,
> >
> > I'd like to propose an Apache Artemis 1.5.4 release (RC1).
> >
> > This revision release of Apache Artemis 1.5 contains a number of bug
> fixes
> > and improvements including:
> >
> > Bug
> >  - [ARTEMIS-919] - Issues creating jms queues in core config in
> broker.xml
> > when hot reloading configuration
> >  - [ARTEMIS-932] - 2 brokers can be started using the same store
> >  - [ARTEMIS-950] - Change log level from INFO to WARN for "Invalid "host"
> > value "0.0.0.0" detected for..." when Artemis is bound to 0.0.0.0
> >  - [ARTEMIS-963] - ClassCastException in ActiveMQChannelHandler
> >  - [ARTEMIS-969] - ReceiveMessage will expand unecessarily on core
> protocol
> >  - [ARTEMIS-974] - MQTT Will messages are not retained
> >  - [ARTEMIS-976] - PostgresSequentialSequentialFileDriver SQLProvider
> NPE
> >  - [ARTEMIS-982] - Deadlock on AMQP Close versus Delivery on AMQP
> >  - [ARTEMIS-989] - Individual Acknowledge:
> > ActiveMQConnectionFactory.createContext(final int sessionMode) throws
> > exception for ActiveMQJMSConstants.INDIVIDUAL_ACKNOWLEDGE
> >  - [ARTEMIS-991] - Null dereference after hitting Ctrl+d when prompted
> for
> > password in `artemis create`
> >  - [ARTEMIS-992] - NPE and other trouble when cluster-connection has bad
> > connector-ref
> >  - [ARTEMIS-998] - NPE when using JDBCFileDriver when Blob is null
> >  - [ARTEMIS-1017] - Wrong error message when default destination for
> > producer is not specified
> >  - [ARTEMIS-1020] - CDI Extension doesn't discover Configuration via CDI
> > producers
> >
> > Improvement
> >  - [ARTEMIS-1002] - ActiveMQBuffers creates a new netty pool increasing
> > memory footprint
> >  - [ARTEMIS-1006] - JDBC Storage Manager to show SQLExceptions on logs
> >
> > New Feature
> >  - [ARTEMIS-999] - Support Oracle12C for Artemis JDBC Store
> >
> > Task
> >  - [ARTEMIS-995] - Cleanup test suite
> >
> > The release notes can be found here:
> > *
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12315920=12339158
> > <
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12315920=12339158
> > >*
> >
> > The binary distributions can be found here:
> >
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1119/org/apache/activemq/apache-artemis/1.5.4/
> >
> > The source archives can be found here:
> >
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1119/org/apache/activemq/apache-artemis/1.5.4/
> >
> > The Maven repository is here:
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-1119/
> >
> > The source tag:
> > *
> > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> git;a=tag;h=refs/tags/1.5.4
> > <
> > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> git;a=tag;h=refs/tags/1.5.4
> > >*
> >
> > As this is only a revision release, only doc and download links needs to
> be
> > updated in the website.  Either I will perform the updates, or ask
> someone
> > with appropriate karma to do so.
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1 approve the release as Apache Artemis 1.5.4
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my (non-binding) +1
> >
> > Regards,
> >
> > John
> >
> > PS - Please check prior mail for my key.
> >
>

[VOTE] Apache Artemis 2.0.0

[Martyn Taylor]

Hello all,

I'd like to propose an Apache Artemis 2.0.0 release.  This will be first
major bump for Apache Artemis which represents a major milestone.

The two major pieces of work in this major release are:

* A complete overhaul of the addressing model which is now much more
powerful, gives a better cross protocol experience and opens the door to
further feature.

* Persistence of messages in their raw state.  This has been a significant
refactor, which enables significant increases performance, the AMQP
protocol is now almost 10x as fast!

On top of these two major features, there has been a **huge** amount of
work on improvements, fixes and features.  Check out the release notes for
more information.

The release notes can be found here:
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12338813
*

The binary distributions can be found here:
*https://repository.apache.org/content/repositories/orgapacheactivemq-1121/org/apache/activemq/apache-artemis/2.0.0/
*

The source archives can be found here:
*https://repository.apache.org/content/repositories/orgapacheactivemq-1121/org/apache/activemq/apache-artemis/2.0.0/
*

The Maven repository is here:
*https://repository.apache.org/content/repositories/orgapacheactivemq-1121
*

The source tag:
*https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/2.0.0
*

I will update the website after the vote.

The vote will remain open for 72 hours.

[ ] +1 approve the release as Apache Artemis 2.0.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my (binding) +1

Regards

Re: [VOTE] Release ActiveMQ Artemis 1.5.4 (RC1)

[Martyn Taylor]

+1 (Binding)

Thanks John!






On Thu, Mar 9, 2017 at 11:59 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> +1
>
> On Wed, Mar 8, 2017 at 8:31 PM, Timothy Bish  wrote:
>
> > +1
> >
> > * Checked signature and checksums
> > * Built from source and ran some tests
> > * Ran the binary distro broker and ran some samples against it.
> > * Checked license and notice files
> >
> > On 03/07/2017 10:14 PM, John D. Ament wrote:
> >
> >> Hello all,
> >>
> >> I'd like to propose an Apache Artemis 1.5.4 release (RC1).
> >>
> >> This revision release of Apache Artemis 1.5 contains a number of bug
> fixes
> >> and improvements including:
> >>
> >> Bug
> >>   - [ARTEMIS-919] - Issues creating jms queues in core config in
> >> broker.xml
> >> when hot reloading configuration
> >>   - [ARTEMIS-932] - 2 brokers can be started using the same store
> >>   - [ARTEMIS-950] - Change log level from INFO to WARN for "Invalid
> "host"
> >> value "0.0.0.0" detected for..." when Artemis is bound to 0.0.0.0
> >>   - [ARTEMIS-963] - ClassCastException in ActiveMQChannelHandler
> >>   - [ARTEMIS-969] - ReceiveMessage will expand unecessarily on core
> >> protocol
> >>   - [ARTEMIS-974] - MQTT Will messages are not retained
> >>   - [ARTEMIS-976] - PostgresSequentialSequentialFileDriver SQLProvider
> >> NPE
> >>   - [ARTEMIS-982] - Deadlock on AMQP Close versus Delivery on AMQP
> >>   - [ARTEMIS-989] - Individual Acknowledge:
> >> ActiveMQConnectionFactory.createContext(final int sessionMode) throws
> >> exception for ActiveMQJMSConstants.INDIVIDUAL_ACKNOWLEDGE
> >>   - [ARTEMIS-991] - Null dereference after hitting Ctrl+d when prompted
> >> for
> >> password in `artemis create`
> >>   - [ARTEMIS-992] - NPE and other trouble when cluster-connection has
> bad
> >> connector-ref
> >>   - [ARTEMIS-998] - NPE when using JDBCFileDriver when Blob is null
> >>   - [ARTEMIS-1017] - Wrong error message when default destination for
> >> producer is not specified
> >>   - [ARTEMIS-1020] - CDI Extension doesn't discover Configuration via
> CDI
> >> producers
> >>
> >> Improvement
> >>   - [ARTEMIS-1002] - ActiveMQBuffers creates a new netty pool increasing
> >> memory footprint
> >>   - [ARTEMIS-1006] - JDBC Storage Manager to show SQLExceptions on logs
> >>
> >> New Feature
> >>   - [ARTEMIS-999] - Support Oracle12C for Artemis JDBC Store
> >>
> >> Task
> >>   - [ARTEMIS-995] - Cleanup test suite
> >>
> >> The release notes can be found here:
> >> *
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> >> ctId=12315920=12339158
> >> <
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> >> ctId=12315920=12339158
> >>
> >>> *
> >>>
> >> The binary distributions can be found here:
> >> https://repository.apache.org/content/repositories/orgapache
> >> activemq-1119/org/apache/activemq/apache-artemis/1.5.4/
> >>
> >> The source archives can be found here:
> >> https://repository.apache.org/content/repositories/orgapache
> >> activemq-1119/org/apache/activemq/apache-artemis/1.5.4/
> >>
> >> The Maven repository is here:
> >> https://repository.apache.org/content/repositories/orgapache
> >> activemq-1119/
> >>
> >> The source tag:
> >> *
> >> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.g
> >> it;a=tag;h=refs/tags/1.5.4
> >> <
> >> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.g
> >> it;a=tag;h=refs/tags/1.5.4
> >>
> >>> *
> >>>
> >> As this is only a revision release, only doc and download links needs to
> >> be
> >> updated in the website.  Either I will perform the updates, or ask
> someone
> >> with appropriate karma to do so.
> >>
> >> The vote will remain open for 72 hours.
> >>
> >> [ ] +1 approve the release as Apache Artemis 1.5.4
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> Here's my (non-binding) +1
> >>
> >> Regards,
> >>
> >> John
> >>
> >> PS - Please check prior mail for my key.
> >>
> >>
> >
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> >
>

Re: [DISCUSS] ActiveMQ Artemis 2.x stream

[Martyn Taylor]

Mirek,

I'd prefer not to change the default value, but instead make our
configuration options include a units parameter.  If we add a units
parameter like discussed above users can specify however which way they'd
like to time slice their window, changing it to only support 5 minutes
might be great for you, but not so great for other users.

I think this applies to many other configuration options where units are
currently fixed.  I don't think we need to break and API or configuration
to resolve this, let's just extend it to give users more control.

Cheers
Martyn

On Wed, Mar 8, 2017 at 6:57 AM, Miroslav Novak <mno...@redhat.com> wrote:

> I would like only to change default value for attribute
> "slow-consumer-check-period' from 5 seconds to 5 minutes. I believe it was
> original intention. Calculating msg/s rate based on 5 second time window
> might be very inaccurate.


> Mirek
>
> - Original Message -
> > From: "Martyn Taylor" <mtay...@redhat.com>
> > To: dev@activemq.apache.org
> > Sent: Tuesday, March 7, 2017 5:48:42 PM
> > Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
> >
> > This specific field is message consumption rate, i.e. no message per time
> > window.  So we would need something like:
> >
> > 10msg/minute etc...
> >
> > I don't mind either way, as a unit parameter or as part of the value.
> > Either way, we don't need to break configuration to add this improvement.
> >
> > Cheers
> >
> > On Tue, Mar 7, 2017 at 4:11 PM, Clebert Suconic <
> clebert.suco...@gmail.com>
> > wrote:
> >
> > > On Tue, Mar 7, 2017 at 11:06 AM Justin Bertram <jbert...@apache.org>
> > > wrote:
> > >
> > > > > 10 consumer-threshold>
> > > >
> > > > I would suggest something more akin to what was implemented for byte
> > > > fields (i.e. support notation like "KB", "M", "gb", etc.).  For
> example:
> > > >
> > > >   10m
> > > >
> > > > or
> > > >
> > > >   30s
> > >
> > >
> > >
> > >
> > >
> > >
> > > +1000
> > >
> > > >
> > > > And default to whatever time-unit is used now.
> > > >
> > > >
> > > > Justin
> > > >
> > > >
> > > > - Original Message -
> > > > From: "Jiri Danek" <jda...@redhat.com>
> > > > To: dev@activemq.apache.org
> > > > Sent: Tuesday, March 7, 2017 10:01:13 AM
> > > > Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
> > > >
> > > > On Tue, Mar 7, 2017 at 4:23 PM, Martyn Taylor <mtay...@redhat.com>
> > > wrote:
> > > >
> > > > > Hi Jiri,
> > > > >
> > > > > Thanks for bringing this up again.
> > > > >
> > > > > One approach to this that avoids having to add new settings or
> change
> > > the
> > > > > default values of current config  would be to add a unit parameter
> to
> > > the
> > > > > configuration element.  For example
> > > > >
> > > > > 
> > > > > 10 consumer-threshold>
> > > > >
> > > > > This is just an example, but we could standardise across all
> > > > configuraiton
> > > > > options by just passing in "unit".
> > > > >
> > > > > This way users are free to express units that they are familiar
> with
> > > > > (msg/s) for example is a typical measurement, however, it could be
> > > > messages
> > > > > per minute or what ever you want.
> > > > >
> > > > > Does this sound reasonable?
> > > > >
> > > >
> > > > Hi, yes, that would resolve the usecase I had in mind in such a way
> that
> > > > current configuration files stay compatible. Sorry for derailing the
> 2.x
> > > > stream thread. I am looking forward to that release soonest.
> > > >
> > > > Best of wishes,
> > > >
> > > >
> > > > >
> > > > > Cheers
> > > > >
> > > > > On Tue, Mar 7, 2017 at 2:12 PM, Jiri Danek <jda...@redhat.com>
> wrote:
> > > > >
> > > > > > I somehow buried this thread, sorry...
> > > > > >
> > > > > > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
&g

Re: [DISCUSS] ActiveMQ Artemis 2.x stream

[Martyn Taylor]

This specific field is message consumption rate, i.e. no message per time
window.  So we would need something like:

10msg/minute etc...

I don't mind either way, as a unit parameter or as part of the value.
Either way, we don't need to break configuration to add this improvement.

Cheers

On Tue, Mar 7, 2017 at 4:11 PM, Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> On Tue, Mar 7, 2017 at 11:06 AM Justin Bertram <jbert...@apache.org>
> wrote:
>
> > > 10
> >
> > I would suggest something more akin to what was implemented for byte
> > fields (i.e. support notation like "KB", "M", "gb", etc.).  For example:
> >
> >   10m
> >
> > or
> >
> >   30s
>
>
>
>
>
>
> +1000
>
> >
> > And default to whatever time-unit is used now.
> >
> >
> > Justin
> >
> >
> > - Original Message -
> > From: "Jiri Danek" <jda...@redhat.com>
> > To: dev@activemq.apache.org
> > Sent: Tuesday, March 7, 2017 10:01:13 AM
> > Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
> >
> > On Tue, Mar 7, 2017 at 4:23 PM, Martyn Taylor <mtay...@redhat.com>
> wrote:
> >
> > > Hi Jiri,
> > >
> > > Thanks for bringing this up again.
> > >
> > > One approach to this that avoids having to add new settings or change
> the
> > > default values of current config  would be to add a unit parameter to
> the
> > > configuration element.  For example
> > >
> > > 
> > > 10
> > >
> > > This is just an example, but we could standardise across all
> > configuraiton
> > > options by just passing in "unit".
> > >
> > > This way users are free to express units that they are familiar with
> > > (msg/s) for example is a typical measurement, however, it could be
> > messages
> > > per minute or what ever you want.
> > >
> > > Does this sound reasonable?
> > >
> >
> > Hi, yes, that would resolve the usecase I had in mind in such a way that
> > current configuration files stay compatible. Sorry for derailing the 2.x
> > stream thread. I am looking forward to that release soonest.
> >
> > Best of wishes,
> >
> >
> > >
> > > Cheers
> > >
> > > On Tue, Mar 7, 2017 at 2:12 PM, Jiri Danek <jda...@redhat.com> wrote:
> > >
> > > > I somehow buried this thread, sorry...
> > > >
> > > > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> > > > clebert.suco...@gmail.com
> > > > > wrote:
> > > >
> > > > > you're right.. I was just trying to understand Jiri's comment, and
> > not
> > > > > actually make an evaluation on the feature.
> > > > >
> > > >
> > > > When I wrote the comment, I was confused about the units. I somehow
> > > thought
> > > > that both  and 
> > were
> > > > meant to be in minutes, but by some mistake it got coded in seconds
> and
> > > > then it was not possible to change it because of backwards
> > > compatibility. I
> > > > thought that 2.0.0 release could be a good point to make it right.
> > > >
> > > > In fact, I think that  should be in minutes,
> > > > because if it is in seconds, the lowest message rate that it is
> > possible
> > > to
> > > > specify is 1 msg/s. I imagine it may be too high for some users who
> > send
> > > > very large messages or messages where processing of each takes a very
> > > long
> > > > time. Minutes as a unit would increase the range of possible values.
> > > >
> > > > I'll think more about this and either start a new thread, or wait for
> > > Miro
> > > > to start it (in case he feels the need to discuss the slow consumers
> > > > feature in relation to the Jira he opened), or just leave it be.
> > > > --
> > > > Jiří Daněk
> > > > Messaging QA
> > > >
> > >
> >
> >
> >
> > --
> > Jiří Daněk
> > Messaging QA
> >
> --
> Clebert Suconic
>

Re: [DISCUSS] ActiveMQ Artemis 2.x stream

[Martyn Taylor]

Hi Jiri,

Thanks for bringing this up again.

One approach to this that avoids having to add new settings or change the
default values of current config  would be to add a unit parameter to the
configuration element.  For example


10

This is just an example, but we could standardise across all configuraiton
options by just passing in "unit".

This way users are free to express units that they are familiar with
(msg/s) for example is a typical measurement, however, it could be messages
per minute or what ever you want.

Does this sound reasonable?

Cheers

On Tue, Mar 7, 2017 at 2:12 PM, Jiri Danek  wrote:

> I somehow buried this thread, sorry...
>
> On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> clebert.suco...@gmail.com
> > wrote:
>
> > you're right.. I was just trying to understand Jiri's comment, and not
> > actually make an evaluation on the feature.
> >
>
> When I wrote the comment, I was confused about the units. I somehow thought
> that both  and  were
> meant to be in minutes, but by some mistake it got coded in seconds and
> then it was not possible to change it because of backwards compatibility. I
> thought that 2.0.0 release could be a good point to make it right.
>
> In fact, I think that  should be in minutes,
> because if it is in seconds, the lowest message rate that it is possible to
> specify is 1 msg/s. I imagine it may be too high for some users who send
> very large messages or messages where processing of each takes a very long
> time. Minutes as a unit would increase the range of possible values.
>
> I'll think more about this and either start a new thread, or wait for Miro
> to start it (in case he feels the need to discuss the slow consumers
> feature in relation to the Jira he opened), or just leave it be.
> --
> Jiří Daněk
> Messaging QA
>

Re: [DISCUSS] ActiveMQ Artemis 2.x stream

[Martyn Taylor]

Franz,

Contributions to documentation is always welcomed :).  A scan of the
persistence layer and journal docs would be really useful.  Thanks

On Tue, Mar 7, 2017 at 12:30 PM, nigro_franz  wrote:

> An awesome work Clebert!
> And to everyone that has made this master filled of such great stuff :)
> Martyn, do u need an hand on the doc?
> In particular the journal type part is something that I was pretty involved
> :P
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/DISCUSS-ActiveMQ-Artemis-2-x-stream-tp4721815p4723170.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

[HEADS-UP] Apache Artemis 2.0.0

[Martyn Taylor]

All,

As many of you are already aware, Apache Artemis has been developing some
great new features including a new and improved addressing model that lends
itself well to cross protocol and advance features like exclusive consumer
queues, configuration derived semantics for addresses and so on. There's
also been a ton of improvements around our persistence layer that has
resulted in significant perf gains for non CORE protocols like AMQP.
There's also been a great deal of other work that's been on going including
stablising protocol support including MQTT and OpenWire, Security layer
improvements and many other bug fixes and improvements.

Our master branch is now in a stable state now, no more API breakages or
data format changes are scheduled to take place.  Therefore, I believe now
is a good time to do an Apache Artemis 2.0.0 release and get all the great
stuff we've all been working on into the hands of users.

Before we do so. I think now is a good time to revisit areas like
documentation and examples to ensure everything is up to date and in good
shape, before any major release takes place.  I'm going to spend some time
over the next couple of days working on this and would welcome any other
contributions to this area.

If anyone else has any work they'd like to get into an Apache Artemis 2.0.0
now would be a great time.  I plan on cutting a 2.0.0 release candidate in
a few days time.

Regards
Martyn

Re: Artemis 1.5.4 release?

[Martyn Taylor]

Yes.  There are users who reported issues that have been fixed and ported
to the 1.x branch.  Let's get a 1.5.4 out the door asap to get these users
unblocked.

Cheers

On Mon, Mar 6, 2017 at 11:45 PM, John D. Ament 
wrote:

> On Mon, Mar 6, 2017 at 6:42 PM Clebert Suconic 
> wrote:
>
> > >>
> > > Big +1
> > > Even if we have a 2.0 coming soon, maintaining old versions should be
> > easy
> > > enough to help those that may need it.
> >
> >
> > I have been supporter of 1.x for a while.. I wouldn't let it go away
> > for sure. I was just afraid of spamming too many releases all at once.
> > it was a new thing for me.. didn't mean to imply I'm not supporting
> > it..
> >
> >
> > >
> > > So far it sounds like there would be no objections to cutting the
> current
> > > 1.x branch as a 1.5.4, so I can plan to start that process tomorrow
> > evening.
> >
> > It would be actually awesome if you dit it actually. consider this
> > thread a HEADS UP already. 1.x is in good shape for a release.
> >
>
>
> I did just resolve an issue I saw you commit with Jiri earlier.  There's 2
> still open with fix versions of 1.5.4.  1 looks like the user has a
> permissions change that went in to fix it so maybe not critical, the other
> I'll wait for Justin to comment on..
>
> https://s.apache.org/artemis-v154
>
> John
>

Re: [DISCUSS] ActiveMQ Artemis 2.x stream

[Martyn Taylor]

Great work Clebert.  I know this was a long hard slog.  I'm going to send a
2.0.0 HEADSUP later today.  I'm really excited to get all the great stuff
we've been doing on master into the hands of users.

I think now is a good time to revisit our documentation and examples to
ensure everything is up to date.  I'm going to spend some time on this
today and tomorrow.

On Mon, Mar 6, 2017 at 4:13 PM, Clebert Suconic 
wrote:

> As you guys have seen, my work now arrived on master.
>
> Any further improvements now won't break any compatibility or anything.
>
> After this I think it's time to put something out and keep working on
> master as usual.
>
> On Fri, Feb 10, 2017 at 5:56 PM, Clebert Suconic
>  wrote:
> > although maybe giving this power to the user may change certain
> > semantics? things that are supposed to run fast could eventually take
> > much longer.
> >
> >
> > But the user would be in control.
> >
> >
> > Dunno, that's splitting the conversation on the 2.x discussion already.
> >
> > On Fri, Feb 10, 2017 at 5:54 PM, Clebert Suconic
> >  wrote:
> >>> The two properties are pretty straight-forward, and I personally don't
> see how making them use the same time unit makes things simpler.  Granting
> such
> >>
> >> you're right.. I was just trying to understand Jiri's comment, and not
> >> actually make an evaluation on the feature.
> >>
> >>  If we were to make any changes, I would change all properties
> >> that refer to time to also include the time unit on them. That way the
> >> user would be more free to make any changes. 
> >>
> >>
> >>
> >> Example: 5s
> >>
> >>
> >>
> >>
> >> Just an idea though!
> >>
> >>
> >>
> >> If not, I would keep it as is... as it wouldn't bring much value
> otherwise.
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic
>

Re: What is the current status and plans for the web-console?

[Martyn Taylor]

Sounds like a great idea.  Cheers.

On Thu, Mar 2, 2017 at 3:37 PM, Christian Schneider  wrote:

> That sounds good. In the worst case we learned something in the best case
> we got the start of a good console.
>
> Christian
>
>
> On 02.03.2017 03:16, Clebert Suconic wrote:
>
>> What about this .
>>
>>
>> I want to learn something knew :) and I want t a break after what I'm
>> doing
>> now.
>>
>>
>>
>> Let's try making a prototype around next month.  (April)
>>
>> If it gets too difficult we go back to the hawt io road.
>>
>>
>> 
>>
>>
>>
>>
>> On Wed, Feb 22, 2017 at 2:56 PM Clebert Suconic <
>> clebert.suco...@gmail.com>
>> wrote:
>>
>> I liked Martyn's proposal for being a cool thing :)
>>>
>>>
>>> Just looked at this thing he mentioned (bootstrap).. man.. it's really
>>> cool...
>>> http://getbootstrap.com/getting-started/
>>>
>>>
>>> I'm not writing software just to be cool... but a great console would
>>> definitely improve things...
>>>
>>>
>>> One thing with a great UI though... our website still sucks :)
>>>
>>>
>>> - It provides a framework for plugins. So you can have one console that
 gives you access to ActiveMQ but also to other modules in your system
 - It uses jolokia to access the existing JMX layer over REST. So we do

>>> not
>>>
 need to create an additional REST layer for the console on the AMQ and
 Artemis side
 - Uses a html/javascript client (Angular). So the client side is easy to
 install on any server

 So if we do not write a Hawtio plugin then we should still consider to

>>> use
>>>
 jolokia to avoid overhead on the server side.
 I also think a framework to hook other plugins in would be great but for
 just the activemq and artemis consoles it is not absolutely necessary.

>>> +1... although I strongly encourage to keep the bits isolated. Not
>>> only for easy switch between AMQ5 and Artemis, but eventually we could
>>> include other technologies available on the console. (examples: AMQP
>>> Management, JMX, some consoles standard that I don't remember now, or
>>> any other thing yet to be invented)..   All I'm asking is for standard
>>> OO encapsulation.
>>>
>>> So ideally I would like to have something like Hatwio at apache as a

>>> generic
>>>
 base for a console where all apache projects can hook in via plugins.
 Unfortunately this is a lot of effort and I am not sure if we find
 enough
 manpower to do it.  It would also be a project on its own and should not

>>> be
>>>
 done at activemq.

>>>
>>>
>>> . if I had the time. :/
>>>
>>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: What is the current status and plans for the web-console?

[Martyn Taylor]

On Fri, Feb 17, 2017 at 5:23 PM, Christian Schneider <
ch...@die-schneider.net> wrote:

> How about creating a hawtio plugin for activemq and artemis at apache


So my opinion on this...

I feel quite passionately about creating a really great UX for both
ActiveMQ and Artemis and I'm not sure that a HawtIO plugin is what I'd
hoped for when we started talking about an ActiveMQ console.  I think we
could build something that is more focused and much more UX driven than the
ActiveMQ HawtIO plugins that have been created outside Apache.

I'd much prefer to see a console built specifically for the messaging
space.  With something focused solely on messaging, we can think about the
best way to model/manage messaging concepts and how to expose these things
to the end users.  My view is that we either consider some of the other
frameworks like the ones mentioned in this thread, or (my first preference)
would be to go down the route of building our own, something specific to
messaging, based on technologies like HTML5/JS + Bootstrap with the
back-end being made plugable so we could manage both ActiveMQ 5.x and
Artemis brokers.

if redhat does not donate these? -- which would of course be the best
> option.
>
I'd prefer not to go down this route, but, if the community decide this is
the way forward, then I don't think this would be a problem.

>
> I personally would be fine with the hawtio core not being at apache if the
> specific plugins are here. So we have most of the control without trying to
> replicate hawtio.
> In a chat with Dan he added that hawtio must be skinnable enough to have
> an apache look. I agree with that.
>
> Christian
>
>
> On 17.02.2017 15:39, Clebert Suconic wrote:
>
>> *AND* all of the ActiveMQ/Artemis related bits are written and maintained
>>> here at Apache as part of this community.  How the queues and brokers and
>>> such are presented to the user is completely under the control of this
>>> community.
>>>
>>> In other words: we don’t take the activemq plugin or whatever they have
>>> and use it as is. (Unless they want to donate it to this community)
>>>
>> Of course!
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: Artemis MQTT durable messages and Topics

[Martyn Taylor]

Hi Fabio,

Right now there is no way to specify the durability of just the Retained
messages.  It's something we can easily add as a new feature.  Please open
a JIRA and we'll look to get it implemented.

Regards
Martyn

On Tue, Feb 21, 2017 at 10:08 AM, fabio72 
wrote:

> hi Justin,
> after connecting via jmx we saw that all topics are durable (indipendently
> from qos); analyzing the journal (using artemis data print) we can see that
> all messages with qos>0 are durable .
> We think that this behaviour may depends from following code:
>
> for topics(from MQTTSubscriptionManager.java):
>
>
>private Queue createQueueForSubscription(String topic, int qos) throws
> Exception {
>   String address = MQTTUtil.convertMQTTAddressFilterToCore(topic);
>   SimpleString queue = getQueueNameForTopic(address);
>
>   Queue q = session.getServer().locateQueue(queue);
>   if (q == null) {
>  q = session.getServerSession().createQueue(new
> SimpleString(address), queue, managementFilter, false,
> MQTTUtil.DURABLE_MESSAGES && qos >= 0);
>   }
>   return q;
>}
>
>
> for queues (from MQTTPublishManager.java)
>
>// INBOUND
>void handleMessage(int messageId, String topic, int qos, ByteBuf
> payload,
> boolean retain) throws Exception {
>   synchronized (lock) {
>  ServerMessage serverMessage =
> MQTTUtil.createServerMessageFromByteBuf(session, topic, retain, qos,
> payload);
>
>  if (qos > 0) {
> serverMessage.setDurable(MQTTUtil.DURABLE_MESSAGES);
>  }
>
> Is it possible to use durable messages only for retained messages?
>
> Tks
> Fabio
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Artemis-MQTT-durable-messages-and-Topics-tp4722239p4722274.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [ANNOUNCE] Apache Artemis 1.5.3 Release

[Martyn Taylor]

Good point.  I'll wait for 24hrs in future.

Cheers.

On Mon, Feb 20, 2017 at 1:55 PM, Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:

> The mirrors take quite a while to sync and its typical to wait a while
> after putting the files in the dist repo before announcing in order to
> avoid the 404 errors most folks willcurrently be seeing.
>
> Typically I wait 24+hrs to let essentially all of them update, but a
> significant proportion are usually ready between 12-18hrs if in a
> hurry. The mirror ages are visible at https://www.apache.org/mirrors/
>
> Robbie
>
> On 20 February 2017 at 13:46, Martyn Taylor <mtay...@redhat.com> wrote:
> > The distribution mirrors are taking a little while to sync.  In the
> > meantime you can grab the latest artifacts from:
> https://dist.apache.org/
> > repos/dist/release/activemq/activemq-artemis/1.5.3/
> >
> > Cheers
> >
> > On Mon, Feb 20, 2017 at 11:16 AM, Martyn Taylor <mtay...@redhat.com>
> wrote:
> >
> >> All,
> >>
> >> I'm pleased to announce the release of Apache Artemis 1.5.3.
> >>
> >> This revision release of Apache Artemis contains a number of
> improvements
> >> and bug fixes.
> >>
> >> The project website for Apache Artemis has been updated include this
> >> release and can be found here:
> >> http://activemq.apache.org/artemis/
> >>
> >> A list of issues fixed in Apache Artemis 1.3.0 is available here:
> >> https://activemq.apache.org/artemis/release-notes-1.5.3.html
> >>
> >> API and User documentation can be found here:
> >> https://activemq.apache.org/artemis/docs.html
> >>
> >> Regards
> >> Martyn
> >>
>

Re: [ANNOUNCE] Apache Artemis 1.5.3 Release

[Martyn Taylor]

The distribution mirrors are taking a little while to sync.  In the
meantime you can grab the latest artifacts from: https://dist.apache.org/
repos/dist/release/activemq/activemq-artemis/1.5.3/

Cheers

On Mon, Feb 20, 2017 at 11:16 AM, Martyn Taylor <mtay...@redhat.com> wrote:

> All,
>
> I'm pleased to announce the release of Apache Artemis 1.5.3.
>
> This revision release of Apache Artemis contains a number of improvements
> and bug fixes.
>
> The project website for Apache Artemis has been updated include this
> release and can be found here:
> http://activemq.apache.org/artemis/
>
> A list of issues fixed in Apache Artemis 1.3.0 is available here:
> https://activemq.apache.org/artemis/release-notes-1.5.3.html
>
> API and User documentation can be found here:
> https://activemq.apache.org/artemis/docs.html
>
> Regards
> Martyn
>

[ANNOUNCE] Apache Artemis 1.5.3 Release

[Martyn Taylor]

All,

I'm pleased to announce the release of Apache Artemis 1.5.3.

This revision release of Apache Artemis contains a number of improvements
and bug fixes.

The project website for Apache Artemis has been updated include this
release and can be found here:
http://activemq.apache.org/artemis/

A list of issues fixed in Apache Artemis 1.3.0 is available here:
https://activemq.apache.org/artemis/release-notes-1.5.3.html

API and User documentation can be found here:
https://activemq.apache.org/artemis/docs.html

Regards
Martyn

Re: What is the current status and plans for the web-console?

[Martyn Taylor]

Thanks for restoring this discussion.

On Fri, Feb 17, 2017 at 3:38 PM, Clebert Suconic 
wrote:

> What about start doing it right after Artemis 2.0.0 is out? Aim it to
> 2.1.0 (on Artemis, being compatible with AMQ5 (still a question mark
> on how to do it.. but I"m taking this is a requirement)).
>
>
> On Fri, Feb 17, 2017 at 9:38 AM, Christopher Shannon
>  wrote:
> > Yes there seemed to be some consensus to build a plugin hosted here at
> > Apache or to build a new console altogether to support 5.x and Artemis.
> > And we would keep the existing console until then.
>
Yes!

The console is something I am really passionate about.  In my opinion user
experience is the number one priority and the lack of any form of console
in Artemis is just a disaster.  We're really missing a trick here as I
think we could build something fantastic for both ActiveMQ 5.x and Artemis.

>
> > However, the hold up has always been finding people who have time to work
> > on it and want to work on it.  If someone wants to create a repo and
> start
> > working on it that would probably help to get others involved.
>
I'm more than happy to take this on and get a repository created and put a
basic framework in place.  This should get the ball rolling.

> >
> > On Fri, Feb 17, 2017 at 9:23 AM, Daniel Kulp  wrote:
> >
> >>
> >> > On Feb 17, 2017, at 8:52 AM, Clebert Suconic <
> clebert.suco...@gmail.com>
> >> wrote:
> >> >
> >> > On Fri, Feb 17, 2017 at 4:48 AM, Christian Schneider
> >> >  wrote:
> >> >> I have read the old threads about the web console.
> >> >>
> >> >> If I understood correctly then we would like to get rid of the
> current
> >> >> activemq web console but need a replacement. There is hawt.io which
> >> >> functionally would work but which is not compatible from a community
> >> >> standpoint.
> >> >
> >> > My understand was: as long as it looked like an apache console, and
> >> > not a commercial product belonging to any company it would be ok.
> >> >
> >>
> >> *AND* all of the ActiveMQ/Artemis related bits are written and
> maintained
> >> here at Apache as part of this community.  How the queues and brokers
> and
> >> such are presented to the user is completely under the control of this
> >> community.
> >>
> >> In other words: we don’t take the activemq plugin or whatever they have
> >> and use it as is. (Unless they want to donate it to this community)
> >>
> >> --
> >> Daniel Kulp
> >> dk...@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
>
>
>
> --
> Clebert Suconic
>

[RESULT][VOTE] Apache Artemis 1.5.3

[Martyn Taylor]

Results of Apache Artemis 1.5.3 release vote.

Vote passes with 7 binding +1 votes.

Binding:
+1 Clebert Suconic
+1 Claus Ibsen
+1 Dejan Bosanac
+1 Christopher Shannon
+1 Timothy Bish
+1 Jim Gomes
+1 Martyn Taylor

Non Binding:
+1 Francesco Nigro

Thank you to everyone who contributed and took the time to review the
release candidates and vote.

I'll move forward with the getting the release out and updating the
relevant documentation.

Regards

[VOTE] Apache Artemis 1.5.3 (RC2)

[Martyn Taylor]

Hello all,

I'd like to propose an Apache Artemis 1.5.3 release (RC2).

This revision release of Apache Artemis 1.5 contains a number of bug fixes
and improvements including:

Bug

   - [ARTEMIS-917 ] -
   Retained messages from file system contain weird chars
   - [ARTEMIS-931 ] -
   Improve HTTP upgrade connection
   - [ARTEMIS-934 ] -
   Stomp server keeps pinging client after client stops responding
   - [ARTEMIS-937 ] -
   Use Proper disk alignment over libaio instead of 512 hard coded.
   - [ARTEMIS-939 ] -
   User list not updated on the broker dynamically
   - [ARTEMIS-951 ] -
   MQTT Messages Acks are not auto-committed
   - [ARTEMIS-952 ] -
   MQTT Clean session should delete subscription queues

Improvement

   - [ARTEMIS-873 ] -
   Use K,M,G notations on broker.xml
   - [ARTEMIS-935 ] -
   Tool to recalculate disk sync times
   - [ARTEMIS-938 ] -
   JDBC persistence-store should use BIGINT type for IDs in database tables
   - [ARTEMIS-957 ] -
   JDBC Store should use setBytes API vs using Concat on BLOB



The release notes can be found here:
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12339575=Html=12315920
*

The binary distributions can be found here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1117/org/apache/activemq/apache-artemis/1.5.3/

The source archives can be found here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1117/org/apache/activemq/apache-artemis/1.5.3/

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1117/

The source tag:
*https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.5.3
*

As this is only a revision release, only doc and download links needs to be
updated in the website.  I will update accordingly after the release.

The vote will remain open for 72 hours.

[ ] +1 approve the release as Apache Artemis 1.5.3
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my (binding) +1

Regards

[CANCEL][VOTE] Apache Artemis 1.5.3

[Martyn Taylor]

Cancelling this vote will send an RC2 shortly.

On Fri, Feb 10, 2017 at 2:12 PM, Martyn Taylor <mtay...@redhat.com> wrote:

> Guys,
>
> I made a bit of a git foobar when doing the release and missed off some
> commits that were intended to be cherry-picked from master.
>
> I'm going to give this my -1 this and redo the release.
>
> Apologies for the inconvenience.
>
> On Fri, Feb 10, 2017 at 2:01 PM, Clebert Suconic <
> clebert.suco...@gmail.com> wrote:
>
>> +1 (Binding)
>> Just a minor update, the links for the tag is wrong:
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.g
>> it;a=tag;h=refs/tags/1.5.3
>>
>>
>> On Fri, Feb 10, 2017 at 6:30 AM, Martyn Taylor <mtay...@redhat.com>
>> wrote:
>> > Hello all,
>> >
>> > I'd like to propose an Apache Artemis 1.5.3 release.
>> >
>> > This revision release of Apache Artemis 1.5 contains a number of bug
>> fixes
>> > and improvements including:
>> > Bug
>> >
>> >- [ARTEMIS-931 <https://issues.apache.org/jira/browse/ARTEMIS-931>]
>> -
>> >Improve HTTP upgrade connection
>> >- [ARTEMIS-934 <https://issues.apache.org/jira/browse/ARTEMIS-934>]
>> -
>> >Stomp server keeps pinging client after client stops responding
>> >- [ARTEMIS-937 <https://issues.apache.org/jira/browse/ARTEMIS-937>]
>> -
>> >Use Proper disk alignment over libaio instead of 512 hard coded.
>> >- [ARTEMIS-939 <https://issues.apache.org/jira/browse/ARTEMIS-939>]
>> -
>> >User list not updated on the broker dynamically
>> >- [ARTEMIS-951 <https://issues.apache.org/jira/browse/ARTEMIS-951>]
>> -
>> >MQTT Messages Acks are not auto-committed
>> >- [ARTEMIS-952 <https://issues.apache.org/jira/browse/ARTEMIS-952>]
>> -
>> >MQTT Clean session should delete subscription queues
>> >
>> > Improvement
>> >
>> >- [ARTEMIS-935 <https://issues.apache.org/jira/browse/ARTEMIS-935>]
>> -
>> >Tool to recalculate disk sync times
>> >
>> > New Feature
>> >
>> >- [ARTEMIS-873 <https://issues.apache.org/jira/browse/ARTEMIS-873>]
>> -
>> >Use K,M,G notations on broker.xml
>> >
>> >
>> >
>> > The release notes can be found here:
>> > *https://issues.apache.org/jira/secure/ReleaseNote.jspa?vers
>> ion=12339575=Html=12315920
>> > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?vers
>> ion=12339575=Html=12315920>*
>> >
>> > The binary distributions can be found here:
>> > *https://repository.apache.org/content/repositories/orgapach
>> eactivemq-1116/
>> > <https://repository.apache.org/content/repositories/orgapach
>> eactivemq-1116/>*
>> > org/apache/activemq/apache-artemis/1.5.3/
>> > <https://repository.apache.org/content/repositories/orgapach
>> eactivemq-1095/org/apache/activemq/apache-artemis/1.3.0/>
>> >
>> >
>> > The source archives can be found here:
>> > *https://repository.apache.org/content/repositories/orgapach
>> eactivemq-1116/
>> > <https://repository.apache.org/content/repositories/orgapach
>> eactivemq-1116/>*
>> > /org/apache/activemq/apache-artemis/1.
>> > <https://repository.apache.org/content/repositories/orgapach
>> eactivemq-1095/org/apache/activemq/apache-artemis/1.3.0/>
>> > 5.3
>> >
>> > The Maven repository is here:
>> > *https://repository.apache.org/content/repositories/orgapach
>> eactivemq-1116/
>> > <https://repository.apache.org/content/repositories/orgapach
>> eactivemq-1116/>*
>> >
>> > The source tag:
>> > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
>> > git;a=tag;h=refs/tags/1.
>> > <https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
>> git;a=tag;h=refs/tags/1.3.0>
>> > 5.3
>> >
>> > As this is only a revision release, only doc and download links needs
>> to be
>> > updated in the website.  I will update accordingly after the release.
>> >
>> > The vote will remain open for 72 hours.
>> >
>> > [ ] +1 approve the release as Apache Artemis 1.5.3
>> > [ ] +0 no opinion
>> > [ ] -1 disapprove (and reason why)
>> >
>> > Here's my (binding) +1
>> >
>> > Regards
>>
>>
>>
>> --
>> Clebert Suconic
>>
>
>

Re: [VOTE] Apache Artemis 1.5.3

[Martyn Taylor]

Guys,

I made a bit of a git foobar when doing the release and missed off some
commits that were intended to be cherry-picked from master.

I'm going to give this my -1 this and redo the release.

Apologies for the inconvenience.

On Fri, Feb 10, 2017 at 2:01 PM, Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> +1 (Binding)
> Just a minor update, the links for the tag is wrong:
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> git;a=tag;h=refs/tags/1.5.3
>
>
> On Fri, Feb 10, 2017 at 6:30 AM, Martyn Taylor <mtay...@redhat.com> wrote:
> > Hello all,
> >
> > I'd like to propose an Apache Artemis 1.5.3 release.
> >
> > This revision release of Apache Artemis 1.5 contains a number of bug
> fixes
> > and improvements including:
> > Bug
> >
> >- [ARTEMIS-931 <https://issues.apache.org/jira/browse/ARTEMIS-931>] -
> >Improve HTTP upgrade connection
> >- [ARTEMIS-934 <https://issues.apache.org/jira/browse/ARTEMIS-934>] -
> >Stomp server keeps pinging client after client stops responding
> >- [ARTEMIS-937 <https://issues.apache.org/jira/browse/ARTEMIS-937>] -
> >Use Proper disk alignment over libaio instead of 512 hard coded.
> >- [ARTEMIS-939 <https://issues.apache.org/jira/browse/ARTEMIS-939>] -
> >User list not updated on the broker dynamically
> >- [ARTEMIS-951 <https://issues.apache.org/jira/browse/ARTEMIS-951>] -
> >MQTT Messages Acks are not auto-committed
> >- [ARTEMIS-952 <https://issues.apache.org/jira/browse/ARTEMIS-952>] -
> >MQTT Clean session should delete subscription queues
> >
> > Improvement
> >
> >- [ARTEMIS-935 <https://issues.apache.org/jira/browse/ARTEMIS-935>] -
> >Tool to recalculate disk sync times
> >
> > New Feature
> >
> >- [ARTEMIS-873 <https://issues.apache.org/jira/browse/ARTEMIS-873>] -
> >Use K,M,G notations on broker.xml
> >
> >
> >
> > The release notes can be found here:
> > *https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12339575=Html=12315920
> > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12339575=Html=12315920>*
> >
> > The binary distributions can be found here:
> > *https://repository.apache.org/content/repositories/
> orgapacheactivemq-1116/
> > <https://repository.apache.org/content/repositories/
> orgapacheactivemq-1116/>*
> > org/apache/activemq/apache-artemis/1.5.3/
> > <https://repository.apache.org/content/repositories/
> orgapacheactivemq-1095/org/apache/activemq/apache-artemis/1.3.0/>
> >
> >
> > The source archives can be found here:
> > *https://repository.apache.org/content/repositories/
> orgapacheactivemq-1116/
> > <https://repository.apache.org/content/repositories/
> orgapacheactivemq-1116/>*
> > /org/apache/activemq/apache-artemis/1.
> > <https://repository.apache.org/content/repositories/
> orgapacheactivemq-1095/org/apache/activemq/apache-artemis/1.3.0/>
> > 5.3
> >
> > The Maven repository is here:
> > *https://repository.apache.org/content/repositories/
> orgapacheactivemq-1116/
> > <https://repository.apache.org/content/repositories/
> orgapacheactivemq-1116/>*
> >
> > The source tag:
> > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> > git;a=tag;h=refs/tags/1.
> > <https://git-wip-us.apache.org/repos/asf?p=activemq-
> artemis.git;a=tag;h=refs/tags/1.3.0>
> > 5.3
> >
> > As this is only a revision release, only doc and download links needs to
> be
> > updated in the website.  I will update accordingly after the release.
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1 approve the release as Apache Artemis 1.5.3
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my (binding) +1
> >
> > Regards
>
>
>
> --
> Clebert Suconic
>

[VOTE] Apache Artemis 1.5.3

[Martyn Taylor]

Hello all,

I'd like to propose an Apache Artemis 1.5.3 release.

This revision release of Apache Artemis 1.5 contains a number of bug fixes
and improvements including:
Bug

   - [ARTEMIS-931 ] -
   Improve HTTP upgrade connection
   - [ARTEMIS-934 ] -
   Stomp server keeps pinging client after client stops responding
   - [ARTEMIS-937 ] -
   Use Proper disk alignment over libaio instead of 512 hard coded.
   - [ARTEMIS-939 ] -
   User list not updated on the broker dynamically
   - [ARTEMIS-951 ] -
   MQTT Messages Acks are not auto-committed
   - [ARTEMIS-952 ] -
   MQTT Clean session should delete subscription queues

Improvement

   - [ARTEMIS-935 ] -
   Tool to recalculate disk sync times

New Feature

   - [ARTEMIS-873 ] -
   Use K,M,G notations on broker.xml



The release notes can be found here:
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12339575=Html=12315920
*

The binary distributions can be found here:
*https://repository.apache.org/content/repositories/orgapacheactivemq-1116/
*
org/apache/activemq/apache-artemis/1.5.3/



The source archives can be found here:
*https://repository.apache.org/content/repositories/orgapacheactivemq-1116/
*
/org/apache/activemq/apache-artemis/1.

5.3

The Maven repository is here:
*https://repository.apache.org/content/repositories/orgapacheactivemq-1116/
*

The source tag:
https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
git;a=tag;h=refs/tags/1.

5.3

As this is only a revision release, only doc and download links needs to be
updated in the website.  I will update accordingly after the release.

The vote will remain open for 72 hours.

[ ] +1 approve the release as Apache Artemis 1.5.3
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my (binding) +1

Regards

[DISCUSS] ActiveMQ Artemis 2.x stream

[Martyn Taylor]

All,

As discussed in a previous thread [1] Artemis master has had a major bump
(due to major model refactor).

The great news is that the new model is more flexible and lends itself well
to 5.x features like Virtual Topics as well as being consistent across all
protocols.  The not so good news is that this work required API breakages,
hence the major version bump.).  This refactor work (mostly around the
addressing scheme [2]) is now completed.

The code base is now in a stable state, and as such, I'd like to start
thinking about doing a release off of master as an Apache Artemis 2.0.0 to
get the new changes into the hands of users.

I'd like to open discussion around this topic, does anyone have any
suggestions, or can think of anything that is needed before we go ahead
with a major release? This is the perfect time to do anything that could
break APIs, drop deprecated methods support, break data format etc...

Cheers
Martyn

[1]
http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-addressing-improvements-JMS-component-removal-and-potential-2-0-0-td4719262.html

[2] https://issues.apache.org/jira/browse/ARTEMIS-780

Re: [HEADS-UP] Artemis 1.5.3 release WAS: ARTEMIS-937 affect my productive environment

[Martyn Taylor]

Clebert,

There are a couple of issues around MQTT raised on the dev list.
Specifically:

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

and an Issue I am currently investigating around MQTT message not getting
properly ack'd.

If we can hold off a couple of days I should get these fixes done.  I'd
also be happy to co-ordinate the release of 1.5.3.

Cheers
Martyn



On Fri, Feb 3, 2017 at 8:47 PM, Clebert Suconic 
wrote:

> Fair enough Fabio,
>
>
> I will make a 1.5.3 release early next week (On Tuesday).
>
>
> On Fri, Feb 3, 2017 at 3:37 PM, Fabio Gomes dos Santos
>  wrote:
> > Hi guys!
> >
> > Do you pretend to release a new version soon?
> > I think that bug justify a new release, all my artemis nodes use SSD to
> > supposed improve performance.
> >
> > Anyone using a SSD too?
> >
> > --
> > Fábio Santos
> > supergr...@gmail.com
> > 
>
>
>
> --
> Clebert Suconic
>

Re: [DISCUSS] ActiveMQ utility project name

[Martyn Taylor]

+1 on keep the scope to CLI utilities only.  Shared libraries is a separate
topic.

I would, however, like to suggest that we extend the scope to more than
just store tools.  We have, for example, tools to migrate configurations of
Artemis 1.x to the newer 2.0 format and this new project seems like an
ideal home for this sort of thing.  Perhaps just activemq-cli-tools?

On Wed, Feb 1, 2017 at 5:58 PM, Clebert Suconic 
wrote:

> I thought we could still release independently from a sub tree.
>
>
> As for he tools project what about having the exporter on amq code base and
> have it exporting the same format we use on Artemis importer?
>
> If you really need a bridge for what you think then we need the project as
> suggested.
>
>
> On Wed, Feb 1, 2017 at 12:47 PM Robbie Gemmell 
> wrote:
>
> > I would echo Tim's comments, particularly around test client code. I'm
> > in the middle of seperating things elsewhere that probably shouldn't
> > have been lumped together initially.
> >
> > Beyond that, the first thing infra will likely tell folks to do is to
> > use http://reporeq.apache.org for any new repository requests (as I
> > found out recently, but couldn't actually use it myself due to the
> > specifics of what I needed done).
> >
> > Robbie
> >
> > On 1 February 2017 at 16:20, Timothy Bish  wrote:
> > > On 02/01/2017 09:09 AM, Clebert Suconic wrote:
> > >>
> > >> +1
> > >>
> > >> Although, can we use the opportunity to go beyond the tools you are
> > >> thinking now?
> > >
> > >
> > > I'd be careful of the amount of things lumped into one subproject
> > especially
> > > if they are unrelated to the focus of that project as it drags down the
> > ease
> > > of doing quick releases with targeted features.
> > >
> > >>
> > >>
> > >> there are a couple of other things that would be nice to be shared as
> > >> well. For instance some openwire parsers, some testsuite libraries for
> > >> AMQP that we share with a copy & paste inheritance between artemis and
> > >> activemq.
> > >
> > >
> > > I'd suggest that anything OpenWire related might be better slotted into
> > the
> > > openwire project that was created previously.  And I'd think long and
> > hard
> > > about how far into the wild we let the AMQP test client bits go because
> > once
> > > it gets into a release outside of a test jar the likely hood of having
> to
> > > support it to the general public grows.
> > >
> > >>
> > >>
> > >> I have been thinking also to split docs into a separate repo. We would
> > >> still release docs connected to a version, but we could then make
> > >> changes to docs independently of the release, without having to spin a
> > >> broker release to fix eventual typos on the docs.
> > >>
> > >> So, can we have an extras repo, and have all these as part of the new
> > >> repo?
> > >
> > >
> > > Again putting unrelated things into the same subproject complicates the
> > > timing of releases and muddies the focus of the project so I'd shy away
> > for
> > > lumping broker docs into a tooling subproject.
> > >
> > >>
> > >> (I'm not so sure if docs should be mixed with this all, perhaps we
> > >> still need a separate repo for docs.. but I wanted to throw out the
> > >> idea now anyways).
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Feb 1, 2017 at 7:44 AM, Christopher Shannon
> > >>  wrote:
> > >>>
> > >>> I'm going to ping infra to create a new project but wanted to get
> some
> > >>> feedback from people first. The main motivation for this utility
> > project
> > >>> is
> > >>> to create some command line store utilities for things like
> migrating a
> > >>> KahaDB store to an Artemis store.
> > >>>
> > >>> I could request the name to be 'activemq-store-tools' or something
> like
> > >>> that but we could also make it more generic such as
> > 'activemq-cli-tools'
> > >>> or
> > >>> even just simply 'activemq-tools' if there is other stuff we wanted
> to
> > >>> put
> > >>> in there.  Thoughts?
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > Tim Bish
> > > twitter: @tabish121
> > > blog: http://timbish.blogspot.com/
> > >
> >
> --
> Clebert Suconic
>

Re: Time to assemble a board report

[Martyn Taylor]

I've added some Artemis related updates to the board report.  Could someone
with more day to day experience of ActiveMQ 5.x add some of the main
highlights over the past couple of month.

Thanks

On Mon, Jan 9, 2017 at 2:13 PM, Martyn Taylor <mtay...@redhat.com> wrote:

> Bruce,
>
> Just returned from vacation and caught up with email.  I'll get to this
> before the end of today.
>
> Regards
> Martyn
>
> On Tue, Jan 3, 2017 at 11:20 PM, Clebert Suconic <
> clebert.suco...@gmail.com> wrote:
>
>> The activemq blog inauguration could be a topic ?
>>
>>
>> On Mon, Jan 2, 2017 at 7:16 PM John D. Ament <johndam...@apache.org>
>> wrote:
>>
>> > Here's some of what I've seen:
>> >
>> >
>> >
>> > - Typical holiday slowdown
>> >
>> > - 3 patch fix releases to the 5.x line, 2 releases on the Artemis side
>> >
>> > - Active development of Artemis 2.0 which has major changes to the
>> >
>> > internals of routing within Artemis.
>> >
>> > - Both products have baselined to a Java 8 minimum requirement.
>> >
>> >
>> >
>> > John
>> >
>> >
>> >
>> > On Mon, Jan 2, 2017 at 2:20 PM Bruce Snyder <bruce.sny...@gmail.com>
>> > wrote:
>> >
>> >
>> >
>> > > There have been zero updates to the January board report page in the
>> wiki
>> >
>> > > and this report is due next week.
>> >
>> > >
>> >
>> > > Please take 10 minutes to contribute some information regarding the
>> > recent
>> >
>> > > activity in the project.
>> >
>> > >
>> >
>> > > Bruce
>> >
>> > >
>> >
>> > > On Mon, Jan 2, 2017 at 1:05 PM, Bruce Snyder <bruce.sny...@gmail.com>
>> >
>> > > wrote:
>> >
>> > >
>> >
>> > > > The report is due on 11 January so I plan to post it on 9 or 10
>> > January.
>> >
>> > > >
>> >
>> > > > Bruce
>> >
>> > > >
>> >
>> > > > On Fri, Dec 30, 2016 at 10:32 AM, Clebert Suconic <
>> >
>> > > > clebert.suco...@gmail.com> wrote:
>> >
>> > > >
>> >
>> > > >> When are we doing it?
>> >
>> > > >>
>> >
>> > > >> I'm in vacations with family without access to a computer.  I could
>> > help
>> >
>> > > >> in
>> >
>> > > >> 2 weeks. But perhaps is too late ?
>> >
>> > > >>
>> >
>> > > >>
>> >
>> > > >> On Wed, Dec 28, 2016 at 3:31 AM Bruce Snyder <
>> bruce.sny...@gmail.com>
>> >
>> > > >> wrote:
>> >
>> > > >>
>> >
>> > > >> > I'd like to take a moment to wish everyone happy holidays and a
>> >
>> > > >> wonderful
>> >
>> > > >> >
>> >
>> > > >> > new year wherever you are in the world! I hope you are able to
>> spend
>> >
>> > > >> time
>> >
>> > > >> >
>> >
>> > > >> > with friends and loved ones to appreciate everything in our
>> > fortunate
>> >
>> > > >> > lives.
>> >
>> > > >> >
>> >
>> > > >> >
>> >
>> > > >> >
>> >
>> > > >> > It's time again to compile another board report, so please take a
>> > few
>> >
>> > > >> >
>> >
>> > > >> > moments to contribute to the wiki page:
>> >
>> > > >> >
>> >
>> > > >> >
>> >
>> > > >> >
>> >
>> > > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?
>> >
>> > > >> pageId=67636191
>> >
>> > > >> >
>> >
>> > > >> >
>> >
>> > > >> >
>> >
>> > > >> > The goal is to report the activity in any code base under the
>> > ActiveMQ
>> >
>> > > >> >
>> >
>> > > >> > project including ActiveMQ and ActiveMQ Artemis. I would like to

Re: Time to assemble a board report

[Martyn Taylor]

Bruce,

Just returned from vacation and caught up with email.  I'll get to this
before the end of today.

Regards
Martyn

On Tue, Jan 3, 2017 at 11:20 PM, Clebert Suconic 
wrote:

> The activemq blog inauguration could be a topic ?
>
>
> On Mon, Jan 2, 2017 at 7:16 PM John D. Ament 
> wrote:
>
> > Here's some of what I've seen:
> >
> >
> >
> > - Typical holiday slowdown
> >
> > - 3 patch fix releases to the 5.x line, 2 releases on the Artemis side
> >
> > - Active development of Artemis 2.0 which has major changes to the
> >
> > internals of routing within Artemis.
> >
> > - Both products have baselined to a Java 8 minimum requirement.
> >
> >
> >
> > John
> >
> >
> >
> > On Mon, Jan 2, 2017 at 2:20 PM Bruce Snyder 
> > wrote:
> >
> >
> >
> > > There have been zero updates to the January board report page in the
> wiki
> >
> > > and this report is due next week.
> >
> > >
> >
> > > Please take 10 minutes to contribute some information regarding the
> > recent
> >
> > > activity in the project.
> >
> > >
> >
> > > Bruce
> >
> > >
> >
> > > On Mon, Jan 2, 2017 at 1:05 PM, Bruce Snyder 
> >
> > > wrote:
> >
> > >
> >
> > > > The report is due on 11 January so I plan to post it on 9 or 10
> > January.
> >
> > > >
> >
> > > > Bruce
> >
> > > >
> >
> > > > On Fri, Dec 30, 2016 at 10:32 AM, Clebert Suconic <
> >
> > > > clebert.suco...@gmail.com> wrote:
> >
> > > >
> >
> > > >> When are we doing it?
> >
> > > >>
> >
> > > >> I'm in vacations with family without access to a computer.  I could
> > help
> >
> > > >> in
> >
> > > >> 2 weeks. But perhaps is too late ?
> >
> > > >>
> >
> > > >>
> >
> > > >> On Wed, Dec 28, 2016 at 3:31 AM Bruce Snyder <
> bruce.sny...@gmail.com>
> >
> > > >> wrote:
> >
> > > >>
> >
> > > >> > I'd like to take a moment to wish everyone happy holidays and a
> >
> > > >> wonderful
> >
> > > >> >
> >
> > > >> > new year wherever you are in the world! I hope you are able to
> spend
> >
> > > >> time
> >
> > > >> >
> >
> > > >> > with friends and loved ones to appreciate everything in our
> > fortunate
> >
> > > >> > lives.
> >
> > > >> >
> >
> > > >> >
> >
> > > >> >
> >
> > > >> > It's time again to compile another board report, so please take a
> > few
> >
> > > >> >
> >
> > > >> > moments to contribute to the wiki page:
> >
> > > >> >
> >
> > > >> >
> >
> > > >> >
> >
> > > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?
> >
> > > >> pageId=67636191
> >
> > > >> >
> >
> > > >> >
> >
> > > >> >
> >
> > > >> > The goal is to report the activity in any code base under the
> > ActiveMQ
> >
> > > >> >
> >
> > > >> > project including ActiveMQ and ActiveMQ Artemis. I would like to
> >
> > > report
> >
> > > >> any
> >
> > > >> >
> >
> > > >> > progress that has been made in the last three months.
> >
> > > >> >
> >
> > > >> >
> >
> > > >> >
> >
> > > >> > If only a few people contribute three items of progress, then we
> >
> > > should
> >
> > > >> be
> >
> > > >> >
> >
> > > >> > able to provide a good report.
> >
> > > >> >
> >
> > > >> >
> >
> > > >> >
> >
> > > >> > Thank you for your contributions,
> >
> > > >> >
> >
> > > >> >
> >
> > > >> >
> >
> > > >> > Bruce
> >
> > > >> >
> >
> > > >> >
> >
> > > >> >
> >
> > > >> > --
> >
> > > >> >
> >
> > > >> > perl -e 'print
> >
> > > >> >
> >
> > > >> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E "YC;VT*"
> >
> > > >> );'
> >
> > > >> >
> >
> > > >> >
> >
> > > >> >
> >
> > > >> > ActiveMQ in Action: http://bit.ly/2je6cQ
> >
> > > >> >
> >
> > > >> > Blog: http://bsnyder.org/ 
> >
> > > >> >
> >
> > > >> > Twitter: http://twitter.com/brucesnyder
> >
> > > >> >
> >
> > > >> >
> >
> > > >>
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > --
> >
> > > > perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&
> >
> > > > 5R\"F)R=6-E+G-N>61E >
> > > >
> >
> > > > ActiveMQ in Action: http://bit.ly/2je6cQ
> >
> > > > Blog: http://bsnyder.org/ 
> >
> > > > Twitter: http://twitter.com/brucesnyder
> >
> > > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > perl -e 'print
> >
> > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E );'
> >
> > >
> >
> > > ActiveMQ in Action: http://bit.ly/2je6cQ
> >
> > > Blog: http://bsnyder.org/ 
> >
> > > Twitter: http://twitter.com/brucesnyder
> >
> > >
> >
> >
>

Re: [DISCUSS] Web site update

[Martyn Taylor]

I can help with this. Let's sync up in the new yeat

On 21 Dec 2016 16:15, "Clebert Suconic"  wrote:

> H.. I need a web designer's help.. anyone caring to help? or give
> us some direction?
>
>
> I was trying to do this by hand.. getting the index.html and make it
> look like the artemis website (just for a prototype), and this harder
> than I thought.
>
>
> I will need some help...
>
>
> anyway.. this will be on my new years resolutions... loose weight,
> improve encoding, improve website :)... :)
>
> On Fri, Dec 16, 2016 at 6:33 AM, Robbie Gemmell
>  wrote:
> > The content for most of the site is actually a Confluence wiki, which
> > is converted into the HTML pages for the website, with those then
> > being committed into an svn repo, and that being mirrored onto the
> > webservers upon commit by an svnpubsub process.
> >
> > The 'source' for the website is mostly:
> > https://cwiki.apache.org/confluence/display/ACTIVEMQ/Index
> >
> > Many of the Apache project sites used to do their sites like this, as
> > infra managed the export via a Confluence plugin. Infra stopped
> > supporting that plugin a number of years ago during a Confluence
> > upgrade, and projects were requried to either move to alternatives, or
> > come up with a new export system, which seems to be what happened with
> > the ActiveMQ site.
> >
> > On 16 December 2016 at 02:43, Clebert Suconic 
> wrote:
> >> I got a bit confused.
> >>
> >>
> >> There is a confluence link at the page.  But there is a svn for the
> >> website. Confluence is the old scheme?
> >>
> >> What's going on? :)
> >>
> >>
> >> On Thu, Dec 15, 2016 at 2:41 PM Matt Pavlovich 
> wrote:
> >>
> >>> @tbish Good point. We'll want to bring NMS, CMS, etc along for sure.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 12/15/16 2:21 PM, Timothy Bish wrote:
> >>>
> >>> > On 12/15/2016 02:08 PM, Matt Pavlovich wrote:
> >>>
> >>> >> @tbish.. haha.  Yeah, the Karaf site can be a bit much, but the use
> >>>
> >>> >> of color and pictures is good.. lot of other popular open source
> >>>
> >>> >> projects have similar layouts.. spring.io, etc.
> >>>
> >>> >>
> >>>
> >>> >> @clebert- IMO the plain apache.org is pretty bland. Prolly one step
> >>>
> >>> >> up from openbsd.org level blandness ;-) The current Artemis docs
> have
> >>>
> >>> >> nice l I agree w/ clean site, but I think we should shoot for
> >>>
> >>> >> better font usage and at least an updated logo.
> >>>
> >>> >>
> >>>
> >>> >> A nice logo that looks good as a laptop sticker, backpacks,
> t-shirts,
> >>>
> >>> >> etc seems to be attainable.
> >>>
> >>> >>
> >>>
> >>> >> Others to consider:
> >>>
> >>> >> wicket.apache.org
> >>>
> >>> >> spark.apache.org
> >>>
> >>> >> cassandra.apache.org (meh on the font, but clean look, good use of
> >>>
> >>> >> font face and font color)
> >>>
> >>> >> mesos.apache.org
> >>>
> >>> >> couchdb.apache.org (less karaf'sh, simple layout. good font faces
> and
> >>>
> >>> >> logo)
> >>>
> >>> >>
> >>>
> >>> >> -Matt
> >>>
> >>> >
> >>>
> >>> > Keep in mind that ActiveMQ has several subprojects (multiple brokers,
> >>>
> >>> > multiple clients) so the site design and layout needs to scale along
> >>>
> >>> > with the subprojects
> >>>
> >>> >
> >>>
> >>> >
> >>>
> >>> >>
> >>>
> >>> >> On 12/15/16 1:40 PM, Clebert Suconic wrote:
> >>>
> >>> >>> On Thu, Dec 15, 2016 at 12:40 PM, Timothy Bish <
> tabish...@gmail.com>
> >>>
> >>> >>> wrote:
> >>>
> >>>  On 12/15/2016 12:11 PM, Matt Pavlovich wrote:
> >>>
> >>> > +1 website needs to be updated and will to assist.
> >>>
> >>> >
> >>>
> >>> > I'd also throw out there kafka.apache.org and karaf.apache.org
> as
> >>>
> >>> > design
> >>>
> >>> > concepts to consider as well.
> >>>
> >>> >
> >>>
> >>>  The Kafka one isn't bad, the Karaf site make me feel like I need
> to
> >>>
> >>>  contact
> >>>
> >>>  someone from sales to get a trial license.
> >>>
> >>> >>> LOL
> >>>
> >>> >>>
> >>>
> >>> >>> I think Karaf and Kafka have too much of their project's
> personality
> >>>
> >>> >>> to bring it as a template.
> >>>
> >>> >>> I was looking for a plain template. qpid is very clean. the main
> >>>
> >>> >>> apache.org is also a very good example.
> >>>
> >>> >>
> >>>
> >>> >>
> >>>
> >>> >
> >>>
> >>> >
> >>>
> >>>
> >>>
> >>>
>
>
>
> --
> Clebert Suconic
>

Re: [DISCUSS] Web site update

[Martyn Taylor]

+1.  Also happy to provide support/help

On Thu, Dec 15, 2016 at 5:11 PM, Matt Pavlovich  wrote:

> +1 website needs to be updated and will to assist.
>
> I'd also throw out there kafka.apache.org and karaf.apache.org as design
> concepts to consider as well.
>
>
>
> On 12/15/16 11:03 AM, Clebert Suconic wrote:
>
>> How we could revamp the webiste on activemq.apache.org.
>>
>> Both Camel and ActiveMQ share the same design. It would be great if we
>> could do something clean...
>>
>> I like the example of qpid.apache.org, I would even still their design
>> :).
>>
>> Maybe bring Artemis a bit more up front on the website and make the
>> look and feel a bit more modern and clean.
>>
>>
>> Anyone available to help here? :)
>>
>>
>>
>>
>

Re: [DISCUSS] Artemis 2.0.0 target features

[Martyn Taylor]

On Thu, Dec 8, 2016 at 4:44 PM, Martyn Taylor <mtay...@redhat.com> wrote:

>
>
> On Thu, Dec 8, 2016 at 4:35 PM, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
>> I was not implying that the feature parity with ActiveMQ is a marketing
>> goal. I just wanted to show a case where typically in companies marketing
>> pushes for a major release based on a feature set as they think they can
>> sell it better. As an open source project ActiveMQ/Artemis has the luxury
>> to not being pushed by marketing.
>>
>> I currently do not see any bigger breaking API changes
>
> This thread has some more info: http://activemq-dev.markmail.
> org/search/?q=possible%202.0.0#query:possible%202.0.0+page:
> 1+mid:bt5v5z3l7n575vwc+state:results
>
Copy and paste fail...

The Nabble archieve is here:


http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-addressing-improvements-JMS-component-removal-and-potential-2-0-0-tt4719262.html


but I am not so much into the Artemis internals. Until now I was only
>> involved in the OSGi support.
>
>
>> I also think it is very good to talk about the upcoming or planned
>> features. I would make the list rather small though as in my experience the
>> actual features going into the code often differ from the plannings as
>> quite many people are involved at apache projects and the amount of work
>> they put in often can not be predicted well. So I would only look one or
>> two minor versions ahead most of the time.
>>
>> Christian
>>
>> On 08.12.2016 16:50, Matt Pavlovich wrote:
>>
>>> Christian-
>>>
>>> Are there any features or API breaking changes you'd like to see? My #1
>>> goal is to kick off a conversation.
>>>
>>> I don't think setting goals like "feature parity w/ ActiveMQ 5.x" is a
>>> marketing goal. I think it is a user-centric goal. Users use features. For
>>> Artemis to be a suitable upgrade for ActiveMQ 5.x, a set of features need
>>> to be present. My intention with this thread is to discuss and prioritize
>>> those features.
>>>
>>> -Matt
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>

Re: [DISCUSS] Artemis 2.0.0 target features

[Martyn Taylor]

On Thu, Dec 8, 2016 at 4:35 PM, Christian Schneider  wrote:

> I was not implying that the feature parity with ActiveMQ is a marketing
> goal. I just wanted to show a case where typically in companies marketing
> pushes for a major release based on a feature set as they think they can
> sell it better. As an open source project ActiveMQ/Artemis has the luxury
> to not being pushed by marketing.
>
> I currently do not see any bigger breaking API changes

This thread has some more info:
http://activemq-dev.markmail.org/search/?q=possible%202.0.0#query:possible%202.0.0+page:1+mid:bt5v5z3l7n575vwc+state:results


> but I am not so much into the Artemis internals. Until now I was only
> involved in the OSGi support.


> I also think it is very good to talk about the upcoming or planned
> features. I would make the list rather small though as in my experience the
> actual features going into the code often differ from the plannings as
> quite many people are involved at apache projects and the amount of work
> they put in often can not be predicted well. So I would only look one or
> two minor versions ahead most of the time.
>
> Christian
>
> On 08.12.2016 16:50, Matt Pavlovich wrote:
>
>> Christian-
>>
>> Are there any features or API breaking changes you'd like to see? My #1
>> goal is to kick off a conversation.
>>
>> I don't think setting goals like "feature parity w/ ActiveMQ 5.x" is a
>> marketing goal. I think it is a user-centric goal. Users use features. For
>> Artemis to be a suitable upgrade for ActiveMQ 5.x, a set of features need
>> to be present. My intention with this thread is to discuss and prioritize
>> those features.
>>
>> -Matt
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>