Re: Guarantee delivery response message to origin producer

2018-09-19 Thread artnaseef
Typically, the best way to accomplish request/reply is to use a temporary
queue.  Like this:

- JMS client A creates a temporary queue
- JMS client A produces message to request queue
  - On that message, the temporary queue is set as the JMSReplyTo using
javax.jms.Message.setJMSReplyTo()
- JMS client B consumes the request from the request queue
- JMS client B then produces a message to the temporary queue using
MessageProducer(requestMessage.getReplyTo(), replyMessage)

There are variations.  The good thing about temporary queues is that they
are automatically deleted by the broker when the client disconnects, so
there will never be idle messages sitting around.  If you need those
messages to remain until consumed, then switching to a permanent queue
that's dedicated to the client usually does the trick.

Hope this helps.

BTW, correlation ID can be used together with selectors to solve this. 
However, I would not recommend using selectors if they can be avoided at
all.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


Re: Artemis Roadmap

2017-12-11 Thread artnaseef
Thanks Bruce - I will look at this page shortly - I hope this week, but
should be no later than the end of next week.

Art




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


Re: [DISCUSS] Video call on ActiveMQ Artemis

2017-12-07 Thread artnaseef
+1 Count me in.  Hope I can make it.




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


Re: [DISCUSS] Graduate Artemis as TLP

2017-12-07 Thread artnaseef
I don't know about you guys - but I often feel like I'm arguing with myself
in an echo chamber when trying to find a way to move these discussions
forward.

:-)




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


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

2017-12-07 Thread artnaseef
For all the folks arguing that change is not needed - let me ask a question.

Is the concern clear?

I thought Clebert's post showing the mailing list did a good job, but we can
talk more about the concern.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


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

2017-12-07 Thread artnaseef
I'm putting this out there - hope folks will read it as I found it very
helpful.  It's not technical...

https://www.stephencovey.com/7habits/7habits-habit4.php

The numbered list is the most pertinent part IMO.  I post it here because I
see a trend in the communication that I think this helps to address.

Art

P.S. Yes, I'm a huge fan of Stephen Covey.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6

2017-12-06 Thread artnaseef
Please don't get too discouraged.  My vote personally was a request to slow
down and discuss.  I'm just not at a point where I'm ready for "ActiveMQ
Artemis becomes ActiveMQ 6".

We have this cycle of communication in which a vote goes out and generates a
ton of discussion (often heated).  Then we go quiet.  Months or years pass,
and then we do it again.

Let's change that!  We are all passionate about messaging and there's a ton
of great knowledge here.

I look forward to Bruce working on a roadmap, and providing input on the
same.  Thank you Bruce.  (Please correct me if I read it wrong).




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


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

2017-12-06 Thread artnaseef
+1 to Clebert's comments on clarity.




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


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

2017-12-06 Thread artnaseef
So any thoughts on how we can make sure important discussions, that deserve
the full attention of the PMC, can be achieved?  Really, on how we can meet
everybody's needs...

We've got the following positions, as I see it so far:

   1. Keep all DISCUSS and VOTE in public on the DEV list, do NOT bother
posting to the PMC list, and do NOT clean up the DEV list
   2. Keep all DISCUSS and VOTE in public on the DEV list, do NOT bother
posting to the PMC list, but DO cleanup the DEV LIST
   3. Keep all DISCUSS and VOTE in public on the DEV list, send an
appropriate posting to the PMC list, and do NOT clean up the DEV list

All three leave some concerns unaddressed.

I'm sure we can solve all the needs in a way that's comfortable for
everyone.  We're smart, we have a ton of technology at our disposal, and we
care.

Note that this is coming up now because of the current DEV thread VOTING on
the future of AMQ in a very important way was almost missed by many of the
PMC members.

As a member of the PMC, I want to see all of the DISCUSS and VOTE threads,
but I personally do not get paid to read through the mailing lists, making
it challenging to find the time to filter through large numbers of messages
to find them. Filters are a valid approach for each individual, but we can
and should do better - without any special effort, folks communicating with
the community (especially those in key roles) should have easy access to the
right information.

And yes, I have setup email filters with mixed success.  Another way to
think of this - if the messages can pre-organized, that helps everybody and
prevents distributing unneeded complexity.

P.S. For those of you saying, "deja vu?" - yes.  This was raised more than
once in the past and has come up again.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


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

2017-12-06 Thread artnaseef
+1

Note that the actual list name comes up as "[hidden email]" in this post, so
my vote is not for the name itself.

With that said, cleaning up the DEV list - so that PRs, commit messages,
and other auto-generated git notices do not distract - is most welcome.

Art




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6

2017-12-05 Thread artnaseef
-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: [DISCUSS] Removing the Web Console

2017-07-04 Thread artnaseef
What is the "rh-messaging project" 

On Mon, Jul 3, 2017 at 3:34 PM, MichaelAndrePearce [via ActiveMQ] <
ml+s2283324n4728194...@n4.nabble.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 <[hidden email]
> > wrote:
> >
> >>
> >> On Jun 29, 2017, at 1:59 PM, Michael André Pearce <[hidden email]
>   email] >> 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 <[hidden email]
> > 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
> >>> <[hidden email]
> > 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 <[hidden email]
> > 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 <
> > [hidden email]
> > 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
> >> Hawt

Re: [DISCUSS] Removing the Web Console

2017-07-04 Thread artnaseef
Please catch me up here - are we saying that the Artemis built-in web
console will be running HawtIO???

Art


On Tue, Jul 4, 2017 at 7:15 AM, rajdavies [via ActiveMQ] <
ml+s2283324n4728199...@n4.nabble.com> wrote:

> On the “about” page - it would be polite to reference the hawtio comunity
> - i.e. “Artemis Management console is powered by hawtio: hawt.io <
> http://hawt.io/>” etc - as there is no powered by logo.
>
> > On 3 Jul 2017, at 23:52, Michael André Pearce <[hidden email]
> > wrote:
> >
> > Ok,
> >
> > So i think we can do this. From a local build.
> >
> > Please see screenshots.
> >
> > https://gist.github.com/michaelandrepearce/
> 98b4be98d20f407c2d745a41df9cef03  michaelandrepearce/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 <[hidden email]
> > wrote:
> >>
> >>>
> >>> On Jun 29, 2017, at 1:59 PM, Michael André Pearce <[hidden email]
>   email] >> 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 <[hidden email]
> > 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
>  <[hidden email]
> > 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 <[hidden email]
> > 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 <
> >> [hidden email]
> 

Re: [DISCUSS] Removing the Web Console

2017-07-03 Thread artnaseef
I just saw this thread; haven't read the entire history, so I apologize for
any misperceptions.

Here are some fundamental requirements for the Web Console that I feel
strongly must be met:

   - ActiveMQ must have a built-in web console that requires minimal/no
   configuration to enable
   - This web console must come out-of-the-box with the broker
   - This web console must be easily kept up-to-date with broker changes
   - Functionality that must be present (parity with existing console):
  - View the list of queues and basic status (number of messages on the
  queue, total enqueue count, total dequeue count, consumer count, ...)
  - View the list of topics and basic status (number of enqueues and
  dequeues, subscriber count, ...)
  - View the list of durable topic subscriptions and basic status
  (number of messages in the subscription, ...)
  - Current connections to the broker
  - *and more*


As for any ideas around providing a common web tool to manage ActiveMQ and
Artemis, those are great, but the built-in web console is a must-have.  The
amount of use the web console gets, it's immediate out-of-the-box value,
and ease-of-use when assisting others are all very valuable.

Art



On Thu, Jun 29, 2017 at 11:00 AM, dkulp [via ActiveMQ] <
ml+s2283324n4728078...@n4.nabble.com> wrote:

>
> > On Jun 29, 2017, at 1:59 PM, Michael André Pearce <[hidden email]
> > 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 <[hidden email]
> > 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
> >> <[hidden email] >
> 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 <[hidden email]
> > 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 <
>  [hidden email]
> > 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 suc

Re: [DISCUSS] New logo discussion

2017-05-25 Thread artnaseef
Yeah, feels like 1 month is a good start.  Perhaps allow it to draw out a
longer (not indefinitely) if there's continued, constructive activity.


On Thu, May 25, 2017 at 7:37 AM, clebertsuconic [via ActiveMQ] <
ml+s2283324n4726567...@n4.nabble.com> wrote:

> How long should I keep the submission open before we call for a Vote.
> I thought about 1 month? It's summer, and perhaps that will attract
> students.
>
> On Thu, May 25, 2017 at 10:49 AM, Clebert Suconic
> <[hidden email] >
> wrote:
>
> > Just so as a heads up.. I will post a blog about the submission next
> > week after the US Holiday.
> >
> > On Thu, May 25, 2017 at 9:23 AM, Clebert Suconic
> > <[hidden email] >
> wrote:
> >> On Thu, May 25, 2017 at 9:16 AM, Justin Bertram <[hidden email]
> > wrote:
>  Aspect ratio - square or banner?
> >>>
> >>> I think we would need both - a banner for the top of web pages plus a
> square icon for other purposes.  Here [1] is an example submission from the
> Camel process which Clebert linked to at the beginning of this thread.
> >>
> >> If the submission is also including an abstract image.. a square image
> >> would be great... yeah...
> >>
> >>
> >> @Michael Pearce: I loved the abstraction for MQ..
> >> I wouldn't put the 6 on the Logo though.. just for practical reasons..
> >> (What to do when there's a 7?)
> >>
> >>
> >>>
> >>>
> >>> Justin
> >>>
> >>> [1] https://github.com/apache/camel/pull/1556/commits/
> f28ff8739cc895314a95ebec323c075c38a08813
> >>>
> >>> - Original Message -
> >>> From: "Timothy Nodine" <[hidden email]
> >
> >>> To: [hidden email]
> 
> >>> Sent: Wednesday, May 24, 2017 4:20:08 PM
> >>> Subject: Re: [DISCUSS] New logo discussion
> >>>
> >>> Aspect ratio - square or banner?
> >>>
> >>> 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.
> 
> 
> 
>  thoughts?
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://activemq.2283324.n4.nabble.com/DISCUSS-New-logo-
> discussion-tp4726454p4726567.html
> To start a new topic under ActiveMQ - Dev, email
> ml+s2283324n2368404...@n4.nabble.com
> To unsubscribe from ActiveMQ - Dev, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-New-logo-discussion-tp4726454p4726594.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: Anyone going to JavaOne? Proposed Hackathon

2016-09-20 Thread artnaseef
I am in town. 

Sent from my iPhone

> On Sep 14, 2016, at 5:14 PM, John D. Ament-2 [via ActiveMQ] 
>  wrote:
> 
> Hey, 
> 
> I know I've been busy the past few weeks.  Wondering if anyone else from 
> ActiveMQ is planning to be at JavaOne next week?  Would be great to meet 
> some other devs. 
> 
> There's a proposed hackathon next week to make TomEE work with ActiveMQ 
> Artemis.  Jonathan Fisher is running it and I'm planning to be there. 
> 
> https://twitter.com/tomitribe/status/776133447265902593
> 
> John 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://activemq.2283324.n4.nabble.com/Anyone-going-to-JavaOne-Proposed-Hackathon-tp4716528.html
> To start a new topic under ActiveMQ - Dev, email 
> ml-node+s2283324n2368404...@n4.nabble.com 
> To unsubscribe from ActiveMQ - Dev, click here.
> NAML




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Anyone-going-to-JavaOne-Proposed-Hackathon-tp4716528p4716672.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: [VOTE] Apache ActiveMQ 5.13.3 #2

2016-05-01 Thread artnaseef
+1

The tests all pass for me now.  Very nice.




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-5-13-3-2-tp4711327p4711414.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [VOTE] Apache ActiveMQ 5.13.3

2016-04-27 Thread artnaseef
OK, so here's my -1

Once that fix is back-ported, please let me know and I'll run the 3.5 hours
of tests again ;-).

Otherwise, the build looks really good to me.

Thanks!


On Wed, Apr 27, 2016 at 4:05 AM, christopher.l.shannon [via ActiveMQ] <
ml-node+s2283324n4711270...@n4.nabble.com> wrote:

> The test failure is not an issue because the test itself is the problem.
> It is related to https://issues.apache.org/jira/browse/AMQ-6175  Gary
> fixed
> the test in master but it wasn't backported to 5.13.x. (I'll do that now
> in
> case o a 5.13.4)
>
> We have been working gradually on fixing tests with hard coded ports (a
> lot
> have been fixed already) but not all of them have been fixed yet.  Some of
> the network tests are more tricky to not rely on hard code ports.
>
> On Tue, Apr 26, 2016 at 5:12 PM, artnaseef <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4711270&i=0>> wrote:
>
> > I keep getting the following test failure on the build:
> >
> >
> > >
> >
> testSuppression(org.apache.activemq.broker.jmx.SelectiveMBeanRegistrationTest)
>
> > > Time elapsed: 30.616 sec  <<< FAILURE!
> > > java.lang.AssertionError: one sub
> > > at org.junit.Assert.fail(Assert.java:88)
> > > at org.junit.Assert.assertTrue(Assert.java:41)
> > > at
> > >
> >
> org.apache.activemq.broker.jmx.SelectiveMBeanRegistrationTest.testSuppression(SelectiveMBeanRegistrationTest.java:86)
>
> >
> > Any thoughts?
> >
> > Note that I also had failures on another test because that test
> hard-coded
> > port numbers that were in-use on my system (that's
> > RequestReplyToTopicViaThreeNetworkHopsTest).
> >
> >
> >
> > --
> > View this message in context:
> >
> http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-5-13-3-tp4711217p4711242.html
> > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> >
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-5-13-3-tp4711217p4711270.html
> To start a new topic under ActiveMQ - Dev, email
> ml-node+s2283324n2368404...@n4.nabble.com
> To unsubscribe from ActiveMQ - Dev, click here
> <http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=2368404&code=YXJ0QGFtbGludi5jb218MjM2ODQwNHwyMDc3NjQwODU5>
> .
> NAML
> <http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-5-13-3-tp4711217p4711298.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: [VOTE] Apache ActiveMQ 5.13.3

2016-04-26 Thread artnaseef
I keep getting the following test failure on the build:


> testSuppression(org.apache.activemq.broker.jmx.SelectiveMBeanRegistrationTest)
>  
> Time elapsed: 30.616 sec  <<< FAILURE!
> java.lang.AssertionError: one sub
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.activemq.broker.jmx.SelectiveMBeanRegistrationTest.testSuppression(SelectiveMBeanRegistrationTest.java:86)

Any thoughts?

Note that I also had failures on another test because that test hard-coded
port numbers that were in-use on my system (that's
RequestReplyToTopicViaThreeNetworkHopsTest).



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-5-13-3-tp4711217p4711242.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Links to ActiveMQ Archived Releases?

2016-04-08 Thread artnaseef
Today (maybe earlier), http://archive.apache.org was put into maintenance
mode, making all of ActiveMQ's archived content unavailable (not to mention
others).  This means that the download links on all release pages, except
the latest one on each of the two maintained branches, fail to download.

I inquired with the infrastructure team and this was part of the response:

> We would also appreciate it if people could take the opportunity to find
> ways of using Apache products without relying too much on our archive to
> send out petabytes of data that could be obtained elsewhere.

Should links to ActiveMQ's archived releases be pointing a the Maven central
location for the same instead of the archive server?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Links-to-ActiveMQ-Archived-Releases-tp4710537.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: ActiveMQ : Integration of C.

2016-04-08 Thread artnaseef
Can you provide details of the problems seen?  I haven't used ActiveMQ-CPP
myself in a while, but I would expect building it from sources on any modern
Linux system to work.



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


Re: ActiveMQ 5.13.3 and 5.14.0 release schedule

2016-04-08 Thread artnaseef
Yeah, AMQ-6203 should be a big win for a major headache, if the fix
eliminates the problem.

Please include it in the 5.13.3 release at the very least.  Probably a new
release of 5.12.x too, unless 5.14.0 comes out in the next couple of weeks.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-5-13-3-and-5-14-0-release-schedule-tp4710502p4710529.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: ActiveMQ : Integration of C.

2016-03-27 Thread artnaseef
This is an uncommon situation.  Here's my thoughts (note that I was a "Unix
and C" developer for many years before moving over to Java):

1. Either approach can work
2. Java runs within a virtual machine (the JVM) and is designed that way
a. It is great for execution of java applications
b. It kinda stinks for integration into native programs (like those
created by compiled "C") as the JVM is not light-weight (not even if you
wanted a the simplest library routine)
3. JNI is a good tool when it is absolutely necessary to make use of native
code from within the JVM
4. Because of 2b, though, JNI is not a great approach for using Java code
from native code

To clarify what I mean in 2b, here's just one potential concern: the JVM
uses garbage collection for its memory management while "C" programs use
application-managed memory (e.g. malloc and free); splitting memory between
the two approaches becomes a challenge for the application, and insight into
the handling and performance of JVM memory in the native program will be
challenging (JVM OutOfMemory condition is very different than a "C"
program's failed malloc call).

So, my personal recommendation: do not go the JNI route for a "C"
application unless you must.

On the other hand, if there is a strong desire to use native Java code to
interact with ActiveMQ via OpenWire, which is a good practice since it's the
primary client interface and is always guaranteed to be maintained ahead of
others,  then perhaps a split architecture of the application makes sense. 
The ActiveMQ client can be written in Java and use another IPC
(inter-process communication) to hand-off the message to the "C"
application, and get the results back.

Note that the ActiveMQ-CPP library is good solution in my experience, so
going with a native Java application may be overkill.

Hope this helps.



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


Re: Building AMQ 5.13.1 from tag

2016-02-19 Thread artnaseef
I wonder if it's timezone-related.  There's odd logic in the test looking for
8:50, based on the snippet Jamie posted.

Oddly it's using 20 minutes into the epoch as the time, and then somehow
expecting a different result if that returns 8 and 50 as follows:

if (startHours == 8 && startMinutes == 50) {



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Building-AMQ-5-13-1-from-tag-tp4707866p4707888.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] ActiveMQ {CodeName} Web Console...

2015-12-14 Thread artnaseef
I would love to see this console added to the ActiveMQ code base.  Whether we
move it toward inclusion as a new console is something we can look at going
forward.

Adding it as a tool available directly from the main broker Jetty page would
be great.

Playing with AMQC against remote brokers does raise the concern of CORS. 
The recommendation on the wiki was to disable the browser CORS checking -
I'm not a fan of disabling security features.  With that said, including
AMQC with the broker's Jetty server would eliminate that concern for the
local-broker case.

The next step here would be either a Pull Request adding the code into the
AMQ codebase.  It would be awesome if the code could be reused for Artemis
as well, but following the "use before reuse" methodology, that can come
later.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-ActiveMQ-CodeName-Web-Console-tp4694984p4704931.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Messages between Brokers

2015-11-18 Thread artnaseef
There are two approaches I would recommend.

First is the "network of brokers," which is the simpler one to setup, but
introduces race conditions and caveats (e.g. reduced reliability of temp
destination and topic message flow):

http://activemq.apache.org/networks-of-brokers.html

Second is the use of "static routing," in which you setup the brokers with
bridges that always move messages for specific destinations in one
direction.  There's more than one way to accomplish this:

a. "Pure static networks" section of the network-of-brokers page
b. JMS bridges in ActiveMQ
c. Camel routes
d. other

Note this is not in any particular order.




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


Re: [DISCUSS] OSGi support for Artemis

2015-11-16 Thread artnaseef
Here's a script that will nicely list all of the packages with more than one
source root followed by the list of roots:



Note that for the AMQ source code, it comes up with many things, including
(this is partial output):





--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703990.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] OSGi support for Artemis

2015-11-16 Thread artnaseef
A simple shell script would work well if we have access to all the
directories.

Something like this:



Or, this is even better:





--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703989.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] OSGi support for Artemis

2015-11-15 Thread artnaseef
How much work are we talking to get Artemis properly OSGi-ready?  An uber-jar
is a work-around.  If nothing better can be accomplished, then we may have
to live with it in the near-term, but it is important to understand what
challenges are driving us toward a work-around.

Also, we have an individual showing interest to make this happen, so let's
encourage that effort!  Thank you Guillaume.

I may be a bit tainted as these days I'm spending large amounts of time
refactoring code and eliminating the impacts of work-arounds and shortcuts.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703972.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Release ActiveMQ 5.11.3....

2015-10-28 Thread artnaseef
That's great Daniel.  I have nothing outstanding for 5.11.3.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Release-ActiveMQ-5-11-3-tp4703386p4703461.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Compatibility of Versions 5.5.1 and 5.6/5.7

2015-10-28 Thread artnaseef
Note that 5.6 had a lot of NOB issues.  There are ways to bridge the brokers
if you only need static routing (i.e. the direction of message flow is
fixed).

For example, a simple camel route can be used.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Compatibility-of-Versions-5-5-1-and-5-6-5-7-tp4703391p4703460.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Compile failure

2015-10-28 Thread artnaseef
One question is coming to mind.  I see the maven command is running the
"clean" command.  However, I wonder if the workspace for the build has been
wiped clean recently.

This commit moved the file from "src/main" to "src/test"
5c6b8ba11f2e77cd7fb6102f7ad0cb759ca26723.  That dates back to 2013 though.



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


Re: Compile failure

2015-10-28 Thread artnaseef
Personally, I've never seen activemq run into duplicate classes in this way. 
I'll attempt the build with the same options and see if I can reproduce it
locally.

Note that the "-fae" option allows us to get all of the tests run even when
there is a failure because ActiveMQ has been notorious for tests that fail
intermittently.  Without the "-fae" you could run the build many times and
never reach the end even with different tests failing on each run.

Another thing that would be good to check - search the build directory for
all *.java and *.class files for the reported duplicates.  That might help
us to track down from where they are being introduced.



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


Re: [VOTE] Release ActiveMQ-CPP v3.9.0 #2

2015-08-14 Thread artnaseef
+1

Thank you Tim.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Release-ActiveMQ-CPP-v3-9-0-2-tp4700871p4701099.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] Including Camel in activemq-all

2015-08-14 Thread artnaseef
OK, so it sounds like a nice-to-have, but not expected to be an essential
part of any production-grade solution.

Makes sense.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-Including-Camel-in-activemq-all-tp4700996p4701096.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] Including Camel in activemq-all

2015-08-14 Thread artnaseef
Before the feature to allow camel routes to intercept incoming messages
(http://activemq.apache.org/broker-camel-component.html), camel really just
depended on ActiveMQ, but ActiveMQ didn't depend on camel.

Now with that feature however, it seems like it makes sense to go in that
jar file.

Actually, can anybody clarify how the activemq-all jar file is used and/or
why it's really needed?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-Including-Camel-in-activemq-all-tp4700996p4701093.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [HEADS-UP/Discussion] Artemis: Planning a release soon

2015-08-13 Thread artnaseef
My recommendation is to use semantic versioning and stick with it:

* x.y.z
* z = bug fixes only
* y = any new features or changes to existing features
* x = any backward compatibility loss in APIs / usage of the product

With that said, whatever approach is used, let's make clear guidelines and
stick with it.

The biggest advantage of sticking with semantic versioning is it's
wide-spread use in the industry, with maven, and in the open source
community.  For example, IIUC, maven will allow a dependency upgrade at the
minor version level but not at the major version level (when there are two
dependency chains leading to different versions of the same artifact).




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/HEADS-UP-Discussion-Artemis-Planning-a-release-soon-tp4700793p4701053.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Create network of brokers dynamically using java

2015-08-13 Thread artnaseef
Is it not possible to use a broker discovery method for this purpose?  It
should be simple enough to implement the DiscoveryAgent interface and plug
it into the brokers.  Take a look at DiscoveryNetworkConnector for that
approach.

To directly add network connectors to a running broker, use one of the
BrokerService.addNetworkConnector() methods.  Note that it may be necessary
to "manually" start the connector after using one of these methods, if the
broker is already running.

If you don't have the BrokerService object easily injected into the code in
question (the preferred method), then the BrokerRegistry may be the solution
to obtaining it.

Hope this helps.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Create-network-of-brokers-dynamically-using-java-tp4700870p4701050.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Too many updates in MySQL

2015-08-10 Thread artnaseef
OK, extracting one SUB_NAME and CLIENT_ID combo, something else looks wrong
here:

  Query,UPDATE ACTIVEMQ_ACKS SET LAST_ACKED_ID=25026\, XID = NULL WHERE
  CONTAINER='topic://testTopic' AND CLIENT_ID='AP8DA27' AND SUB_NAME='test3'

  Query,UPDATE ACTIVEMQ_ACKS SET LAST_ACKED_ID=25027\, XID = NULL WHERE
  CONTAINER='topic://testTopic' AND CLIENT_ID='AP8DA27' AND SUB_NAME='test3'

  Query,UPDATE ACTIVEMQ_ACKS SET LAST_ACKED_ID=25026\, XID = NULL WHERE
  CONTAINER='topic://testTopic' AND CLIENT_ID='AP8DA27' AND SUB_NAME='test3'

  Query,UPDATE ACTIVEMQ_ACKS SET LAST_ACKED_ID=25027\, XID = NULL WHERE
  CONTAINER='topic://testTopic' AND CLIENT_ID='AP8DA27' AND SUB_NAME='test3'

Notice that the ACK ID 25026 is updated, then 25027, and then both again. 
Perhaps I'm misreading the Ops pasted content.




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Too-many-updates-in-MySQL-tp4700512p4700740.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Too many updates in MySQL

2015-08-10 Thread artnaseef
Actually, it looks like the updates are not storing new information, but
simply repeatedly storing the acknowledgement table.

I need to review the code to be sure how this works.  I believe the ack
table is re-written periodically.  However, I *may* be thinking of KahaDB
logic that does not apply to MySql.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Too-many-updates-in-MySQL-tp4700512p4700739.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Memory limit reached

2015-08-10 Thread artnaseef
Thanks for letting us know - glad you were able to track it down.



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


Re: [VOTE] Apache ActiveMQ 5.12.0

2015-08-10 Thread artnaseef
I agree with more frequent releases.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-5-12-0-tp4700720p4700735.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [VOTE] Apache ActiveMQ 5.12.0

2015-08-10 Thread artnaseef
Ah, looking more carefully, that is correct.  While I did only see the notice
this morning, it's been out there since July 30.  I must be mixing 5.11.2
and 5.12 stuff.

I have some outstanding improvement work on selector issues, but it needs at
least a few more days of work.  If we're comfortable to have a 5.13 release
within 1-2 months after the 5.12 release, then I won't worry about it.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-5-12-0-tp4700720p4700734.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [VOTE] Apache ActiveMQ 5.12.0

2015-08-10 Thread artnaseef
Whao - that was fast.  I just saw the messages this morning announcing plans
to release 5.12.0 and now it's already up for a vote?

What's the rush?  Can we slow this down so folks who have things to
contribute to a once-in-six-to-twelve-months release can find time to work
on them?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-5-12-0-tp4700720p4700727.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Maven dependencies

2015-08-10 Thread artnaseef
Yup, looks like a version issue.

Also, taking a quick look at [2] in the Ops message, it seems the author
there is using the activemq maven plugin as a way to get started quickly
with using ActiveMQ.  I wouldn't go that route to start with as it can be
harder to see what's going on with ActiveMQ.

My recommendation is to run ActiveMQ locally.  Download the TGZ or ZIP file
and run it that way, preferably with the "console" options (e.g.
bin/activemq console) so that you can see the broker logging on the console. 
Of course, this requires a dedicated terminal window.

Here's the "getting started" page for ActiveMQ itself:
http://activemq.apache.org/getting-started.html

Once you have activemq running on its own, then configure your client to
connect to it using the TCP transport (e.g. broker url
tcp://localhost:61616).

Hope this helps.



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


Re: Memory limit reached

2015-08-07 Thread artnaseef
Are transactions in use?  Perhaps this is the result of an open transaction.

I would need to look more closely at the code to see under what conditions
this can happen, and exactly what that queue size 0 means.

Another thought - look at the inflight count for the queue and make sure
that's zero as well.



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


Re: [VOTE] ActiveMQ 5.11.2

2015-08-07 Thread artnaseef
Hey - I don't expect to find time to test this release before the vote period
is up, so here's my vote:

+0

@Dan - I had started merging many of the outstanding bug fixes for a 5.10.3
release and identified a list of candidate bugs to back-port to both 5.10.2. 
Have you seen the list?  If not, I can find the nabble link and post it back
here.  If you are interested to work together on getting more bug-fixes back
ported to either 5.11.x or 5.10.x, please let me know and I'll get my
existing merges up to github so we can collaborate.

Thank you.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-ActiveMQ-5-11-2-tp4700508p4700594.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Message Groups and long running transactions

2015-07-07 Thread artnaseef
This is an interesting mix of needs.  Using message groups to ensure ordered
processing of messages while at least some of the messages take excessive
periods of time to process.

Can the slow-processing messages be separated from the message-groups?

Note the default message group handling uses a hash bucket of group
assignments to consumers, meaning multiple groups are assigned as a unit. 
So, assigning the slow messages to only one group will not prevent mixing
with fast messages (remember one consumer may be assigned multiple groups).

The -1 sequence on the group only takes effect as that message is dispatched
to the assigned owner (when it has prefetch space available), meaning it
goes to the same old owner as the message immediately before it, but then
new messages may go to a different owner.  So, actually, a higher prefetch
may be needed so that the -1 sequence message can be dispatched, but then it
will only affect messages that come after it, not those from before. 
Assigning a sequence number of -1 for the group on the slow messages would
do the trick - if combined with a prefect of 1.

Of course, if the fast and slow messages are in the same group, then the
fast messages need to wait for the slow ones to process.  That's the point
of message groups.

Another thought - is it possible eliminate the use of message groups adding
a message aggregator (camel) to collect all of the messages that require
sequential processing and feed them back out as a single message?




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Message-Groups-and-long-running-transactions-tp3499325p4698769.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Please review: Unix Init Script Improvements - strange options "export" and "create"

2015-07-07 Thread artnaseef
One thought here.  There's a lot of complexity and functionality in the
existing scripts.

Perhaps it would make sense to start a new set of smaller scripts that are
more focused on individual tasks.  If we want to have a master script so the
command-name is the same across multiple functions, that would be easy
enough to do.

One concern here is breaking backward compatibility and ease-of-upgrade for
users.  The 5.11.1 script updates (maybe earlier?) did make at least one
non-backward-compatible change.

I have a lot of thoughts on the scripts (I was a Unix & C dev longer than
I've been a Java dev).  Let's chat on IRC if you're interested.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Please-review-Unix-Init-Script-Improvements-tp4698378p4698743.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] enabling svngit2jira integration?

2015-07-07 Thread artnaseef
This sounds good to me.  Fisheye has always been far too slow in my
experience.

I take it this will only apply to new commits and no history will be
back-filled, right?  That's probably a good thing.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-enabling-svngit2jira-integration-tp4698723p4698727.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


AMQ-5695 kahadb files not being cleaned up

2015-06-23 Thread artnaseef
Has anyone else seen this issue?  The KahaDB files are not being cleaned up
even though there are no old messages out there.  Disconnecting all clients,
the problem did not clear itself, so it doesn't appear to be an issue of
unacknowledged messages or anything similar.

https://issues.apache.org/jira/browse/AMQ-5695




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/AMQ-5695-kahadb-files-not-being-cleaned-up-tp4698115.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [HEADSUP] ActiveMQ 5.10.3 release preparation

2015-04-27 Thread artnaseef
Update - this past weekend I did not manage to get any time on this release,
and this coming week, I won't be able to put much time into it either.

As for a 5.11.2 release, it makes sense to create that release as well. 
I'll keep you informed.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/HEADSUP-ActiveMQ-5-10-3-release-preparation-tp4695445p4695704.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: IRC channels - Codehaus to Freenode

2015-04-23 Thread artnaseef
Oh, and thanks for taking the action and getting the IRC room properly
registered.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/IRC-channels-Codehaus-to-Freenode-tp4695526p4695550.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: IRC channels - Codehaus to Freenode

2015-04-23 Thread artnaseef
Hey, let's make this an announce.  I'll tweet it too.

Jeff - do you want me to start a new thread with "[ANNOUNCE]" in the title
and copy your text?

Hmm, maybe we should put it in the news feed on the activemq website as
well...



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/IRC-channels-Codehaus-to-Freenode-tp4695526p4695549.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [HEADSUP] ActiveMQ 5.10.3 release preparation

2015-04-22 Thread artnaseef
Thanks JB.  I hope we can target a 5.12.0 release for May.

If you change your mind and decide some commits are important, please let me
know and I'll work with you to either get them in, or decide the best
alternate course of action.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/HEADSUP-ActiveMQ-5-10-3-release-preparation-tp4695445p4695466.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [HEADSUP] ActiveMQ 5.10.3 release preparation

2015-04-22 Thread artnaseef
I can do that - no problem.  But it will have to wait until the cherry
harvest is complete.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/HEADSUP-ActiveMQ-5-10-3-release-preparation-tp4695445p4695465.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [HEADSUP] ActiveMQ 5.10.3 release preparation

2015-04-22 Thread artnaseef
To come up with the commit list, I used "git log" to find all commits from
the time of the last release until now, on the master branch.  Then, I
literally reviewed each, looking at the following:

* commit comments
* Jira tickets, if any was identified in the commit comment
* actual code changes

I looked for commits that appear to be important bug fixes, or low-risk
updates.  And I avoided anything that is a pure enhancement (like new
features) or any dependency version changes as they could create
compatibility problems for users.

Honestly, I don't have a strict set of criteria.  And, the process I'm
following, which seems like a good one to me - is to publish the list as
done here and ask for input.

Wheh.

As for the AMQ-5709 fix, I will give Gary a little time in the hopes he will
give some input, and then follow up with you.

Looking at the total list of recent changes, I am considering to target a
May release of 5.12.0, and so I'm personally not too concerned about missing
some useful updates.  However, it would be good to make this release as
useful as possible.  The biggest risk here, with that said, is partial
updates from cherry-picked updates leading to failures - hopefully failures
caught by tests, but even so - with the amount of time it takes to run
tests, a long list of commits increases the chances the entire release will
delay for a significant amount of time.

Another wheh.

I am cherry-picking and looking at clashes.  Already fixed about 3 or 4;
they were minor.  Even one which I couldn't understand why it was a conflict
as the local side of the conflict was empty.  If the conflicts for a commit
are great and involved, I'll likely note it here and then drop it from the
release unless someone else wants to help on that front.

Finally, my branch plan - work directly off the 5.10.x branch locally.  Once
I have all the commits in the branch, run a full build.  If all passes, then
I'll push the branch and continue the release process.  Otherwise, I'll
resolve failures, rinse-and-repeat.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/HEADSUP-ActiveMQ-5-10-3-release-preparation-tp4695445p4695463.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [HEADSUP] ActiveMQ 5.10.3 release preparation

2015-04-22 Thread artnaseef
We can apply that fix it you feel strongly about it.  The only reason I'm
holding off that specific fix right now is the discussion I started on the
ticket regarding the desired new state of operation.

I saw your response there - thank you.  If we could get Gary to comment,
that would address or eliminate all of my concern.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/HEADSUP-ActiveMQ-5-10-3-release-preparation-tp4695445p4695451.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [HEADSUP] ActiveMQ 5.10.3 release preparation

2015-04-22 Thread artnaseef
NOTE: commit 72837960cffc58b559ced6c243a459c62cb153cf is not an actual commit
from the AMQ repo; the commit be6617507914532188530a605e476cb8ae59cdce
covers it.

Apologies for any confusion.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/HEADSUP-ActiveMQ-5-10-3-release-preparation-tp4695445p4695452.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [HEADSUP] ActiveMQ 5.10.3 release preparation

2015-04-22 Thread artnaseef
Hiram - if you provide the specific commands that will get me the exact
output you want from the list of commits, then I'll gladly run them.

Getting a log of the precise commit list is not trivial in my experience.

You're assistance is greatly anticipated.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/HEADSUP-ActiveMQ-5-10-3-release-preparation-tp4695445p4695449.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] dev mailing list is cluttered

2015-04-22 Thread artnaseef
What are the next steps here?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4695448.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


[HEADSUP] ActiveMQ 5.10.3 release preparation

2015-04-22 Thread artnaseef
I have started working on the 5.10.3 release.  Here is the list of commits
that I plan to include in the release.

Please advise of others which are important.  Note that I haven't yet
reviewed open patch submissions and will do so shortly.  Also note that I
haven't yet confirmed that all of these commits are valid for the 5.10.3
release.

In the interest of keeping this brief, only the commit hash codes are listed
here.  If anyone feels it would be helpful, I'll put up a confluence page
with this list and either add the commit comments or a link to obtain the
same.

commit be6617507914532188530a605e476cb8ae59cdce
commit 72837960cffc58b559ced6c243a459c62cb153cf
commit ec9a92f6fc5554017e1b3551b24e2e19e0da8fbc
commit 2562cf21a2fdfd3b0301160e28b7109d85f38cfe
commit b29eb384b8e6b24f2b11242f1ddb464413301e5a
commit f2837bac037569d77660c9f997b07918e02d5671
commit c705523cd047fcdd6231cb936abc4ef5b4cf5816
commit e16d054362b51786576b71d01031aec1550653db
commit 299410820e92797abbf00db5c97827d37d1c2052
commit a6243225c5be2f8eaa7121e9616315e1b5661483
commit 6df02555fde8bfcee003b1d248bcfcc454ad2c6f
commit 516c9db43b25a9a5679dd854af9a22b7104d27be
commit 8bb58036a0251aa03301dc2c79d24076e0e8c8ff
commit a39e51e0519852332f7779443c3db09b6e691d49
commit efc9a8d5782143b8c1e86750d34ce74af5a2940a
commit e33b3f5939c1b48a35df54eae13757f44a179650
commit 559f52a2aa1e30d945d48d8de3bfbff348dee463
commit 10c47d69d7545157f79d9b1dff15eabca147754d
commit 55f040e616899262d19c2bd1178826a65359516c
commit 3b39d2cc2a20f42e43b2699a76c0d007e7ec5dd9
commit 7738e862ae5337cb9d8d07092e57520e8368f912
commit 3ef8f492a7cb9c056ac1883ccb069e9559fc6b22
commit ab28b771e367d8fa4f9591fb88cb9c29ec41c25a
commit 42b606da9d9f4fa9f9c926f7c04d2fa134fb334a
commit 8c66fba0aab96a5f842b52b634690a8bff0b03b3
commit 113a3815b0fef93ccf9b2dcf7ccf9f196e182f0d
commit 5313ad8a96279c63fb1b6a97513c142eba778643
commit 4d5bb4ab7b09ba48d605850ab1aaac594bb66f65
commit 4b346360be63d5b60d94eb47f86d24e1d20dd2fe
commit 6e038d5ffd20678efac42c410fd7c2e0266b4416
commit ecebd2413b878ba87710db9541f6bf353ceeb96e
commit 260e28ecadc654ce3f0a5b6c7058788235265574
commit f00d2fbde4b4dca72a8fd961ef8d5895e1b80584
commit 05b401993b215c55e26f2e3143ec5758bfc6
commit 141ad4cb8f302c16d64d2ee95480ce2897dd5f80
commit 2b17fd805098e0c42821dacd5695db067ce594f6
commit 25376afac1d504e5c068ca44d6a47cedf188cfe5
commit c6837acefe8ca466d8cd9b3bd9adf297372b65b8



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/HEADSUP-ActiveMQ-5-10-3-release-preparation-tp4695445.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Special Board Report

2015-04-20 Thread artnaseef
I didn't even catch up on this entire thread, so forgive me if I missed
something.  It's wearing me out - again.

Look, it's last minute.  No quick fixes are coming.

There are some good things happening now, but they won't fix things today or
tomorrow.  Given the timing and the threat of board action, it's natural to
question sincerity.

Let's get the board report finished.

Hiram - please add to the board report Hadrian's belief that the best path
forward for the new code is to take it to the incubator.  Mention that at
least one other board member feels that path is likely the best one forward
- especially given the problems currently faced by the ActiveMQ community. 
Just state it as fact - that it's the opinion of individual PMC members.



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


Re: Plan clarification

2015-04-17 Thread artnaseef
Hiram - the new code base will be released with version number 1.0.0, right?



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


Re: Plan clarification

2015-04-17 Thread artnaseef
Hey Bruce - the original thread for the board report was on @dev.  Unless
there's a real need to take it back to @private, I think it is good to work
through the report in the open so members of the community can see the
discussion and contribute to it.



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


Re: [VOTE] Pick a code name for the HornetQ code donation

2015-04-16 Thread artnaseef
Ah, thanks for setting me straight.  I am going to stick with Artemis anyway
as that was the direction I was leaning originally.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Pick-a-code-name-for-the-HornetQ-code-donation-tp4694889p4695103.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [VOTE] Pick a code name for the HornetQ code donation

2015-04-16 Thread artnaseef
I was staying quiet because I didn't feel too strongly about the name, due in
part to past use of the name Artemis (outside Apache), but thinking about
how the name "ActiveMQ ReactiveMQ" would likely get shortened by most folks
to just "ReactiveMQ" to eliminate the redundancy, changed my mind...

+1 Artemis




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Pick-a-code-name-for-the-HornetQ-code-donation-tp4694889p4695100.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [PROPOSAL] Move IRC channel to freenode ?

2015-04-16 Thread artnaseef
Ah - Bruce beat me to the update.  I added notes to move away from codehaus
and avoid #activemq on FREENODE.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Fwd-PROPOSAL-Move-IRC-channel-to-freenode-tp4694923p4695097.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [PROPOSAL] Move IRC channel to freenode ?

2015-04-16 Thread artnaseef
OK, I'll update the Apache ActiveMQ website to refer to the new
#apache-activemq channel on freenode and indicate the old channel is
deprecated.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Fwd-PROPOSAL-Move-IRC-channel-to-freenode-tp4694923p4695094.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: New PR build for ActiveMQ 5.x

2015-04-16 Thread artnaseef
Nice touch.  Looks like it needed a little tweaking, but looks good now.

I agree on the unit testing as well.  We want to have some base unit tests
to run, but I don't believe we are prepared at this time to do so.




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/New-PR-build-for-ActiveMQ-5-x-tp4695015p4695092.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-04-09 Thread artnaseef
+1

(Please pardon my reference to Buddhism here)

In buddhist practice, we remind ourselves of many things every time we
practice.  One of those is stated this way, "forgive me for divisive
actions," and, "I promise to avoid divisive actions."  We all do it, whether
with intent or not, but in the long run, it only leads to anger,
frustration, ...  Suffering.

All the heated arguments here that attack all the value of all the great
work of the past done by the folks on this project is truly sad.  I only
hope that there are enough folks either not listening, or believing that
this is just one large "vent" so this conversation doesn't drive folks away
from ActiveMQ.

A culture of respect and honest interest in technical concerns, impacts on
users and others across the community, and a focus on moving things forward
-- that's a vision I dream of when I think of being a core member of the
ActiveMQ community.  I long for more discussions like ones I have had with
Hadrian - in which we actually talk about ideas and work together to make a
solution better than either one of us would have made alone.  It's awesome. 
I highly recommend everyone to try it.

Please move past the fighting.  Every foolish thing any one of us has ever
said can be forgiven.  Every one here is valuable, and can bring that value
to ActiveMQ - it's our actions and the impact they have on ActiveMQ - both
the product and the community - that are our measure.  Let's strive for the
ideal - working together (not without disagreement) - bringing out valid
concerns and providing valid responses, considering impacts and deciding
which to accept, and how to minimize where possible.  Then work toward
resolution through decision-making and acceptance that no path forward will
be perfect, and all paths forward that are worth taking require effort -
true effort.

With this said, I'm going back to focusing on other parts of my life at the
moment as this entire discussion has drained so much of my energy for a week
or two, and those parts have been neglected.  Please PM me if my input is
valuable and desired, or my absence is somehow blocking, before I return
more prominently (probably after ApacheCon), when it will be time to get the
next patch release of ActiveMQ built (I will do all the grunt work, although
help is appreciated - thanks to Hadrian again for his past help in creating
releases)!




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4694603.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] dev mailing list is cluttered

2015-04-07 Thread artnaseef
I'm OK either way.  This is something that can be undone without too much
hassle if a later objection arises, but not without a little impact (that is
messages in the interim being in a different place).



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694463.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] dev mailing list is cluttered

2015-04-07 Thread artnaseef
So the Infra team manages Jira and mailing lists?

What about nabble - will it also be included, or is there more work to do
there?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694453.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] dev mailing list is cluttered

2015-04-07 Thread artnaseef
Hey Bruce - I would like to learn the process here.  Can you help me?

Was the request made simply by creating a Jira entry?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694448.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] dev mailing list is cluttered

2015-04-07 Thread artnaseef
It sounds like the Jira list is the way to go.

How can I go about getting the list created and messages redirected?  I
think iss...@activemq.apache.org is the way to go.

Art




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694440.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS] dev mailing list is cluttered

2015-04-07 Thread artnaseef
+1

That works.  It looks like the volume of github notifications is much lower
- and appear to be mostly pull requests, so moving out the jira entries
would be a big win.




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694438.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


[DISCUSS] dev mailing list is cluttered

2015-04-07 Thread artnaseef
Using Nabble, as I do, to keep up with the dev mailing list, this is what it
looks like to me whenever I look:


 

Actually, there are two more discussions easily visible this time than I
normally see.  All of the jira, github, and other (?) notifications make it
hard to find meaningful discussions.

Any ideas on how we can solve this?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: ApacheCon 2015

2015-04-06 Thread artnaseef
I am coming in Tuesday evening and leaving Wednesday evening and hope to meet
as many of the folks here as possible.

It sounds like I'll be in too late to catch up with Bruce.



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


Re: Code donation for stomp.js

2015-04-02 Thread artnaseef
On the placement question - is there anything ActiveMQ-specific?

If not, would it be best with its own repo, like ActiveMQ-CPP?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Code-donation-for-stomp-js-tp4694260p4694276.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [PROPOSAL] Pluggable Brokers...

2015-03-31 Thread artnaseef
I'm not sure how this proposal fits into the existing ActiveMQ solution at
this point.  It should be feasible to start down this path and consider how
it fits later down the line.

Giving it a little thought right now, one possible approach would be to get
the API defined, and then make a new messaging solution by taking key
ActiveMQ features (e.g. virtual topics) and putting them into a new artifact
that uses the Engine API.

I have another concept that may help to see how this proposal innovates. 
This borrows from the "use before reuse" idea.  Instead of creating a single
messaging solution (or broker), having a toolset for creating messaging
solutions makes it possible to better address diverse needs.

Another concept...  We have socket, filesystem, and other APIs that make
networking, file storage, and other needs in applications easy.  There are
multiple implementations of these APIs (every O/S has its own).  And we have
messaging APIs (e.g. JMS) that makes messaging in applications easy.  In
between, we have large solutions (ActiveMQ, XMPP, etc).  What would happen
if we split that middle into two parts: one that brings up, from the bottom,
a "messaging engine" or "messaging primitives" API, creating a space coming
down from the top into which multiple implementations can be placed and more
easily developed?

Creating the best fit...



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


Re: [PROPOSAL] Pluggable Brokers...

2015-03-30 Thread artnaseef
Right, and users that use STOMP are not concerned with how well the solution
works for JMS or AMQP users.  Although some users may want support for
multiple protocols.  That's at least four use-cases right there.

An idea that keeps coming to mind -- the computer world has already
implemented the tool that "solves all problems" -- it's called a CPU.  Our
job as developers is not to write the one solution that does everything, but
to find a balance and implement the "right size".  Which raises the
question, "what is the right size?"

One messaging solution that meets all needs sounds like a huge challenge. 
That's like asking for one database solution that meets all needs.  I
wouldn't want to use a DBMS that handles large warehousing solutions
effectively in a small, embedded device.



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


Re: [PROPOSAL] Pluggable Brokers...

2015-03-30 Thread artnaseef
This is awesome.  I have been thinking of a similar idea.

Separation of concerns... Core "messaging" implementation separated from the
overall messaging solution, allowing multiple messaging solutions with
varying needs to be maintained separately while also making it possible to
replace the engine implementation easily:

--
messaging-solution
--
  |   * client API
  |   * transaction management (including XA, if so desired)
  |   * features (such as Virtual Topics)
  |   * message containers (queues, topics, chat rooms, private message
rooms)
  |   * persist message for longer-term access, as-needed
  |
  | <---  *** Messaging Engine API
  |
  V
-
messaging-engine
-
* persist messages for guaranteed delivery (only; and not a required
feature of the engine)
* route messages
* transaction support
* enable enforcement of order
* moving messages to endpoints

NOTE: this needs more thought; the separation above may not be a good
dividing line, but I hope it makes my thinking more clear.

One key I see here - the ability to create a complete messaging solution
that is tuned to specific use-cases (e.g. small, embedded architecture; or
large, enterprise messaging backbone), while using the same engine.  And,
the means to replace the engine with another one as long as the API is met.

James - is this in-line with your idea?



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


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-28 Thread artnaseef
Thank you Rob - that's great insight.  It is giving me much on which to
reflect.

With that said - since the board is involved at this time, would you mind to
table this discussion until after we hear from them?  While I would love to
continue this discussion, learn more, and share ideas, the board's guidance
can have a significant impact on taking the discussion further.

I didn't want to leave this discussion hanging without a response.

Art




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4694028.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [VOTE] Apache ActiveMQ 6.0.0 (RC3)

2015-03-28 Thread artnaseef
Hey Gary - in all the discussion, I missed this response, so forgive my slow
response.

First, let me apologize for my use of the word "take" - it sounds it was
read as an attack or accusation, and that was not my intent.  I simply
meant, "why is it important that HornetQ be called AMQ-6?"

On the point that AMQ needs a v6, can you tell me why that itself is
important?  Please be specific - I have seen many comments made that really
are just restatements of the line that ActiveMQ needs a new broker, but no
real detail to discuss behind that.  When I look at those statements, I have
to balance them with my belief of ActiveMQ's popularity, market penetration,
and ongoing efforts to add ActiveMQ into companies.

Also, have you considered the possibility that naming Apollo "AMQ-6" has
contributed apparent lack of innovation?  In other words, isn't it a concern
that it will be hard to encourage innovation on the current product,
ActiveMQ 5.x, as long as there's a promise of a very different ActiveMQ 6.x? 
I know that even causes me to pause.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-6-0-0-tp4692911p4694026.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-28 Thread artnaseef
David - please go back and read my posts (user name artnaseef, full name
Arthur Naseef).  I have repeated myself multiple times with concerns.  And
there has not been constructive response to my concerns, nor to questions I
posed in an attempt to get clarity on the position that ActiveMQ needs a new
broker.

It is disappointing because I know there is valid discussion there.

I agree this thread contains much passion and input that is unactionable
(i.e. pure criticism), and that sucks because it will never serve to move
use forward, reach conclusion, nor build consensus.  At the same time, it's
understandable and I recognize that I have inserted some myself.  So let me
be the first to apologize.  I'm sorry for statements that I've made which
have not been constructive.

Getting back to the actionable concerns raised and finding a way to address
them going forward would be greatly appreciated.

If you want me to rehash my concerns, then I'll do so, but I would prefer to
avoid repeating myself multiple times.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4694024.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: CPU core/thread scaling test

2015-03-27 Thread artnaseef
That would be wise - both the naming, and the ducking!



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/CPU-core-thread-scaling-test-tp4693913p4694007.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: CPU core/thread scaling test

2015-03-27 Thread artnaseef
Oh, very nice.  I was thinking ActiveMQ would do well to have its own load
tests from which baseline measurements could be taken.  Perhaps with a
separate source code repository dedicated to the purpose?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/CPU-core-thread-scaling-test-tp4693913p4694001.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-27 Thread artnaseef
Hey - it's clear we are not moving toward consensus right now.  I'm going to
break off and give some time to hear from others and consider the entire
situation more carefully.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693991.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-27 Thread artnaseef
I don't agree with the presumption that ActiveMQ *needs* a *new* broker.  Nor
with the argument that it will die out if it doesn't get one.

Whole-sale replacement is hard.  I worked in a company that *still* uses
technology dating back to 1980 because several efforts to whole-sale replace
the existing platform failed.  That approach is hard.  Note that I am not
arguing that it's impossible, but this does make me concerned that even with
the AMQ-6 name, HornetQ may fail to replace ActiveMQ - even as it continues
as a completely successful product of its own.

With all of that said, if it proves that ActiveMQ dies out without a new
broker, I am alright with that.  As mentioned before, if HornetQ takes over
the market, I don't see that as a bad thing and look forward to the
opportunity to contribute there, or move on to other things.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693983.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-27 Thread artnaseef
I agree with Hadrian again.  It's important for HornetQ to grow its own
community, and one that stretches beyond the Red Hat.  A project at Apache
only to satisfy the needs of a single entity does not seem appropriate.

*AMQ-6 Name*
I would also like to re-hash the concern of using the AMQ-6 name.  Doing so
raises issues.

Using the name AMQ-6 creates a presumption that HornetQ will whole-sale
replace ActiveMQ 5.x.  (Please understand I give 0 credit to the idea that
ActiveMQ 5.x could continue on as ActiveMQ 7.x - that's not reasonable).

While it is good to have a common direction and shared vision, this isn't
the right direction.  Using the AMQ-6 name puts users on notice that they
will be expected to switch; I know first hand - I started to worry about
Apollo and my team's efforts on 5.4 back-in-the-day, how much of that work
would need to be revisited, and whether Apollo would continue to meet my
needs or I would need to shop for an entirely new messaging solution. 
Which, by the way, proved to be a valid concern since Apollo didn't support
JMS in its earlier releases.

And there were missing-message and duplicate-message bugs I tracked down and
for which I personally contributed fixes; would those problems resurface
with a new solution?

It isn't wise for the ActiveMQ community to put all its users on notice that
they will be expected to switch to the new broker - at least not until we
have reached a point at which we, as a community, are convinced it is ready
to do so.  And that's a big "when" - I'm not sure it will ever happen.

*Details and Impacts*
Keep in mind that two solutions to the same problem never take the same
approach, and the detail can easily become overwhelming for users.  For
example, while it is very easy to install and start ActiveMQ for the first
time, setting up deployments and configuration management around ActiveMQ
takes time and effort.  Moving to a new broker that is a complete rewrite
means that details like these will turn into significant effort for users,
and there's no guarantee that it won't be a blocker for some of them.

So, while the strength of the code is important, it is not the only
consideration.  Programmers don't think about these things.  Developers do. 
We need to consider the entire solution, how it will be used, and the
impacts our decisions will have on others.

*My Vision*
What I would love to see happen here is HornetQ runs as a separate project
and folks who want to see it do well and take over the ActiveMQ market
contribute to it.  And, in due time, if it takes over the market, we all
have the opportunity to move and contribute with it, if we so desire.

At the same time, ActiveMQ continues on its own path, preferably with more
folks, from more places who continue to believe in it, have not tired of it,
and are investing in it.  Encouraging more committers, PMC members, and
contributors in general.

HornetQ can continue on its path of feature parity with ActiveMQ in order to
ease the transition for ActiveMQ users.  And, since ActiveMQ continues on
its own, there's less pressure on HornetQ to adopt every feature.

*Summary*
In summary, I feel strongly that it's the best path forward for HornetQ to
avoid the AMQ-6 name.  And I agree that building its own community and
learning the Apache way through the incubation process is valuable and the
best path forward.  I hope the HornetQ folks are comfortable to go through
the incubator.

With all of that said, I plan to continue to support ActiveMQ regardless of
the outcome.  In that light - anyone who wants to discuss ideas on how to
address open concerns, such as a lack of JMS 2.0 support, I welcome the
discussion; please raise those concerns in separate threads and let's start
the action down the path of resolution.

Art

P.S. I hope to see folks at ApacheCon!  I'm going to talk about a vision and
ideas for fixing some of problems AMQ has had for a long time.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693960.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: CPU core/thread scaling test

2015-03-27 Thread artnaseef
A higher load on CPU versus other brokers under the exact same load?

Are there any reports with details, such as the topology of brokers and
ActiveMQ clients?

It would be great to have a baseline to start from, and some detail to
review.  For example, not being able to saturate a network connection with a
single client connection to ActiveMQ would not be a surprise.

Things I would be interested to know about these tests:
* Numbers of brokers and broker topology
* Numbers of ActiveMQ producers and consumers, and their topology wrt the
ActiveMQ broker topology
* Types and sizes of messages
* ActiveMQ broker configuration



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/CPU-core-thread-scaling-test-tp4693913p4693951.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-27 Thread artnaseef
I agree with the value of getting more folks involved with coding.

When questions and attempts to contribute are met with silence and
resistance, it is discouraging.  I personally had that experience and gave
up more than once.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693943.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-26 Thread artnaseef
I see how one could get that impression.

It's a shame it wasn't explicit in the original vote.  Then we wouldn't have
this confusion.  Poor communication is leading to conflict, division, and
discouragement.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693872.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-26 Thread artnaseef
That's great.  I hope I've made it clear that I want to see HornetQ continue
on as well.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693871.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [VOTE] Apache ActiveMQ 6.0.0 (RC3)

2015-03-26 Thread artnaseef
Do you seriously think that would be wise?

Now it sounds like your advocating that we *could* have two separate brokers
maintained, but just using the same exact name by skipping around major
version numbers.  I certainly will not back *that* plan.

Honestly, this response confuses me.  I thought your primary argument is
that ActiveMQ needs a refresh.  Arguing that there's a way to continue the
ActiveMQ line in this way is just ... baffling.

Why is it important to you for HornetQ to take the ActiveMQ-6 name?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-6-0-0-tp4692911p4693865.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-26 Thread artnaseef
Oh, and to your question - yes, it is reasonable to have 2 apache brokers. 
There are already many Apache projects sharing spaces.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693864.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-26 Thread artnaseef
That's great to hear that you have a large working HornetQ installation.

Why is renaming HornetQ to ActiveMQ-6  important to you?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693863.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-26 Thread artnaseef
> 5.x needs a new core.

I think this point is really at the heart of the entire disagreement here.

The initial grant vote did not mention that HornetQ was going to be taken as
a *replacement* for the entirety of ActiveMQ.  As several folks have
mentioned here, we had the impression the code was going to be made
available for merging into the ActiveMQ code base.

If the initial vote had been, "[VOTE] accept HornetQ as ActiveMQ 6 to
replace the existing code base", the results of the vote would have been
very different.  It may still have passed, but there would have been this
same discussion back then before heading part-way down this path, and there
would be no reason to discuss it now.

Chris - I think you mentioned there was a vote to bring HornetQ folks into
the AMQ PMC.  I don't believe that happened (someone please correct me if I
have it wrong).



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693856.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-25 Thread artnaseef
+1 Hadrian

"Reports of ActiveMQ's death have been grossly exaggerated." (borrowing from
Mark Twain)

There is definitely a sense that many of the members of this PMC are tired
of maintaining the existing code base.  That's understandable - they've been
the key folks for a long time, and I for one appreciate their effort.

Thank you.

With that said, I would love to see a fresh wave of innovation and influx of
talent to ActiveMQ.  Itself.

Gary - remember the idea of "feedback flow control"?  I still think that is
a better approach to PFC in spite of being told that ActiveMQ doesn't want
large changes of that nature.  And how about approaches to solving temporary
destination race conditions across a network of brokers?  I know it can be
solved and am working now toward that end.

I know very well that over many years, almost no new committers were added
to ActiveMQ.  Certainly, we need to do better.

Gary - I ask for information showing what problem needs to be solved and you
reply, "you can look around yourself," and give a reference to one benchmark
that appears to cost $1800.  That's not a helpful, nor a convincing,
argument.  I am getting a strong vibe from you, and I truly hope you find a
next step that satisfies you.

By the way, if we're talking benchmarks, here's a benchmark that shows
ActiveMQ outperforming HornetQ:
http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/
(note the graphs show time, so lower is better).

There is no convincing argument at hand that ActiveMQ is anything other than
a widely-used, popular and successful solution, and I for one will continue
to put in the effort I can to continue it forward.  I wish I were paid to
work on it, but my effort is actually 100% volunteer, making it harder to
put in the time.  But I will find time and I hope others will join me.

Honestly, if we look at the arguments for bringing HornetQ in as ActiveMQ6,
they all involve attacking ActiveMQ and hype around the strength of
HornetQ's technology.  So, then, why does HornetQ need the ActiveMQ name?

HornetQ folks - you are welcome to woo any and all ActiveMQ community
members.  Coming in and saying, "we need a presumption of taking the
activemq-6 mantle so we can tap into the ActiveMQ resources" is not
convincing.  Nor is the, "hey, come on guys - let's work together" argument. 
In fact, why do you need the activemq6 name at all?  The more I don't hear,
"yeah, we could go out on our own, but really thought this move was the best
because ...," the less I believe the hype.

Also under the "joining forces argument" -- should Microsoft Windows and Mac
OSX merge and join forces?  I'm sure there would be benefits.  But, perhaps
the entire industry is better because they do *not* join forces.  Sometimes
innovation comes best when two solutions are built separately toward the
same end.  There are entire markets based on that model.

HornetQ folks - your solution has some strong merits based on my brief
research, and I anticipate great things.  For example, the separation of the
core messaging primitives from JMS sounds promising, as does the statement
that the engine uses entirely non-blocking operations.

Keep up the good work - everyone.  Vigorous discussion is an important part
of open source.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693825.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: [DISCUSS} HornetQ & ActiveMQ's next generation

2015-03-25 Thread artnaseef
Growing the community around HornetQ is the same issue regardless of the
naming - it needs to happen, and just naming it ActiveMQ 6 doesn't really
change anything other than to create the presumption that HornetQ will
succeed as ActiveMQ 6.

Sharing a direction across the community is important, and making sure that
direction is clear is also important.  In that light, I am very glad to be
having this discussion.

The statement "Neglecting to commit to a direction will leave ActiveMQ
rudderless" is valid, but does not decide that direction.  Nor does it mean
that a complete restart of ActiveMQ is the right direction.

So, let's put this back into perspective.

We have the HornetQ donation to ActiveMQ.  To what benefit for the ActiveMQ
community?  Age of the solution is not a compelling argument (consider that
Java is even older than ActiveMQ).

ActiveMQ continues to be very widely used and supported.  It serves
mission-critical functions in large companies across multiple industries,
and even supports critical government infrastructure in many places.

Only time will tell if HornetQ is up to the task on all fronts: strength of
technology; community to maintain, support, and advocate the technology;
ease of installation, use, and monitoring; etc.  Therefore, a presumption
that it will replace an existing, proven solution is premature.

Really, the merits here are hard to argue because I'm not seeing any valid
merits described.

I keep wondering, "what problem are we solving?"  Please help me to
understand this and how the HornetQ donation solves the problem.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-generation-tp4693781p4693805.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


  1   2   3   >