Re: C#+EmbeddedBroker

[Jim Gomes]

You can use IKVM (https://www.ikvm.net/) to create a C# assembly from the
ActiveMQ jar file.  Here's the command-line you can use to compile it:

ikvmc.exe activemq-all-*.jar -out:ActiveMQ.Broker.dll -platform:anycpu
-target:library

Once you have created that assembly, create a new project that references
the ActiveMQ.Broker.dll and the IKVM.OpenJDK.Core assemblies.  Call this
new project *ActiveMQ.Embedded*. It will output the assembly
ActiveMQ.Embedded.dll.  This project will have the following source file
(name the source file AMQBroker.cs):

using System;
using System.IO;
using System.Reflection;

namespace ActiveMQ.Embedded
{
public class AMQBroker : IDisposable
{
private readonly org.apache.activemq.broker.BrokerService amqBroker;
private readonly string tmpDataDir = null;

public AMQBroker()
: this(0, false, null)
{
}

public AMQBroker(ushort port)
: this(port, false, null)
{
}

public AMQBroker(ushort port, bool persistent)
: this(port, persistent, null)
{
}

public AMQBroker(ushort port, bool persistent, string dataDirectory)
{
amqBroker = new org.apache.activemq.broker.BrokerService();
amqBroker.setPersistent(persistent);
amqBroker.setUseJmx(false);
amqBroker.setEnableStatistics(false);
amqBroker.setStartAsync(false);

if(string.IsNullOrWhiteSpace(dataDirectory))
{
tmpDataDir = GetTemporaryDirectory();
amqBroker.setDataDirectory(tmpDataDir);
}
else
{
amqBroker.setDataDirectory(dataDirectory);
}

string localserveraddress = IsLinux ? "0.0.0.0" : "localhost";

org.apache.activemq.broker.TransportConnector connector =
amqBroker.addConnector($"tcp://{localserveraddress}:{port}");
ConnectionUri = new Uri(connector.getUri().ToString());
amqBroker.start();
}

public static bool IsLinux
{
get
{
int p = (int) Environment.OSVersion.Platform;
return (p == 4) || (p == 6) || (p == 128);
}
}

public Uri ConnectionUri { get; private set; }
public int ConnectionPort { get { return ConnectionUri.Port; } }
public Uri FailoverUri { get { return new
Uri($"activemq:failover:{ConnectionUri.ToString()}"); } }

private static string GetTemporaryDirectory()
{
string tempFolder = Path.GetTempFileName();
File.Delete(tempFolder);
Directory.CreateDirectory(tempFolder);
return tempFolder;
}

public void Dispose()
{
try
{
amqBroker.stop();
if(null != tmpDataDir)
{
Directory.Delete(tmpDataDir, true);
}
}
catch(Exception e)
{
}
}
}
}

Once you have created the ActiveMQ.Embedded.dll, you can then reference it
in your project and instantiate an embedded broker as follows:

using ActiveMQ.Embedded;

AMQBroker broker = new AMQBroker(56500);  // Set whatever port number you
want to use, or leave it to the default.

It's that simple. Just remember to Dispose() it when you are done. Having
an embedded broker is fantastic for unit testing, or for many other uses.

Good luck!

-Jim


On Tue, Feb 28, 2017 at 12:00 PM xinchangan <610325...@qq.com> wrote:

I need to build an ActiveMQ client with C#.In order to improve the
efficiency
of transmit I have to use the embedded-broker within my C# Client. Finding
through all the documents and examples provided by ActiveMQ, I could not get
any clue or answers.

How can I do it? Anyone has a suggestion?

Thanks!



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

Re: [VOTE] Apache ActiveMQ 5.14.4

[Jim Gomes]

+1

On Mon, Feb 27, 2017, 2:58 PM Christian Schneider 
wrote:

> +1 (non binding)
>
> Christian
>
> On 27.02.2017 15:03, Christopher Shannon wrote:
> > Hi Everyone,
> >
> > I have created the ActiveMQ 5.14.4 release and it's ready for a vote.
> >
> > The list of resolved issues is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12338909
> >
> > You can get binary distributions here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1118/org/apache/activemq/apache-activemq/5.14.4/
> >
> > Source archives are here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1118/org/apache/activemq/activemq-parent/5.14.4/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1118/
> >
> > Source tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=308eab0bb63136871e2c1c8f179a6cd2e458de5f
> >
> > Please vote to approve this release.  The vote will remain open for 72
> > hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.14.4
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
> >
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: [VOTE] Migrate the NMS Projects from SVN to Git

[Jim Gomes]

+0

It does not work for me. I've detailed my technical issues without
satisfactory solutions. However, I will not stand against the community
zeitgeist. It would be my preference to leave it as is.

On Wed, Feb 22, 2017, 8:52 PM Howard Gao  wrote:

> +1
>
> On Thu, Feb 23, 2017 at 7:25 AM, Timothy Bish  wrote:
>
> >
> > Since the discussion around moving the NMS code to Git has died down now
> > I've decided to just call a vote on the matter.
> >
> > The vote covers moving the following NMS projects SVN trees to their own
> > respective Git repositories and marking the old SVN locations as
> > read-only.  As part of the move to Git we'd request that each repository
> be
> > mirrored on Github so that folks that aren't committers can contribute to
> > the NMS clients via pull requests which would make life simpler for both
> > the contributor and the person merging the contributions.  We'd still
> link
> > the repository up to JIRA using the normal svngit2jira mechanism so all
> > repository work with the JIRA issue specified in it gets logged to the
> > associated JIRA issue.
> >
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
> > ache.NMS.ActiveMQ
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
> > ache.NMS.ActiveMQ.OpenWire.Generator
> >
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.AMQP
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.EMS
> >
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.MSMQ
> >
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.Stomp
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.XMS
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ZMQ
> >
> > If the vote passes I can handle to process of requesting all these
> changes
> > and ensure that the migration gets done as we requested.
> >
> > [ ] +1 Migrate the specified NMS projects above to Git repositories.
> > [ ] -1 (provide specific comments)
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> >
>

Re: [DISCUSS] Move Apache.NMS project to Git

[Jim Gomes]

On Tue, Feb 21, 2017 at 5:07 PM Clebert Suconic 
wrote:

> > Yes, I think a Vote is a good idea.  Makes it very clear, and follows
> > established Apache process, and gives a definite cut-off point.
> >
> Ok, but so far you are the only one to be convinced.
>

It wouldn't matter if no one needed to be convinced. It has no bearing on
the process.


> > Does that duplicate the entire Git repository? It kind of looks like it
> > does.
>
> Git is very light. it is not really an issue. We do it all the time on
> many different projects.
>

So, that's a "Yes, it does duplicate the entire repository (which can be
quite sizeable) in order to have multiple branches checked out
simultaneously."  Got it. Clearly a disadvantage.


> We would likely have these sub-directories as part of the git repo:
>
> Apache.NMS/
> Apache.NMS.AMQP/
> Apache.NMS.ActiveMQ/
> Apache.NMS.ActiveMQ.Openwire.Generator/
> Apache.NMS.EMS/
> Apache.NMS.MQTT/
> Apache.NMS.MSMQ/
> Apache.NMS.Pooled/
> Apache.NMS.Stomp/
> Apache.NMS.WCF/
> Apache.NMS.XMS/
> Apache.NMS.ZMQ/
>
>
So, for example, I would be able to have the following structure on my
local hard disk?

Apache.NMS/
/trunk
/tags
/1.7.0
/1.7.1
Apache.NMS.ActiveMQ/
/trunk
/tags
/1.7.0
/1.7.1
/1.7.2

And be able to compile the trunk versions of Apache.NMS and
Apache.NMS.ActiveMQ alongside the 1.7.0 versions of Apache.NMS and 1.7.0
versions of Apache.NMS.ActiveMQ at the same time?  Also, in this situation,
the Apache.NMS.ActiveMQ 1.7.2 version imports the Apache.NMS 1.7.1 output
DLLs.

>> > repository auto-generated sequential number.  Does anyone have any
> >> > suggestions on how to accomplish a similar reproducible build using
> Git?
> >> >
> >>
> >> you don't need really need that, you can use the Hash as the version
> >> ID if you require the git.
> >>
> >> You just increment the version as everybody else does.
> >>
> >
> > I thought everyone else used the Subversion number the way I do. I
> manually
> > increment the ,  and  numbers, and generate the
> 
> > number automatically. It is not possible to embed a hash number into a
> > build number, so I'm not clear on what you are suggesting.
> >
>
> You can just tag when you make a release. It's not really an issue.
>

I guess I didn't explain the requirements clearly. Tagging is not the
solution.  This is about automatically injecting the revision of the source
code that was used to build the product.  For example, let's say the
Subversion repository is at revision number 18634.  I am building
Apache.NMS version 1.7.0.  When I run my build, it will automatically
produce an assembly with the embedded version number 1.7.0.18634.  That
last number can't be a hash.  If I were to commit any change at all (not
necessarily creating a tag or branch, just a change), then the repository
would increment to 18635.  If I build again, it would produce Apache.NMS
1.7.0.18635. Automatically.  This way there is no confusion as to what
exact revisions went into creating that assembly, and I have a reproducible
build.

I understand that revision numbers in Git are SHA1 checksums. There is no
concept of a repository revision number as there is in Subversion. Many
suggestions are to use tagging, but tagging every single check-in to
achieve the same ability does not seem like the proper use of the tool.

Re: [DISCUSS] Move Apache.NMS project to Git

[Jim Gomes]

On Tue, Feb 21, 2017 at 4:31 PM Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> On Tue, Feb 21, 2017 at 7:09 PM, Jim Gomes <jgo...@apache.org> wrote:
> > As well as call a vote. A Discussion is only a discussion. It takes a
> Vote
> > to enable action.
>
> I really didn't think it would be needed.. you are the only one
> against it so far. I think we are have votes on this thread.. do you
> need it to be formal?
>

Yes, I think a Vote is a good idea.  Makes it very clear, and follows
established Apache process, and gives a definite cut-off point.


>
> > 1. I am unable to have multiple branches checked out on the machine at
> the
> > same time, which stops me from building all versions.  This is especially
> 
>
> cp -r original-directory new-directory
> cd .. new-directory
> git checokut your-other-branch
>

Does that duplicate the entire Git repository? It kind of looks like it
does.


> > repository auto-generated sequential number.  Does anyone have any
> > suggestions on how to accomplish a similar reproducible build using Git?
> >
>
> you don't need really need that, you can use the Hash as the version
> ID if you require the git.
>
> You just increment the version as everybody else does.
>

I thought everyone else used the Subversion number the way I do. I manually
increment the ,  and  numbers, and generate the 
number automatically. It is not possible to embed a hash number into a
build number, so I'm not clear on what you are suggesting.


> It's just a matter of you getting used with git.
>

I can get used to Git. I've used many version control systems (RCS, VCS,
PVCS, SourceSafe, Perforce, Subversion, Mercurial, etc.). So, I look to
those more experienced to help migrate to it. I see that it has advantages,
but it also has disadvantages.

Re: [DISCUSS] Move Apache.NMS project to Git

[Jim Gomes]

As well as call a vote. A Discussion is only a discussion. It takes a Vote
to enable action.

And as far as my technical concerns go, perhaps someone more experienced
with Git can help me solve them.  They are:

1. I am unable to have multiple branches checked out on the machine at the
same time, which stops me from building all versions.  This is especially
apparent when I want to build Apache.NMS trunk, and then build its
dependencies Apache.NMS.ActiveMQ, Apache.NMS.EMS, Apache.NMS.STOMP, etc.
How can I have all of these branches checked out at the same time if they
are all in the same Git repository? Am I going to be forced to have
separate Git repositories for each of those projects? Am I going to have to
script my builds to switch branches in the middle of a hierarchical build?
If so, that is extremely cumbersome, and not a solution I would want to go
with.

2. My entire build process is built around the automatic incrementing
revision of Subversion (i.e., when a file is checked in, the repository
revision number automatically increments sequentially). I use that
automatic revision as part of the build numbers when I compile, which gives
me completely reproducible builds.  For example, I compile a project as
version ... where  is the Subversion
repository auto-generated sequential number.  Does anyone have any
suggestions on how to accomplish a similar reproducible build using Git?

So, these are my technical issues with switching to Git.  It's not a matter
of personal preference. So, if I can come up with solutions to these two
items, I would have no reservations to switching to Git.  Any help is
appreciated.


On Tue, Feb 21, 2017 at 2:33 PM Timothy Bish  wrote:

> On 02/21/2017 05:23 PM, Clebert Suconic wrote:
> > I suggest you start with adding the current version there, you make
> > progress... later you cherry-pick the commits or rebase against the
> > new repo.
> >
> > This makes a lot more sense to convert it to git then.
> >
> > If I don't get any -1 in 2 days, I will assume lazy consensus and open
> > the JIRA on infra.
>
> Do you have a plan on what you are going to request?  There are actually
> several SVN repos under the NMS project and if we are migrating the AMQP
> one then I'd suggest that all be moved so you should ensure you capture
> them all.  There's also some logistics involved in the move such as
> whether the current repos be left intact in a read-only state or removed
> after the migration.  You'll also need to ensure infra migrates the
> configuration to svngit2jira for each to the new repos and  also get the
> github mirroring setup for each.
>
> There are some other tasks after that you'd need to do around ensuring
> that the repos get shifted from trunk as the root to a master branch.
>
> So before you do anything I suggest you work up a plan.
>
> >
> > On Tue, Feb 21, 2017 at 5:08 PM, Duane Pauls 
> wrote:
> >> For the NMS AMQP rework, we've created a github repo as a starting
> point:
> >> https://github.com/SolaceLabs/nms-amqp
> >>
> >> It's rather empty at the moment, but the work has been kicked off in a
> fork:
> >> https://github.com/cjwmorgan-sol-sys/nms-amqp/
> >>
> >> There isn't much there yet, but migrating to a git repository should
> make
> >> it a bit easier to migrate changes over to the Apache repo.
> >>
> >> So for me it is a (non-binding) +1.
> >>
> >> On Tue, Feb 21, 2017 at 4:51 PM, nigro_franz 
> wrote:
> >>
> >>> For me is a +1!
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context: http://activemq.2283324.n4.
> >>>
> nabble.com/DISCUSS-Move-Apache-NMS-project-to-Git-tp4722085p4722285.html
> >>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> >>>
> >
> >
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [VOTE] Release ActiveMQ-CPP v3.9.4

[Jim Gomes]

+1

On Mon, Feb 20, 2017 at 9:40 AM Claus Ibsen  wrote:

> +1
>
> On Mon, Feb 20, 2017 at 6:23 PM, Timothy Bish  wrote:
> > New vote open for ActiveMQ-CPP v3.9.4
> >
> > This is a new patch release of the ActiveMQ-CPP client with a fixes for
> > issues found in the Failover transport along with a few other minor
> fixes.
> >
> > The source bundles for this release can be found here:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq-cpp/3.9.4/
> > 
> >
> > The Wiki page for the release is here:
> > http://activemq.apache.org/cms/activemq-cpp-394-release.html
> > 
> >
> > The list of issues fixed in this release is available here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311207=12335498
> >
> > Please cast your votes:
> >
> > [ ] +1 Release the source as Apache ActiveMQ-CPP 3.9.4
> > [ ] -1 (provide specific comments)
> >
> > Here is my binding +1
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog:http://timbish.blogspot.com/
> >
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: [DISCUSS] Rework NMS.AMQP

[Jim Gomes]

I would prefer if this can also be built on Linux, and not just be a
Windows only solution. Having Visual Studio do a NuGet dependency seems
like it will require Visual Studio and only work on Windows.

Does NuGet work without Visual Studio?


On Sat, Feb 18, 2017, 6:10 AM Duane Pauls  wrote:

> On Feb 17, 2017 10:26 PM, "John D. Ament"  wrote:
>
>
> I'm just wondering, AMQPNETLITE is published on nuget.  Does NMS need to
> import the source code from it, or can you rely on the nuget dependency?
>
>
> Right, Chris could confirm, but I think he is going to be creating an MS
> Visual Studio project with the NuGet dependency.  So there's no need to
> distribute it directly, but the end user would be required to install it in
> order to build or run.
>
> Cheers,
> Duane
>

Re: [DISCUSS] Move Apache.NMS project to Git

[Jim Gomes]

So, what stops people from using Git as a front-end to Subversion and
working with the Git toolset?

Here is a great write-up showing a developer doing just that:
http://blog.jthoenes.net/2011/08/01/using-git-as-frontend-for-svn/

This seems like the best of both worlds.  Those that want Git, can do so
without penalty (other than the huge local database). The same for those
who use Subversion.


On Wed, Feb 15, 2017 at 4:15 PM Timothy Bish <tabish...@gmail.com> wrote:

> On 02/15/2017 06:41 PM, Jim Gomes wrote:
> > Breaking this out into its own discussion thread...
> >
> > It has been proposed that Apache.NMS Subversion repository be moved to a
> > Git repository.  While the dominate reason seems to be "that's what
> > everyone else is doing", I'm sure there are more technical reasons for
> the
> > proposal. I will let others offer up those reasons for the move.
> >
> > As for my position, Subversion has been sufficient, but I'm not entirely
> > opposed to the move as long as certain technical requirements can be met.
> > These technical requirements can be entirely met if the Git repository is
> > automatically mirrored to GitHub, which allows for Subversion clients to
> > access a Git repository.  In that case, the port to a Git repository
> > back-end would be completely transparent.
> >
> > So, let's discuss the technical merits on moving the repository to Git.
> >
> We could move to CVS, I hear some people used to think that was
> sufficient  ;)
>
> Depends on who you ask about SVN vs Git.  They both work, but I think
> many of us have moved on to using Git for most everything we work on so
> having to go back and muddle with SVN at this point seems an extra hurdle.
>
> I would say that having the ability to easily link a git based project
> up to the Github mirror to grab PRs, apply them, push them to my github
> mirror while testing and tweaking and them eventually merging and
> pushing to the Activemq repo is certainly a lot simpler than muddling
> with patches and SVN.
>
> It is a simple thing to have Infra mirror the NMS git repos on Github,
> we do that already with ActiveMQ, ActiveMQ-CPP and Artemis among others.
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

[DISCUSS] Move Apache.NMS project to Git

[Jim Gomes]

Breaking this out into its own discussion thread...

It has been proposed that Apache.NMS Subversion repository be moved to a
Git repository.  While the dominate reason seems to be "that's what
everyone else is doing", I'm sure there are more technical reasons for the
proposal. I will let others offer up those reasons for the move.

As for my position, Subversion has been sufficient, but I'm not entirely
opposed to the move as long as certain technical requirements can be met.
These technical requirements can be entirely met if the Git repository is
automatically mirrored to GitHub, which allows for Subversion clients to
access a Git repository.  In that case, the port to a Git repository
back-end would be completely transparent.

So, let's discuss the technical merits on moving the repository to Git.

Re: [DISCUSS] Rework NMS.AMQP

[Jim Gomes]

Yes, I would object. It's not a simple thing as there are many downstream
dependencies on the Subversion repository. Although, anyone is free to use
Git as their own front-end to a Subversion repository if they prefer
working with Git toolset.

Normally, a CLA (Contributor License Agreement) is determined at the time
of the contribution.  It's usually only required for very large
contributions of original code. Since this may be an amalgamation of
third-party projects, it's unclear yet as to whether a CLA would be
required in this case.

On Wed, Feb 15, 2017 at 3:20 PM Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> would anyone object if I open a request on Infra to convert it to git?
>
>
> Also: since Duane will start as a contributor, and it is expected to
> send a considerable amount of contributions, should him sign up the
> contributors agreement?
>
> On Wed, Feb 15, 2017 at 12:48 PM, Clebert Suconic
> <clebert.suco...@gmail.com> wrote:
> > This is actually the list you should follow up with the question:
> >
> > http://www.apache.org/foundation/mailinglists.html#foundation-legal
> >
> >
> > but I think just the JIRA should be enough.
> >
> >
> > Other guys here will have more experience on that.. they may provide
> > more information, but that's what I would do.. open the LEGAL JIRA.
> >
> > On Wed, Feb 15, 2017 at 12:44 PM, Clebert Suconic
> > <clebert.suco...@gmail.com> wrote:
> >> how I would do regarding legal:
> >>
> >>
> >> i would create a JIRA on https://issues.apache.org/jira/browse/LEGAL
> >>
> >>
> >> And I would follow up with a [DISCUSS] thread on the dev list,
> >> referencing the JIRA.
> >>
> >>
> >> Pointing out the dependency you will include, the license and the
> >> source of the project.
> >>
> >>
> >> I don't foresee any issues.. but it would be nice to have you on board
> >> with that discussion.
> >>
> >>
> >>
> >>
> >>
> >> I really think we should convert the NMS as a github project. I have
> >> seen more interest on projects around github these days. (TBH I don't
> >> even remember how to use SVN, git by itself is another + on building
> >> community).
> >>
> >> On Wed, Feb 15, 2017 at 10:05 AM, Duane Pauls <duane.pa...@gmail.com>
> wrote:
> >>> Thanks for the feedback.
> >>>
> >>> On Tue, Feb 14, 2017 at 5:45 PM, Clebert Suconic <
> clebert.suco...@gmail.com>
> >>> wrote:
> >>>
> >>>> On Tue, Feb 14, 2017 at 5:03 PM Jim Gomes <jgo...@apache.org> wrote:
> >>>> > As you point out, the licensing seems to be compatible, but maybe a
> quick
> >>>> > review from Apache legal might be a good idea since the intent is to
> >>>> > re-integrate it into the NMS codebase as an official project.
> >>>>
> >>>
> >>> Would you be able to explain how I'd do this (or refer me to some
> >>> instructions)?
> >>>
> >>>
> >>>
> >>>> >
> >>>> > The NMS code is in Subversion, and not in Git.  Here is the
> repository
> >>>> URL:
> >>>> >
> >>>> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/
> >>>> Apache.NMS.AMQP/trunk
> >>>> > .
> >>>> > It does not need to be ported to Git in order to create a new AMQP
> >>>> provider
> >>>> > implementation.
> >>>> >
> >>>>
> >>>>
> >>>> It would make it easier to contribute thought. PRs is a perfect way to
> >>>> start with contributions.
> >>>
> >>>
> >>> From my point of view we wouldn't strictly require a conversion to git.
> >>> But I agree PR's would simplify reviews and contributions.
> >>>
> >>>
> >>>
> >>>> > > you could also include ActiveMQ Artemis to the list of brokers.
> >>>>
> >>>
> >>> I agree it makes sense to add Artemis to the list of brokers.
> >>>
> >>>
> >>>
> >>>> > > Do you have an idea on how much effort it would take...  do you
> have
> >>>> > > any ideas for the initial implementation already?
> >>>>
> >>>
> >>> One of my colleagues, Chris Morgan has spent more time than I have at
> this
> >>> stage scoping the effort.  We think this will likely take a few months.
> >>>
> >>>
> >>> Cheers,
> >>> Duane
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic
>

Re: [DISCUSS] Rework NMS.AMQP

[Jim Gomes]

Hi Duane,

Thank you very much for this proposal.  I think it sounds great.  The
current NMS.AMQP is just a wrapper around another library.  If we could
have a full native implementation of the NMS API using AMQP, that would be
much better.

As you point out, the licensing seems to be compatible, but maybe a quick
review from Apache legal might be a good idea since the intent is to
re-integrate it into the NMS codebase as an official project.

The NMS code is in Subversion, and not in Git.  Here is the repository URL:
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.AMQP/trunk.
It does not need to be ported to Git in order to create a new AMQP provider
implementation.

Please let me know how I can help with this effort.

Best,
Jim


On Tue, Feb 14, 2017 at 12:53 PM Clebert Suconic 
wrote:

> wow.. IMHO it sounds an awesome idea...
>
>
> you could also include ActiveMQ Artemis to the list of brokers.
>
>
> I have been doing some work around AMQP on Artemis, and I also wrote a
> blog on how to use the AMQP lite:
> https://blogs.apache.org/activemq/entry/using-net-libraries-with-activemq
>
>
> Using the NMS seems like a great Idea, as it would represent an
> independent layer, like JMS is now, and it could make migration from
> OpenWire .NET clients into AMQP an easy transition?
>
>
> Do you have an idea on how much effort it would take...  do you have
> any ideas for the initial implementation already?
>
>
>
> I"m not sure where is the current repo for NMS. Maybe still in SVN? I
> couldn't find a git repo for it yet. If that's the case the first step
> would be to translate it into a git repo. We could start with pull
> requests.
>
> On Tue, Feb 14, 2017 at 2:32 PM, Duane Pauls 
> wrote:
> > Hello,
> >
> > I'm relatively new to the ActiveMQ community, but I've been watching this
> > list for the last little while and would like to propose some rework to
> the
> > NMS.AMQP API.
> >
> > I'm interested in any feedback you folks may have.  Thanks in advance!
> >
> >
> >
> > NMS.AMQP REWORK PROPOSAL
> >
> >
> > Abstract
> >
> > A pure .NET implementation of NMS[1] using the AMQP .NET Lite API[2].
> >
> >
> > Proposal
> >
> > This proposal is to rework the ActiveMQ NMS.AMQP codebase in order to
> > achieve:
> > 1. A pure .NET implementation of the NMS API using the AMQP 1.0[3]
> > wireline protocol as a transport. To do this, the AMQP .NET Lite API
> > will be used.
> > 2. Interoperability with other APIs following the AMQP JMS Mapping
> > Specification[4], namely Qpid JMS[5].
> > 3. Interoperability via AMQP 1.0 brokers such as ActiveMQ[6], the Qpid
> > C++ broker[7], and the Qpid broker for Java[8].
> >
> > While we would be open to alternate approaches, we propose starting work
> > on a development branch within the ActiveMQ NMS.AMQP repository[9], then
> > replace the contents of the trunk with the branch when the branch has
> > reached an appropriate level of maturity.
> >
> > There are two major components changing:
> > 1. The underlying transport API providing AMQP capabilities.
> > 2. The mapping between the NMS API and the underlying AMQP API.
> >
> > Therefore, there is little of the existing implementation that could be
> > reused. Hence the proposal is replace the implementation rather than
> > refactor it.
> >
> >
> > Background
> >
> > AMQP 1.0[3] is a standard wireline protocol. There are already open
> > source APIs that expose native AMQP 1.0 concepts directly:
> > 1. Apache Qpid Proton[10], which is available for a number of different
> > languages.
> > 2. AMQP .Net Lite[2], which is a pure .NET API implementation. AMQP .Net
> > Lite is not an Apache project, but it is licensed under the Apache 2.0
> > license.
> >
> > There are also open source APIs that implement other messaging APIs, and
> > map the APIs concepts to the AMQP 1.0 protocol. Examples of such APIs
> > are:
> > 1. Apache Qpid JMS[5], a JMS implementation that follows the AMQP JMS
> > Mapping Specification[4].
> > 2. The existing Apache ActiveMQ NMS.AMQP[9], an NMS implementation using
> > .NET-wrapped native code, and using a different API to protocol mapping
> > than Qpid JMS.
> >
> >
> > Rationale
> >
> > AMQP 1.0[3] is an attractive technology choice for deploying middleware
> > solutions. As a standardized protocol, it offers operational flexibility
> > for middleware solutions. For example, if it is desired change the AMQP
> > 1.0 provider, this is much more readily achieved with minimal impact to
> > applications compared to changing a provider when applications use a
> > vendor-specific API and/or protocol.
> >
> > Many software architects and developers are familiar with topic and
> > queue based messaging. The prevalence of Message Oriented Middleware
> > offerings such as IBM MQ, Amazon Simple Queue Service, and JMS
> > demonstrate this. In addition, .NET is a very popular software
> > framework. However, AMQP 1.0 is a relative newcomer to the 

Re: [VOTE] Apache Artemis 1.5.3 (RC2)

[Jim Gomes]

+1

On Tue, Feb 14, 2017, 6:39 AM Timothy Bish  wrote:

> On 02/13/2017 02:59 AM, nigro_franz wrote:
> > +1
> >
> >
> >
> > --
> > View this message in context:
> http://activemq.2283324.n4.nabble.com/VOTE-Apache-Artemis-1-5-3-RC2-tp4721880p4721906.html
> > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> >
> +1
>
> * Built from source and ran some tests
> * Verified license and notice files
> * validated signatures and checksums
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [VOTE] Apache ActiveMQ Artemis 1.5.2 (RC2)

[Jim Gomes]

+1

On Wed, Jan 18, 2017 at 5:49 PM Clebert Suconic 
wrote:

> I have just cut Artemis 1.5.2 (RC2) from the 1.x branch, as a maintenance
> release for these following issues:
>
> Bugs
>
> [ARTEMIS-882] - Some objects don't support lists on the connection
> factory definition
> [ARTEMIS-886] - Tiny error in documentation
> [ARTEMIS-890] - Dropped Messages, Paging and Block are ignored when
> broker is non persistent
> [ARTEMIS-892] - Error decoding AMQP frame sent by Artemis
> [ARTEMIS-913] - Slow consumer detection not working when paging
> [ARTEMIS-914] - Max saved replicated journal size on Live node should not
> be -1
> [ARTEMIS-921] - Consumers killed as slow even if overall consuming
> rate is above threshold
> [ARTEMIS-926] - CME when Artemis server start
> [ARTEMIS-927] - ActiveMQ logs cluster password in plain text
>
> Improvements
>
> [ARTEMIS-560] - Add support for Paging using JDBC Store
> [ARTEMIS-920] - Log SQL Exceptions and Warnings
> [ARTEMIS-928] - Remoting Layer will reuse ByteBuffer Pools on messages
>
> Tasks
>
> [ARTEMIS-891] - upgrade proton to 0.16
>
>
>
>
> For a complete list with links:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12338833
>
>
>
>
> Binary and source distributions are here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1115/org/apache/activemq/apache-artemis/1.5.2/
>
> Maven repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1115
>
> Just for reference, in case you want to use the maven repo as a test
> and validate examples, there is a useful doc here:
>
> http://activemq.apache.org/artemis/docs/1.5.1/hacking-guide/validating-releases.html
>
> Source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.5.2
>
>
>
> Please vote to approve this release. The vote will remain open for 72
> hours.
>
> [ ] +1 Aprove the release as Apache Artemis 1.5.2
> [ ] -1 (provide specific comments)
> [ ] 0  (no opinion)
>
>
>
>
> This includes my +1 Binding Vote
> --
> Clebert Suconic
>

Re: [VOTE] Apache ActiveMQ Artemis 1.5.2

[Jim Gomes]

+1

On Mon, Jan 16, 2017, 12:06 PM Clebert Suconic 
wrote:

> I have just cut Artemis 1.5.2 from the 1.x branch, as a maintenance
> release for these following issues:
>
>
>
> [ARTEMIS-882] - Some objects don't support lists on the connection
> factory definition
> [ARTEMIS-886] - Tiny error in documentation
> [ARTEMIS-890] - Dropped Messages, Paging and Block are ignored when
> broker is non persistent
> [ARTEMIS-892] - Error decoding AMQP frame sent by Artemis
> [ARTEMIS-913] - Slow consumer detection not working when paging
> [ARTEMIS-914] - Max saved replicated journal size on Live node should not
> be -1
> [ARTEMIS-921] - Consumers killed as slow even if overall consuming
> rate is above threshold
>
> As well as upgrading Proton per:
>
> [ARTEMIS-891] - upgrade proton to 0.16
>
>
> For a complete list with links:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12338833
>
>
>
>
> Binary and source distributions are here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1114/org/apache/activemq/apache-artemis/1.5.2/
>
> Maven repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1114
>
> Just for reference, in case you want to use the maven repo as a test
> and validate examples, there is a useful doc here:
>
> http://activemq.apache.org/artemis/docs/1.5.1/hacking-guide/validating-releases.html
>
> Source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.5.2
>
>
>
> Please vote to approve this release. The vote will remain open for 72
> hours.
>
> [ ] +1 Aprove the release as Apache Artemis 1.5.2
> [ ] -1 (provide specific comments)
> [ ] 0  (no opinion)
>
>
> --
> Clebert Suconic
>

Re: [VOTE] Apache ActiveMQ 5.14.3

[Jim Gomes]

+1

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

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

Re: [VOTE] ActiveMQ 5.13.5

[Jim Gomes]

Changing vote to +1.


On Sat, Dec 17, 2016, 3:09 PM Jim Gomes <jgo...@apache.org> wrote:

> +0
>
> There are two bug fixes, and as I read the bug reports, they don't seem
> that major to me.  Seems like a lot of work for just a couple of fixes that
> aren't critical.  (Maybe I'm missing something about them?)  If this is
> part of an effort to provide regular releases, then I'd change my vote
> to +1.  Otherwise, it seems more traditional to group more fixes together
> into a release.
>
>
> On Fri, Dec 16, 2016 at 11:23 AM Daniel Kulp <dk...@apache.org> wrote:
>
> This is a vote to release Apache ActiveMQ 5.13.5, a new patch release that
> includes a couple high importance fixes.
>
> Release notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12337971
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1112/
>
> Binary Tarballs:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1112/org/apache/activemq/apache-activemq/5.13.5/
>
> Source Tarballs:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1112/org/apache/activemq/activemq-parent/5.13.5/
>
> Tag:
>
> https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=tag;h=3867d32f6c4e0afdce609c6659be215edcaa64dd
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache ActiveMQ 5.13.5
> [ ] -1 Don’t release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: Parallel calls from 1 consumer to provider

[Jim Gomes]

Hi Jakki,

I think you may be misunderstanding the nature of queues.  Perhaps a topic
might be what you are looking for?  A queue will deliver the message to
only one consumer, even if there are multiple consumers connected.  It will
use a round-robin delivery mechanism.  For two consumers, each consumer
will get every-other message.  If you want your multiple consumers to get
all of the messages, then a topic is what you want. All consumers will get
all messages.

Best,
Jim


On Fri, Dec 16, 2016 at 11:24 AM Jakki  wrote:

> I am developing a C#.Net windows service that uses Apache.NMS.ActiveMQ. In
> this design i have multiple consumers and 1 provider. each consumer has to
> access multiple messages from queue and process it parallely.
> ex: I have 100 messages in a queue. 2 consumers are polling the same queue.
> 1st consumer has to get 10messages  and another 10 messages for 2nd
> consumer
> and in each consumer i create multiple threads to handle the messages like
> call webservice for each message. but i am stuck with only 1 message for a
> consumer it is accessed sequentially but not parallely.
> Could you please provide a sample of code?
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Parallel-calls-from-1-consumer-to-provider-tp4720535.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: Moving message from one queue to another using Apache.NMS.ActiveMQ;

[Jim Gomes]

Hi Jakki,

Here's a little snippet that should get you started:

IConnectionFactory factory =
NMSConnectionFactory.CreateConnectionFactory("activemq:failover:tcp://activemqhost:61616");

using(IConnection connection = factory.CreateConnection())
using(ISession session =
connection.CreateSession(AcknowledgementMode.AutoAcknowledge))
{
IDestination srcQueue = session.GetDestination("queue://Source");
IDestination destQueue = session.GetDestination("queue://Destination");
IMessageConsumer consumer = session.CreateConsumer(srcQueue);
IMessageProducer producer = session.CreateProducer(destQueue);

connection.Start();
// Copy message from source queue to destination queue.
producer.Send(consumer.Receive());
}

Looking at the source code to the unit tests can be very informative, too.

Best,
Jim

On Fri, Dec 16, 2016 at 11:24 AM Jakki  wrote:

> I am new to ActiveMQ, I am trying create an application in C#.net.  Could
> you
> please help me in moving a message from 1 queue to another queue in Active
> MQ?
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Moving-message-from-one-queue-to-another-using-Apache-NMS-ActiveMQ-tp4720534.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [VOTE] ActiveMQ 5.13.5

[Jim Gomes]

+0

There are two bug fixes, and as I read the bug reports, they don't seem
that major to me.  Seems like a lot of work for just a couple of fixes that
aren't critical.  (Maybe I'm missing something about them?)  If this is
part of an effort to provide regular releases, then I'd change my vote
to +1.  Otherwise, it seems more traditional to group more fixes together
into a release.


On Fri, Dec 16, 2016 at 11:23 AM Daniel Kulp  wrote:

> This is a vote to release Apache ActiveMQ 5.13.5, a new patch release that
> includes a couple high importance fixes.
>
> Release notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12337971
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1112/
>
> Binary Tarballs:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1112/org/apache/activemq/apache-activemq/5.13.5/
>
> Source Tarballs:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1112/org/apache/activemq/activemq-parent/5.13.5/
>
> Tag:
>
> https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=tag;h=3867d32f6c4e0afdce609c6659be215edcaa64dd
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache ActiveMQ 5.13.5
> [ ] -1 Don’t release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] Apache ActiveMQ Artemis 1.5.1

[Jim Gomes]

+1

On Tue, Dec 6, 2016, 2:16 PM Timothy Bish  wrote:

> +1
>
> * Validated signatures and sums
> * Checked license and notice files
> * built from source and ran some of the tests
> * ran the binary broker and ran some of the examples against it.
>
> On 12/06/2016 01:38 PM, Clebert Suconic wrote:
> > I have cut a 1.5.1 release of Artemis and it's ready for Vote.
> >
> > The list for the complete changes (release notes) is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12338661
> >
> >
> > We have about 9 bug fixes on this release along with other
> > improvements, including a critical fix for systems constantly using
> > paging:
> >
> > [https://issues.apache.org/jira/browse/ARTEMIS-748] - AddressSize show
> > a negative number.
> >
> >
> >
> > There is also an improvement where a broker can check the network
> > health and decide the life cycle of the server based on the network
> > connection:
> >
> > [https://issues.apache.org/jira/browse/ARTEMIS-863] - The broker
> > should deal with Network Failures.
> >
> >
> >
> >
> >
> > Different from previous Artemis releases, this time I'm not staging
> > the website as it will be orthogonal to the release. (It can be
> > updated independently of the release process).
> >
> >
> >
> >
> >
> > Binary and source distributions are here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-/org/apache/activemq/apache-artemis/1.5.1/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-
> >
> > Just for reference, in case you want to use the maven repo as a test
> > and validate examples, there is a useful doc here:
> >
> http://activemq.apache.org/artemis/docs/1.5.0/hacking-guide/validating-releases.html
> >
> > Source tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.5.1
> >
> >
> >
> > Please vote to approve this release. The vote will remain open for 72
> hours.
> >
> > [ ] +1 Aprove the release as Apache Artemis 1.5.1
> > [ ] -1 (provide specific comments)
> > [ ] 0  (no opinion)
> >
> >
> >
> > Here's my +1 (Binding).
> > .
> >
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [VOTE] Apache ActiveMQ 5.14.2

[Jim Gomes]

+1

On Mon, Dec 5, 2016, 9:18 PM Jean-Baptiste Onofré  wrote:

> +1 (binding)
>
> Regards
> JB
>
> On 12/05/2016 03:49 PM, Christopher Shannon wrote:
> > Hi Everyone,
> >
> > I have created the ActiveMQ 5.14.2 release and it's ready for a vote.
> This
> > release has over 30 bug fixes and improvements.
> >
> > The list of resolved issues is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12338329
> >
> > You can get binary distributions here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1110/org/apache/activemq/apache-activemq/5.14.2/
> >
> > Source archives are here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1110/org/apache/activemq/activemq-parent/5.14.2/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1110/
> >
> > Source tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=2462711684cba96fc9bfc274c75f6725b617a95e
> >
> > Please vote to approve this release.  The vote will remain open for 72
> > hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.14.2
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [DISCUSS] LevelDB deprecation

[Jim Gomes]

No objections. I was never clear on what advantages LevelDB was supposed to
offer anyway.

On Wed, Nov 16, 2016, 3:45 AM Robbie Gemmell 
wrote:

> Seems like a good idea to me.
>
> On 15 November 2016 at 11:45, Christopher Shannon
>  wrote:
> > Hi Everyone,
> >
> > I just wanted to ask what people think about officially deprecating
> LevelDB
> > in our 5.x broker and update our documentation to say that it is no
> longer
> > recommended.  We can leave it in the code base for people who are still
> > using it but discourage its use.
> >
> > The main reason is that KahaDB continues to be the main focus where bugs
> > are fixed and not much attention is paid to LevelDB. There seems to be
> > several issues with corruption (especially with replication) so I don't
> > think it should be a recommended store unless the stability is sorted
> out.
> > Unfortunately nearly every Jira reported against LevelDB goes ignored.
> >
> > Now that Artemis exists and supports replication I think the focus should
> > be primarily on making Artemis the focus for users who need a replicated
> > store or to encourage the use of something like a shared file system
> > master/slave setup.
>

Re: [VOTE] Apache Artemis 1.5.0

[Jim Gomes]

+1

On Thu, Nov 3, 2016 at 2:29 PM Clebert Suconic 
wrote:

> Hello all,
>
> I would like to propose an Apache Artemis 1.5.0 release.
>
> 1.5.0 has these new features as highlights.
>
> [ARTEMIS-724] - Implement no-local consumer support in AMQP
> [ARTEMIS-737] - Add JUnit Rules
> [ARTEMIS-743] - Default the queue address to the queue name
> [ARTEMIS-753] - Persist pause status after restart of the broker.
> [ARTEMIS-756] - Add basic CDI integration
> [ARTEMIS-824] - Management operations for creating and destroying
> connector services
>
>
>
> And many other fixes as part of this release, the complete release
> notes can be found here:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12338118=Html=12315920=Create
>
> The binary distributions can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1109/org/apache/activemq/apache-artemis/1.5.0/
>
> The source archives can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1109/org/apache/activemq/apache-artemis/1.5.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1109/
>
> The source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.5.0
>
> The project website for that version has been staged to:
> http://home.apache.org/~clebertsuconic/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.4.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (binding) +1 vote
>

Re: [DISCUSS] Require Java 8 for 5.15 and Artemis

[Jim Gomes]

+1 for 8.

On Wed, Oct 19, 2016, 6:54 AM Timothy Bish  wrote:

> +1  time to move on to 8
>
> On 10/19/2016 08:44 AM, Christopher Shannon wrote:
> > With the release of Camel 2.18 I thought now was a good time to propose
> > this.  I think for the ActiveMQ 5.15 release we should bump the required
> > Java version to Java 8 as this will allow us to use Camel 2.18 so we can
> > finally fix our OSGi module and drop the deprecated Spring DM entirely.
> > This release probably won't go out until sometime next year and by that
> > time JDK 9 should be either released or close to being released and JDK 7
> > will have had its last public update nearly 2 years ago.
> >
> > Also, I figure we might as well do the same thing for Artemis.
> >
> > Any objections or reasons to stick with Java 7?
> >
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: HEADS-UP/DISCUSS Artemis 1.4.1

[Jim Gomes]

+1
No objections.

On Mon, Oct 17, 2016, 7:52 AM Clebert Suconic 
wrote:

> I want to make a release early next week. (as I have pointed a few weeks
> ago).
>
>
> I will release from master... there are a few new packages added
> around OSGI, but I was still considering calling 1.4.1, and reserve
> 1.5.0 for a few more major features that will change the broker
> itself.
>
>
> If no objections I will call it 1.4.1, but I wouldn't mind calling it
> 1.5.0 if anyone objects.
>

Re: [DISCUSS] Artemis missing advisories and producer tracking

[Jim Gomes]

+1 for supporting all the advisories that the current ActiveMQ 5.x supports.

As for when the advisory message is sent for a Producer, I'm not sure there
is a specific guarantee about that. If a Producer is 'created', but a
message is never sent, was it actually created? I'm not necessarily opposed
to the lazy notification strategy.


On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Also as a follow up, I noticed that the OpenWireProtocalManager already
> fires a couple advisories for new connections/destinations.  I can
> certainly create a PR to add more advisories but I guess really the
> question is whether or not we should support the advisories across any
> protocol or not.
>
> On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > In general it would be nice if all of the current advisories that are
> > supported in 5.x could eventually be supported in Artemis as well.   As I
> > was looking at Artemis's notifications to see what currently existed one
> > thing I noticed was that there is a lack of producer notifications.
> Having
> > an advisory sent when a producer is created is something that I know I
> use
> > all the time.
> >
> > I dug into this and it looks like the reason is because Artemis doesn't
> > actually track a producer until the first message is sent.  In fact
> there's
> > no notion of a producer on the core wire format at all (there's no packet
> > type for it).
> >
> > I realize that many protocols don't have the notion of a producer...In
> 5.x
> > this is handled by just creating ProducerInfo objects on first connection
> > when a protocol doesn't support it (ie Stomp, etc). However, the JMS API
> > does have a specific call to create a producer so I find it useful to get
> > an advisory message and to track when producers come online even if not
> > every protocol supports this.
> >
> > So I guess I wanted to see what people thought about adding a
> notification
> > for producers and also trying to fill in the gaps for the rest of the
> > advisory topics that are missing.
> >
>

Re: [DISCUSS] Removing the Web Console

[Jim Gomes]

Got it. I haven't used pull requests before, but that sounds great to me if
others will find it a better workflow. Will those who don't use git be able
to participate through the mail list interface? Some systems gave that kind
of ability.


On Fri, Oct 7, 2016, 3:29 PM Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> On Fri, Oct 7, 2016 at 5:40 PM, Jim Gomes <jgo...@apache.org> wrote:
> > I was under the impression that all Apache development discussions occur
> on
> > the email list.
>
> As Justin Bertram Said, all PR comments are sent to the dev-list.
>
> What I'm really proposing, it's to be practical... to have something
> concrete to talk about on top of the code.
>
>
>
>  Clebert Suconic <clebert.suco...@gmail.com>
> > wrote:
> >
> >> I think this is pretty straightforward:
> >>
> >> i - it should relay on JMX or jolokia.. A common thing between both
> >> Artemis and ActiveMQ
> >>
> >> ii - it should manage at least a single broker.. with some metrics...
> >>
> >>
> >> iii - anything beyond that will just be a collaboration over the code.
> >>
> >>
> >> The best way to discuss this IMO would be through a Pull Request..
> >> someone send an initial draft.. we can have some **technical**
> >> discussion over of PR, and commit it as version 1... then
> >> collaboratively this could be increased just as with anything else.
> >>
> >>
> >>
> >> I think we are clear from the previous discussions... and that's a
> >> request I am making here, probably the third time... lets CTRL-Alt-Del
> >> and start fresh... The issues we had are clear... and I see everybody
> >> with a single goal here.. to have an integrated console that looks
> >> like an Apache project, pretty and neat.
> >>
> >>
> >> Once someone put a first version, we can only improve it from there.
> >>
> >> On Fri, Oct 7, 2016 at 12:17 PM, Hadrian Zbarcea <hzbar...@gmail.com>
> >> wrote:
> >> > I would suggest discussing the goals for such a console first. Is it
> >> > intended to monitory just one broker instance or a whole network of
> >> brokers?
> >> > Should it manage just the brokers or other services? Should it rely on
> >> JMX
> >> > or something else?
> >> >
> >> > Then one can think about reusing and/or improving something that's
> >> available
> >> > or some other solution.
> >> >
> >> > The way this discuss goes, sounds to me like trying to push again for
> >> > something that was rejected in the past and I suspect will not go
> >> anywhere.
> >> >
> >> > My $0.02,
> >> > Hadrian
> >> >
> >> >
> >> > On 10/07/2016 06:41 AM, Martyn Taylor wrote:
> >> >>
> >> >> +1 on improving/adding a console.  Providing a console out of the box
> >> is a
> >> >> massive win for user experience imo and something that I feel Artemis
> >> >> would
> >> >> greatly benefit from.  Whether it's HawtIO or something else we
> should
> >> >> make
> >> >> every effort to standardise across both 5.x and Artemis.
> >> >>
> >> >> On Tue, Oct 4, 2016 at 5:11 PM, Clebert Suconic
> >> >> <clebert.suco...@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> On Tue, Oct 4, 2016 at 11:57 AM, John D. Ament <
> johndam...@apache.org>
> >> >>> wrote:
> >> >>>>
> >> >>>> @Hiram
> >> >>>>
> >> >>>> The website branding says otherwise (take a look at the top right
> >> >>>
> >> >>> corner).
> >> >>>
> >> >>>
> >> >>> That symbol on the top is just a link to the following:
> >> >>>
> >> >>> "Like hawtio? It’s part of a community of Red Hat projects. Learn
> more
> >> >>> about Red Hat and our open source communities:"
> >> >>>
> >> >>>
> >> >>>
> >> >>>  No other implications from what I see.
> >> >>>
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >>
>
>
>
> --
> Clebert Suconic
>

Re: [DISCUSS] Removing the Web Console

[Jim Gomes]

I was under the impression that all Apache development discussions occur on
the email list. This is for legal and policy reasons. Please correct me if
I'm wrong.

On Fri, Oct 7, 2016, 9:43 AM Clebert Suconic 
wrote:

> I think this is pretty straightforward:
>
> i - it should relay on JMX or jolokia.. A common thing between both
> Artemis and ActiveMQ
>
> ii - it should manage at least a single broker.. with some metrics...
>
>
> iii - anything beyond that will just be a collaboration over the code.
>
>
> The best way to discuss this IMO would be through a Pull Request..
> someone send an initial draft.. we can have some **technical**
> discussion over of PR, and commit it as version 1... then
> collaboratively this could be increased just as with anything else.
>
>
>
> I think we are clear from the previous discussions... and that's a
> request I am making here, probably the third time... lets CTRL-Alt-Del
> and start fresh... The issues we had are clear... and I see everybody
> with a single goal here.. to have an integrated console that looks
> like an Apache project, pretty and neat.
>
>
> Once someone put a first version, we can only improve it from there.
>
> On Fri, Oct 7, 2016 at 12:17 PM, Hadrian Zbarcea 
> wrote:
> > I would suggest discussing the goals for such a console first. Is it
> > intended to monitory just one broker instance or a whole network of
> brokers?
> > Should it manage just the brokers or other services? Should it rely on
> JMX
> > or something else?
> >
> > Then one can think about reusing and/or improving something that's
> available
> > or some other solution.
> >
> > The way this discuss goes, sounds to me like trying to push again for
> > something that was rejected in the past and I suspect will not go
> anywhere.
> >
> > My $0.02,
> > Hadrian
> >
> >
> > On 10/07/2016 06:41 AM, Martyn Taylor wrote:
> >>
> >> +1 on improving/adding a console.  Providing a console out of the box
> is a
> >> massive win for user experience imo and something that I feel Artemis
> >> would
> >> greatly benefit from.  Whether it's HawtIO or something else we should
> >> make
> >> every effort to standardise across both 5.x and Artemis.
> >>
> >> On Tue, Oct 4, 2016 at 5:11 PM, Clebert Suconic
> >> 
> >> wrote:
> >>
> >>> On Tue, Oct 4, 2016 at 11:57 AM, John D. Ament 
> >>> wrote:
> 
>  @Hiram
> 
>  The website branding says otherwise (take a look at the top right
> >>>
> >>> corner).
> >>>
> >>>
> >>> That symbol on the top is just a link to the following:
> >>>
> >>> "Like hawtio? It’s part of a community of Red Hat projects. Learn more
> >>> about Red Hat and our open source communities:"
> >>>
> >>>
> >>>
> >>>  No other implications from what I see.
> >>>
> >>
> >
>
>
>
> --
> Clebert Suconic
>

Re: [DISCUSS] Removing the Web Console

[Jim Gomes]

Thanks for getting the discussion going again.  You bring up some
interesting points.  As stale as the console may be, I still find it
incredibly useful, and would hope that it will remain until a replacement
option is available.  I have found moving to Apache Artemis to feel like
I'm moving backwards because there is no admin console for it.

For those that may view it as a security risk, it is a simple matter to
disable it.  If it were to be replaced, what would be some potential
replacements? Could the most vulnerable parts of it be removed while still
remaining useful?  I mostly use it for knowing what clients are connected,
how many messages have been sent to destinations, and things like that. I
can't see how those limited functions would be difficult to keep, nor how
they could be a security issue.

On Wed, Sep 28, 2016 at 8:18 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> First, I know this topic was brought up back in January 2014 and there were
> a lot of discussions about what to do about it  and ultimately nothing
> happened.  However, it has been nearly 3 years since the last time this
> subject was brought up and absolutely nothing has changed so I think it is
> time to bring it up again and see what people's current opinions are.
>
> The Web Console is extremely out of date and since the last discussions on
> the subject is still completely un-maintained.  It is buggy and has had
> many security vulnerabilities that keep popping up including several that
> have been reported over the past year.  In the past 3 years no one has
> shown any interest in contributing fixes to the console to maintain it.
> Essentially no work has gone into the console except for security fixes.
>
> Also, I know there was talk about moving it into a sub project however I
> don't think that really solves anything.  The code would just be moved to a
> new location and still be un-maintained and full of potential security
> vulnerabilities.
>
> So my preference would be just to EOL the console and remove it form future
> versions. However, if there are people who really still want to keep it
> then at the very least I think it should go into a sub project along with
> some sort of warning that says it is deprecated and to use at your own
> risk, etc.
>
> Thoughts?
>

Re: ActiveMQ NMS and the new .NET Core

[Jim Gomes]

It's likely that it does work on .NET Core. Unfortunately, I can't get .NET
Core to work on my machine, since I don't use the specific version of
Ubuntu Linux that is required. I run Debian Linux. Until Microsoft provides
a version of .NET Core that runs on multiple distros, the supported use
cases will be very low.

On Tue, Sep 20, 2016, 8:47 PM Brian Cole  wrote:

> I think it would be very nice to have the NMS libraries work with .Net
> Core.
> I sadly learned today that Mono does not support TLS 1.2. As TLS 1.2 is
> required for us, Mono is not an avenue that provides Linux support in our
> case.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-the-new-NET-Core-tp4714548p4716675.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [ANNOUNCE] Apache Artemis 1.4.0 Released

[Jim Gomes]

Yes, it'll take some amount of time. Not sure how much.  As I was browsing
manually, I noticed that there are synchronization errors. Most mirrors had
the 1.3.0 version and not the 1.4.0 version (as expected). However, the
mirror that I found 1.4.0 on did *not* have 1.3.0. That was surprising. Do
the mirrors ditch the older version when a newer one comes online? I'm not
sure how that works.


On Tue, Sep 13, 2016 at 2:07 PM Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> I tested before sending the ANNOUNCE, but I guess not all mirrors have it.
>
> I believe it usually takes some time before it syncs them all. I guess
> that's normal?
>
> On Tue, Sep 13, 2016 at 4:55 PM, Jim Gomes <jgo...@apache.org> wrote:
> > Disregard. There seems to be synchronizing issues between the mirrors.
> Some
> > mirrors have it, some don't. I had to manually browse the mirrors to find
> > one that did.
> >
> > On Tue, Sep 13, 2016 at 1:48 PM Jim Gomes <jgo...@apache.org> wrote:
> >
> >> The download links are still broken. How long before they will be
> active?
> >>
> >>
> >> On Tue, Sep 13, 2016 at 8:40 AM Clebert Suconic <
> clebert.suco...@gmail.com>
> >> wrote:
> >>
> >>> Apache ActiveMQ Artemis 1.4.0 has been released.
> >>>
> >>> There are a lot of improvements included in this release:
> >>>
> >>> - Possibility of using a max size for paging, and monitoring disk
> >>> sizes and improving flow control
> >>> - Interceptors support for MQTT
> >>> - Reload configuration support
> >>>
> >>> The artemis sub-project website has been updated:
> >>>
> >>> http://activemq.apache.org/artemis/
> >>>
> >>>
> >>>
> >>> For a complete report of changes:
> >>>
> >>>
> >>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12336052
> >>>
> >>>
> >>> And the documentation can be found here:
> >>>
> >>> https://activemq.apache.org/artemis/docs.html
> >>>
> >>>
> >>>
> >>> Regards
> >>>
> >>>
> >>>
> >>> Clebert Suconic
> >>>
> >>
>
>
>
> --
> Clebert Suconic
>

Re: [ANNOUNCE] Apache Artemis 1.4.0 Released

[Jim Gomes]

Disregard. There seems to be synchronizing issues between the mirrors. Some
mirrors have it, some don't. I had to manually browse the mirrors to find
one that did.

On Tue, Sep 13, 2016 at 1:48 PM Jim Gomes <jgo...@apache.org> wrote:

> The download links are still broken. How long before they will be active?
>
>
> On Tue, Sep 13, 2016 at 8:40 AM Clebert Suconic <clebert.suco...@gmail.com>
> wrote:
>
>> Apache ActiveMQ Artemis 1.4.0 has been released.
>>
>> There are a lot of improvements included in this release:
>>
>> - Possibility of using a max size for paging, and monitoring disk
>> sizes and improving flow control
>> - Interceptors support for MQTT
>> - Reload configuration support
>>
>> The artemis sub-project website has been updated:
>>
>> http://activemq.apache.org/artemis/
>>
>>
>>
>> For a complete report of changes:
>>
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12336052
>>
>>
>> And the documentation can be found here:
>>
>> https://activemq.apache.org/artemis/docs.html
>>
>>
>>
>> Regards
>>
>>
>>
>> Clebert Suconic
>>
>

Re: [ANNOUNCE] Apache Artemis 1.4.0 Released

[Jim Gomes]

The download links are still broken. How long before they will be active?


On Tue, Sep 13, 2016 at 8:40 AM Clebert Suconic 
wrote:

> Apache ActiveMQ Artemis 1.4.0 has been released.
>
> There are a lot of improvements included in this release:
>
> - Possibility of using a max size for paging, and monitoring disk
> sizes and improving flow control
> - Interceptors support for MQTT
> - Reload configuration support
>
> The artemis sub-project website has been updated:
>
> http://activemq.apache.org/artemis/
>
>
>
> For a complete report of changes:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12336052
>
>
> And the documentation can be found here:
>
> https://activemq.apache.org/artemis/docs.html
>
>
>
> Regards
>
>
>
> Clebert Suconic
>

Re: ActiveMQ file passing with C#.net

[Jim Gomes]

Hi Deepak,

You can probably just use a standard ITextMessage and set the message body
to be the CSV file. Add a header property with the filename. There should
be lots of samples that show how to create text messages and set
properties. The unit tests in the source code is one such resource.

Best,
Jim

On Wed, Aug 31, 2016, 6:21 AM dipoody  wrote:

> Hi Team,
>
> I am Deepak Varghese. I am trying to in co-operate ActiveMQ with C# .net
> for
> some kind of message passing. Could you specify how can I send a ".csv"
> file
> to active mq's queue using c#.net. If possible give some sample codes. I
> need to send and receive some files through MQ.
>
> Thanks,
> Deepak
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-file-passing-with-C-net-tp4715998.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: Release current version of Apache.NMS.STOMP

[Jim Gomes]

Hi Dave,

It'll probably take a couple of weeks at least. We'll need to prep and vote
on the artifacts. I'm a little busy with my day job, but I'll work on this
as quickly as I can. Be aware that if you use the NuGet packages, that is
out of our control. Apache doesn't maintain those.

Best,
Jim



On Wed, Aug 17, 2016, 12:09 AM Dave Senn  wrote:

> Hi Jim
>
> Thanks for your answer.
> When do you think will the new version be published?
> I know, I’m not a contributor, but is there anything I can help you with?
>
> Best,
> Dave
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Release-current-version-of-Apache-NMS-STOMP-tp4715483p4715562.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: Release current version of Apache.NMS.STOMP

[Jim Gomes]

Hi Dave,

Yes, it's probably a good time to put out a new release of that provider.

Best,
Jim


On Mon, Aug 15, 2016, 7:22 AM Dave Senn <dave.jon.s...@gmail.com> wrote:

> Hi Apache developers
>
> The current version of Apache.NMS.STOMP is not released.
> The latest available version is 1.5.4, see:
> http://activemq.apache.org/nms/stomp-downloads.html
> Version 1.5.4 is not compatible with any Broker other than Apache MQ,
> Apache
> Apollo, or maybe Apache Artemis (not tested). This problem was fixed by Jim
> Gomes, see: https://issues.apache.org/jira/browse/AMQNET-492
>
> Would it be possible to release the current version 1.7.1 of
> Apache.NMS.STOMP?
> The version 1.7.1 should contain the following fixes:
>
> https://issues.apache.org/jira/browse/AMQNET-394?jql=project%20%3D%20AMQNET%20AND%20status%20%3D%20Resolved%20AND%20affectedVersion%20in%20(1.5.4%2C%201.5.5%2C%201.5.6%2C%201.6.0%2C%201.6.1%2C%201.6.2%2C%201.6.3%2C%201.6.4%2C%201.6.5%2C%201.7.0%2C%201.7.1%2C%201.7.2)%20AND%20component%20%3D%20Stomp%20ORDER%20BY%20priority%20DESC
> * Zombie Consumer is created after failover
> * MessageId assumed to be a number
> * ResponseCorrelator transport is not stopped when Connection is closed
> * TcpTransport.cs - Close() taking 30 seconds
> * Add IDisposable interface to IDestination.
> * Port the NMS library, Stomp and MQTT providers to Xamarin Android
> * Port the ignoreExpiration option from Apache.NMS.ActiveMQ to
> Apache.NMS.Stomp
>
> All this fixes are not currently available to any Apache.NMS.STOMP users.
> This list of fixed issues and the fact that the currently released version
> of Apache.NMS.STOMP (1.5.4) is not compatible with the latest released
> version of Apache.NMS (1.7.1) should be reason enough to
> release the latest version of Apache.NMS.STOMP.
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Release-current-version-of-Apache-NMS-STOMP-tp4715483.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: ActiveMQ NMS and the new .NET Core

[Jim Gomes]

NMS runs on Mono and works very well on Linux already. I even ported it to
Xamarin and ran it on my Android phone using the STOMP provider to connect
to the AMQ broker. I have not tried running on .NET Core yet, but your
platform choice should be supported even without it.

On Wed, Jul 27, 2016, 8:14 AM magmasystems 
wrote:

> With Microsoft giving a big push to .NET Core, I am wondering if ActiveMQ
> NMS
> will ever be ported to .NET Core. We would love to rewrite some of our
> services so they could run on Windows or Linux, but we are concerned about
> having any Linux-based services being able to integrate with ActiveMQ.
>
> Thanks,
>
> Marc Adler
> Quantifi Solutions Inc
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-the-new-NET-Core-tp4714548.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [VOTE] Apache ActiveMQ 5.13.4

[Jim Gomes]

+1

On Fri, Jul 15, 2016 at 5:12 AM Jamie G.  wrote:

> +1 (non-binding)
>
> On Thu, Jul 14, 2016 at 1:40 PM, Hassen Bennour
>  wrote:
> > +1
> > Le 14 juil. 2016 17:47, "Christopher Shannon" <
> > christopher.l.shan...@gmail.com> a écrit :
> >
> >> Hi Everyone,
> >>
> >> I have created the ActiveMQ 5.13.4 release and it's ready for a vote.
> This
> >> release has almost 30 bug fixes and improvements.
> >>
> >> The list of resolved issues is here:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12335661=12311210
> >>
> >> You can get binary distributions here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1096/org/apache/activemq/apache-activemq/5.13.4/
> >>
> >> Source archives are here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1096/org/apache/activemq/activemq-parent/5.13.4/
> >>
> >> Maven repository is at:
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1096/
> >>
> >> Source tag:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=9d48997177697fbe0db24a45a8f6492268413f33
> >>
> >> Please vote to approve this release.  The vote will remain open for 72
> >> hours.
> >>
> >> [ ] +1 Release the binary as Apache ActiveMQ 5.13.4
> >> [ ] -1 (provide specific comments)
> >>
> >> Here's my +1
> >>
>

Re: [VOTE] Apache ActiveMQ 5.13.3 #2

[Jim Gomes]

+1

On Thu, Apr 28, 2016, 7:00 AM Timothy Bish  wrote:

> +1
>
> * Did a diff against the previous RC to check the changes were applied.
>
> On 04/28/2016 09:16 AM, Christopher Shannon wrote:
> > I have merged in the fix for the failing test and re-cut the release.
> >
> > The list of resolved issues is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12335045
> >
> > You can get binary distributions here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1092/org/apache/activemq/apache-activemq/5.13.3/
> >
> > Source archives are here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1092/org/apache/activemq/activemq-parent/5.13.3/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1092/
> >
> > Source tag:
> > *
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=f2f130b3c878d498cb561f7d4fa4613da56e7761
> > <
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=f2f130b3c878d498cb561f7d4fa4613da56e7761
> >*
> >
> > Please vote to approve this release.  The vote will remain open for 96
> > hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.13.3
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
> >
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [VOTE] Apache ActiveMQ 5.13.3

[Jim Gomes]

+1

On Tue, Apr 26, 2016, 7:41 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Hi Everyone,
>
> I have created the ActiveMQ 5.13.3 release and it's ready for a vote. This
> release has over 25 bug fixes and improvements.
>
> The list of resolved issues is here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12335045
>
> You can get binary distributions here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1091/org/apache/activemq/apache-activemq/5.13.3/
>
> Source archives are here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1091/org/apache/activemq/activemq-parent/5.13.3/
>
> Maven repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1091/
>
> Source tag:
> *
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=c49ab9fb5117a1adf0d57c0d1150bbff7026aede
> <
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=c49ab9fb5117a1adf0d57c0d1150bbff7026aede
> >*
>
> Please vote to approve this release.  The vote will remain open for 72
> hours.
>
> [ ] +1 Release the binary as Apache ActiveMQ 5.13.3
> [ ] -1 (provide specific comments)
>
> Here's my +1
>

Re: {VOTE] Release Apache.NMS.ActiveMQ 1.7.2

[Jim Gomes]

+1

On Mon, Apr 4, 2016, 6:36 AM Timothy Bish  wrote:

> Hello
>
> This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.7.2
>
> This is new bugfix release of the Apache.NMS.ActiveMQ v1.7.x line.  This
> release incorporates a few important fixes and improvements over the
> 1.7.1 release.
>
> The binaries and source bundles for the Release Candidate can be found
> here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-dotnet/1.7.x/
>
> The Wiki Page for this release is here:
> http://activemq.apache.org/nms/apachenmsactivemq-v172.html
>
> The list of issues resolved is here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201=12332993
>
> [ ] +1 Release the source as Apache NMS.ActiveMQ v1.7.2
> [ ] -1 (provide specific comments)
>
> Here's my +1
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [VOTE] Apache ActiveMQ 5.13.2

[Jim Gomes]

+1

On Wed, Mar 2, 2016, 9:28 AM Timothy Bish  wrote:

> +1
>
> * Check the signatures and checksums
> * Built from source and ran the sanity tests.
> * Ran a broker from the binary tar.gz archive and tested the webconsole
> * Ran some examples against the running broker.
> * Checked for license and notice files in source and binary archives.
>
> On 03/01/2016 12:15 PM, Christopher Shannon wrote:
> > Hi Everyone,
> >
> > I have created the ActiveMQ 5.13.2 release and it's ready for a vote.
> This
> > release has 15 bug fixes and improvements.
> >
> > The list of resolved issues is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12334774
> >
> > You can get binary distributions here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1089/org/apache/activemq/apache-activemq/5.13.2/
> >
> > Source archives are here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1089/org/apache/activemq/activemq-parent/5.13.2/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1089/
> >
> > Source tag:
> > *
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=6a2e71f11c72e0419f88cbd31d8bc99c35096abf
> > <
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=6a2e71f11c72e0419f88cbd31d8bc99c35096abf
> >*
> >
> > Please vote to approve this release.  The vote will remain open for 72
> > hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.13.2
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
> >
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [VOTE] Apache ActiveMQ 5.13.1

[Jim Gomes]

+1

On Tue, Feb 2, 2016, 10:35 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Hello everyone,
>
> I have created the ActiveMQ 5.13.1 release and it's ready for a vote. This
> release has 43 bug fixes and improvements.
>
> The list of resolved issues is here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12334251
>
> You can get binary distributions here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1086/org/apache/activemq/apache-activemq/5.13.1/
>
> Source archives are here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1086/org/apache/activemq/activemq-parent/5.13.1/
>
> Maven2 repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1086/
>
> Source tag:
> *
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=d60b73402cc11babb53e0a26e4537265f153492b
> <
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=d60b73402cc11babb53e0a26e4537265f153492b
> >*
>
> Please vote to approve this release.  The vote will remain open for 72
> hours.
>
> [ ] +1 Release the binary as Apache ActiveMQ 5.13.1
> [ ] -1 (provide specific comments)
>
> Here's my +1
>

Re: [VOTE] ActiveMQ 5.11.4/5.12.3

[Jim Gomes]

+1

On Wed, Feb 3, 2016, 11:53 AM Daniel Kulp  wrote:

> Several high importance fixes were back ported from the 5.13.1 release
> that we should get into patch releases.
>
>
> Staging Repositories:
> 5.12.3:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1087/
> 5.11.4:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1088/
>
> Tags:
> 5.12.3
>
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=231698ac73d6bc2b2e356a941e626ea9a2077c5c
> 5.11.4
>
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=67ddeb28d85d106dc2a8841cf8e2be7d8e33d0c1
>
>
> The vote will remain open for 72 hours.   Here is my +1
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: No IConnectionFactory implementation found for connection

[Jim Gomes]

Using NMSConnectionFactory will work if you format the URI correctly. When
using NMSConnectionFactory, you must prefix the URI with the provider
implementation you wish to use. For instance, if you want to use ActiveMQ
provider, use the following format:

activemq:failover:tcp://activemqhost:61616

If you want to use TIBCO provider, use the following format:

ems:tcp://tibcohost:7222

Those are just a couple of samples to show how to use NMSConnectionFactory.
It is the preferred method rather than using the straight ConnectionFactory.


On Fri, Jan 22, 2016, 1:36 AM enes.caglar  wrote:

> Fixed the problem by using ConnectionFactory instead of
> NMSConnectionFactory.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/No-IConnectionFactory-implementation-found-for-connection-tp4705373p4706313.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [DISCUSS] Purge ActiveMQ Snapshots Repo to get rid of old cruft

[Jim Gomes]

+1 for auto-removing the SNAPSHOTS of old projects.

On Mon, Jan 18, 2016 at 8:01 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> +1 to blow away the snapshots area.  I don't see any reason to keep around
> old snapshots of versions that were released and if they are not going to
> be released they should not be there.
>
> On Mon, Jan 18, 2016 at 10:53 AM, Timothy Bish 
> wrote:
>
> > We seem to have a bit of a mess in our snapshots area with lots of old
> > snapshots for ancient releases like 5.3, 5.4, etc along with snapshots
> > for an ActiveMQ 6.0.0 release that has caused some confusion recently.
> >
> > Some examples of old snapshots or snapshot to things that were never
> > released.
> >
> >
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/activemq-aerogear-integration/
> >
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/activemq-all/
> >
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/activemq-book/
> >
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/activemq-bootstrap/
> >
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/activemq-core-client/
> >
> > We can request that infra wipe out the snapshots area and let the
> > jenkins runs repopulate with only the current builds for active project
> > work.  Alternatively we can go through every folder and audit them but
> > given they are snapshots it's simpler just to blow them all away.
> >
> > Thoughts?
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> >
> >
>

Re: Added support for QueueBrowser and DeleteDestination in Apache.NMS.MSMQ provider + fixed EMS QueueBrowser

[Jim Gomes]

Hi Stéphane,

Thanks for submitting the patch.  I checked it in and resolved that issue.
It's good to see some attention going to MSMQ provider.

Best,
Jim


On Wed, Jan 6, 2016 at 2:27 PM, Stéphane Ramet 
wrote:

> Hi,
>
> I just submitted a patch as AMQNET-157
>  adding support for
> QueueBrowser and DeleteDestination in the Apache.NMS.MSMQ provider, and
> fixing Apache.NMS.EMS.QueueBrowser (actually implementing the "TODO" part
> in QueueBrowser.GetEnumerator).
>
> Regards,
>
> Stéphane Ramet
>

Re: [VOTE] Apache ActiveMQ 5.12.2 #3

[Jim Gomes]

+1

On Fri, Jan 8, 2016, 6:59 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> I will leave the vote open for a couple more days as we still need a couple
> more binding votes for this release to pass.
>
> On Thu, Jan 7, 2016 at 12:06 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > Yes, AMQ-6077 which is the configuration changes, has been backported to
> > 5.12.2
> >
> > On Thu, Jan 7, 2016 at 11:54 AM, Claus Ibsen 
> > wrote:
> >
> >> Hi
> >>
> >> So this release has the same change as in 5.13.0 about those excluded
> >> package names, which breaks end users applications.
> >>
> >> More here:
> >> http://activemq.apache.org/objectmessage.html
> >>
> >>
> >> Dejan is that latest stuff you did add to master branch also
> >> backported? Or do end users have only the choice of configure this
> >> with JVM system properties?
> >>
> >> If not I would have liked to backport that too, so users on 5.12.x
> >> have a chance to configure this. Its not everyone that is allowed to
> >> configure JVM system properties. Or restart an entire JVM because the
> >> activemq-client can only be configured from JVM system property.
> >>
> >>
> >>
> >>
> >> On Tue, Jan 5, 2016 at 5:18 PM, Christopher Shannon
> >>  wrote:
> >> > Hello everyone,
> >> >
> >> > The problem with AMQ-6094 has been fixed I have re-created the
> ActiveMQ
> >> > 5.12.2 release and it's ready for a vote. This release has over 25 bug
> >> > fixes and improvements.
> >> >
> >> > The list of resolved issues is here:
> >> >
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12333874
> >> >
> >> > You can get binary distributions here:
> >> >
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1082/org/apache/activemq/apache-activemq/5.12.2/
> >> >
> >> > Source archives are here:
> >> >
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1082/org/apache/activemq/activemq-parent/5.12.2/
> >> >
> >> > Maven2 repository is at:
> >> >
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1082/
> >> >
> >> > Source tag:
> >> > *
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=6ccbbce23de1d92daf83456accfdb03a4b768238
> >> > <
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=6ccbbce23de1d92daf83456accfdb03a4b768238
> >> >*
> >> >
> >> > Please vote to approve this release.  The vote will remain open for 72
> >> > hours.
> >> >
> >> > [ ] +1 Release the binary as Apache ActiveMQ 5.12.2
> >> > [ ] -1 (provide specific comments)
> >> >
> >> > Here's my +1 (non-binding)
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -
> >> http://davsclaus.com @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
> >
> >
>

Re: [VOTE] Apache ActiveMQ 5.12.2 #2

[Jim Gomes]

+1

On Thu, Dec 17, 2015, 6:44 AM Dejan Bosanac  wrote:

> +1 (binding)
>
> Looks good
>
> Regards
> --
> Dejan Bosanac
> about.me/dejanb
>
> On Thu, Dec 17, 2015 at 1:38 PM, Robbie Gemmell 
> wrote:
>
> > On 16 December 2015 at 15:48, Christopher Shannon
> >  wrote:
> > > Hello everyone,
> > >
> > > The problem with the previous release attempt has been fixed I have
> > > re-created the ActiveMQ 5.12.2 release and it's ready for a vote. This
> > > release has 20 bug fixes and
> > > improvements.
> > >
> > > The list of resolved issues is here:
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12333874
> > >
> > > You can get binary distributions here:
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1075/org/apache/activemq/apache-activemq/5.12.2/
> > >
> > > Source archives are here:
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1075/org/apache/activemq/activemq-parent/5.12.2/
> > >
> > > Maven2 repository is at:
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1075/
> > >
> > > Source tag:
> > > *
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=f4a05c45730bbf2b2c531e5d263447e53b7c7ddc
> > > <
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=f4a05c45730bbf2b2c531e5d263447e53b7c7ddc
> > >*
> > >
> > > Please vote to approve this release.  The vote will remain open for 120
> > > hours. (because of the weekend)
> > >
> > > [ ] +1 Release the binary as Apache ActiveMQ 5.12.2
> > > [ ] -1 (provide specific comments)
> > >
> > > Here's my +1 (non-binding)
> >
> >
> > +1 (non-binding)
> >
> > Verified the sigs, ran the source build and some of the tests, kicked
> > the tyres on the binary archive with an AMQP client, used the staged
> > maven repo with Qpid JMS master build+tests.
> >
> > Robbie
> >
>

Re: [VOTE] Apache ActiveMQ 5.13.0

[Jim Gomes]

+1

On Mon, Nov 30, 2015, 6:23 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Hello everyone,
>
> I have cut the ActiveMQ 5.13.0 release and it's ready for a vote. This
> release has over 80 bug fixes and new features.
>
> The list of resolved issues is here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12329848
>
> You can get binary distributions here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1071/org/apache/activemq/apache-activemq/5.13.0/
>
> Source archives are here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1071/org/apache/activemq/activemq-parent/5.13.0/
>
> Maven2 repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1071/
>
> Source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=abfe038ddfd6d6c4f7c41e106dabc815041b04c5
>
> Please vote to approve this release.  The vote will remain open for 72
> hours.
>
> [ ] +1 Release the binary as Apache ActiveMQ 5.13.0
> [ ] -1 (provide specific comments)
>
> Here's my +1 (non-binding)
>

Re: NMS Client -Exception message is not propagated in case of consumption failure

[Jim Gomes]

Some sample code showing the expected behavior might be helpful. Given
that, there may be a way to modify it to get the desired behavior back
using the new client.

Please attach it to the JIRA issue.

On Wed, Nov 11, 2015, 9:48 AM wiwi  wrote:

> Hi
>
> Can someone comment on this  issue
> 
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/NMS-Client-Exception-message-is-not-propagated-in-case-of-consumption-failure-tp4703859.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [VOTE] ActiveMQ 5.11.3

[Jim Gomes]

+1

On Thu, Oct 29, 2015, 9:22 AM Daniel Kulp  wrote:

>
> This is a vote to release Apache ActiveMQ 5.11.3
>
> Staging area:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1070/
>
> Tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=a820bfb4c5489ed842efc6ef5702f0fc21975c41
>
> Issues resolved:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12333254
>
>
> This vote will be open till Monday.   Here is my +1
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] Apache ActiveMQ 5.12.1

[Jim Gomes]

+1

On Tue, Oct 13, 2015 at 10:41 AM, Daniel Kulp  wrote:

> +1,   ran CXF’s tests  with it.
>
> Dan
>
>
>
> > On Oct 12, 2015, at 2:33 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
> >
> > Hello everyone,
> >
> > I have cut the ActiveMQ 5.12.1 release and it's ready for a vote. This
> > release has 22 bug fixes and
> > improvements.
> >
> > The list of resolved issues is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12333269
> >
> > You can get binary distributions here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1069/org/apache/activemq/apache-activemq/5.12.1/
> >
> > Source archives are here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1069/org/apache/activemq/activemq-parent/5.12.1/
> >
> > Maven2 repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1069/
> >
> > Source tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=21c8b4695f771065192ed7a24c92367ed9f6e564
> >
> > Please vote to approve this release.  The vote will remain open for 72
> > hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.12.1
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1 (non-binding)
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: {VOTE] Release Apache.NMS.ActiveMQ 1.7.1

[Jim Gomes]

+1

On Wed, Sep 30, 2015, 2:44 PM Timothy Bish  wrote:

> Hello
>
> This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.7.1
>
> This is first bugfix release of the Apache.NMS.ActiveMQ v1.7.x line.
> This release incorporates many fixes and improvements over the 1.7.0
> release.  Several fixes made to the Java OpenWire client were ported
> over as well as some fixes for issues in the .NET Distributed
> Transaction layer.
>
> The binaries and source bundles for the Release Candidate can be found
> here:
> http://people.apache.org/~tabish/nms-1.7.x
> 
>
> The Wiki Page for this release is here:
> http://activemq.apache.org/nms/apachenmsactivemq-v171.html
>
> The list of issues resolved is here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201=12329541
>
> Please cast your votes (the vote will be open for 72 hrs):
>
> [ ] +1 Release the source as Apache NMS.ActiveMQ v1.7.1
> [ ] -1 (provide specific comments)
>
> Here's my +1
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.b...@redhat.com | www.redhat.com
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [VOTE] Release Apache.NMS API 1.7.1

[Jim Gomes]

+1

On Tue, Sep 1, 2015, 6:37 AM Timothy Bish  wrote:

> Hello
>
> This is a call for a vote on the release of the Apache.NMS API v1.7.1.
> This package contains the API for the various Apache.NMS client along
> with utility classes and unit test cases against the abstract NMS API.
>
> This version of the API will be the basis for the next set of NMS client
> releases in the 1.7.x line including Apache.NMS.ActiveMQ.
>
> This is a bug fix version that adds a few minor fixes that are targeted
> at the client libraries that support MS DTC Transactions.
>
> The binaries and source bundles for the Release Candidate can be found
> here:
> [ http://people.apache.org/~tabish/nms-1.7.x
>  ]
>
> The Wiki Page for this release is here:
> [ http://activemq.apache.org/nms/apachenms-api-v171.html ]
>
> Please cast your votes (the vote will be open for 72 hrs):
>
> [ ] +1 Release the source as Apache NMS API 1.7.1
> [ ] -1 (provide specific comments)
>
> Here's my +1
>
> Regards,
> Tim
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.b...@redhat.com | www.redhat.com
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

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

[Jim Gomes]

+1

On Fri, Aug 14, 2015, 7:44 AM Timothy Bish tabish...@gmail.com wrote:

 Still need a couple more folks to review and vote, thanks!

 On Wed, Aug 12, 2015 at 10:44 AM, Timothy Bish tabish...@gmail.com
 wrote:

  New vote open for ActiveMQ-CPP v3.9.0 with fixed archives.
 
  This is a new major release of the ActiveMQ-CPP client.  I've ported
  most of the applicable fixes from the JMS client over to the C++ client
  as well as added support for OpenWire v11 and a bunch of other bug fixes
  and memory leak fixes.
 
  The source bundles for this release can be found here:
  http://people.apache.org/~tabish/cms-3.9.x
 
  The Wiki page for the release is here:
  http://activemq.apache.org/cms/activemq-cpp-390-release.html
 
  The list of issues fixed in this release is available here:
  
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311207styleName=Htmlversion=12324974
  
 
  Please cast your votes:
 
  [ ] +1 Release the source as Apache ActiveMQ-CPP 3.9.0
  [ ] -1 (provide specific comments)
 
  Here is my +1
 
  --
  Tim Bish
  Sr Software Engineer | RedHat Inc.
  tim.b...@redhat.com | www.redhat.com twitter: @tabish121
  blog: http://timbish.blogspot.com/
 
 
 


 --
 --
 Tim Bish

Re: [VOTE] Apache ActiveMQ 5.12.0

[Jim Gomes]

+1


On Mon, Aug 10, 2015 at 11:11 AM Timothy Bish tabish...@gmail.com wrote:

 Hi folks,

 I've just cut a release candidate for the ActiveMQ 5.12.0 release and
 it's ready for a vote. This release has 180+ bug fixes and
 improvements.  A large amount of work has gone into hardening the AMQP
 and MQTT protocol support along with numerous other improvements.

 The list of resolved issues is here:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210version=12329258

 You can get binary distributions here:

 https://repository.apache.org/content/repositories/orgapacheactivemq-1062/org/apache/activemq/apache-activemq/5.12.0/

 Source archives are here:

 https://repository.apache.org/content/repositories/orgapacheactivemq-1062/org/apache/activemq/activemq-parent/5.12.0/

 Maven2 repository is at:
 https://repository.apache.org/content/repositories/orgapacheactivemq-1062/

 Source tag:

 https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=a9eeb03520f074d5013239b8d8708a05ba31e176

 Please vote to approve this release.  The vote will remain open for 72
 hours.

 [ ] +1 Release the binary as Apache ActiveMQ 5.12.0
 [ ] -1 (provide specific comments)

 Here's my +1

 --
 Tim Bish

Re: [VOTE] ActiveMQ 5.11.2

[Jim Gomes]

+1

On Thu, Aug 6, 2015 at 7:57 AM, Daniel Kulp dk...@apache.org wrote:

 This is a vote to release Apache ActiveMQ 5.11.2

 Staging area:
 https://repository.apache.org/content/repositories/orgapacheactivemq-1061/

 Tag:

 https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=tag;h=16e90579044aa4a302164c1a59d5a88db265e81c

 Issues resolved:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210version=12329669


 This vote will be open till Monday.   Here is my +1


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

Re: Git workflow for committers

[Jim Gomes]

+1 to stay with the existing CTR practice that is well established in the
ActiveMQ community. That's why committership is granted. It's a level of
trust and confidence that you don't make low hanging fruit errors.

On Tue, Jun 9, 2015, 8:03 AM Daniel Kulp dk...@apache.org wrote:


  On Jun 9, 2015, at 10:47 AM, Andy Taylor andy.tayl...@gmail.com wrote:
 
  Dan,
 
  are you implying you are going to bypass the workflow that everyone else
 is using and commit directly? shouldnt we be consistent?

 That IS being consistent with the workflow that the *ACTIVEMQ* community
 has been using for the last 10+ years and has been using with the git repo
 for the last 2 years.So yes, I will be using the workflow that the
 community has agreed on and been using.   Thanks for asking.

 Dan


 
  On 09/06/15 15:45, Daniel Kulp wrote:
 
  On Jun 9, 2015, at 10:32 AM, Clebert Suconic 
 clebert.suco...@gmail.com wrote:
 
  It turns out we didn’t have a build setup for that.   We do now.
 
  The build I sent you before was a PR build from my own PR. Unless you
  set it up somewhere. Did you set up a new build for that?
 
  Yes:
 
 
 https://builds.apache.org/view/A-D/view/ActiveMQ/job/ActiveMQ-Artemis-Master/
 
  It builds on each commit to the canonical repository.
 
 
  Dan
 
 
 
 
  On Tue, Jun 9, 2015 at 10:29 AM, Clebert Suconic
  clebert.suco...@gmail.com wrote:
  Well,  I fixed that situation this morning.   I *THOUGHT* we had a
 CI build that was running on master on all commits.   That was the
 expectation and if something broke I would have gotten a “this is broken”
 email within 15 minutes or so.   It turns out we didn’t have a build setup
 for that.   We do now.
 
 
  I was not being specific about the situation itself.. just finding it
  as an example on where the CI build would been useful.
 
  We have a CI build that run on every Pull Request, not on every
 commit.
 
  We have a daily build but they are not as fast on catching issues.
 
 
  I'm asking if you could at least send a PR and wait for the build
 to finish.
 
  How do I do a pull request that doesn’t involve github?   I’m not
 using github for development.
 
 
  You really need github for that. You would need a github account
  associated with your apache email and send send the PR.
 
  You don't want to use github at all? If you don't want to use github,
  then you certainly won't be able to use these tools.
 
  Do you have any issues on using github?
 
 
 
  --
  Clebert Suconic
  http://community.jboss.org/people/clebert.suco...@jboss.com
  http://clebertsuconic.blogspot.com
 
 

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

Re: Git workflow for committers

[Jim Gomes]

+1
Nicely written, Dan. Thanks!

On Tue, Jun 9, 2015, 5:22 PM Daniel Kulp dk...@apache.org wrote:

 I guess if it was up to me to actually write a formal doc describing the
 process it would go something like:


 ———

 ActiveMQ uses a Commit-Then-Review process for getting changes contributed
 to the development branches.   In general, this means the ActiveMQ
 committers are free to directly commit their own work to master and push
 those changes to the canonical repository at Apache.   However, the
 expectation is that the developer has made a good effort to test their
 changes and is reasonably confident that the changes that are being
 committed will not “break the build.”

 What does it mean to be reasonably confident?  That may depend on the
 developer.  If the developer has run the same maven commands that the CI
 builds are running, they can likely be reasonably confident.   However, if
 the changes are significant, touches a wide area of code, or even if the
 developer just wants a second opinion, they are encouraged to engage other
 members of the community to obtain an additional review prior to commit.
  This can easily be done via a pull request on github, a patch file
 attached to an email or JIRA, committed to a branch in the Apache git repo,
 etc…  There are a variety of options open to them.Having additional
 eyes looking at significant changes prior to committing to the main
 development branches is definitely encouraged if it helps obtain the
 “reasonable confidence” that the build is not broken and code quality has
 not decreased.  We also have automatic builds setup to test github pull
 requests in advance to help establish a good level of confidence in the
 build.

 However, “things happen”.   We’re all human.   In the case where the build
 does break, the expectation is that the developer will make a best effort
 to get the builds fixed in a reasonable amount of time.If it cannot be
 fixed in a reasonable amount of time, the commit can be reverted and
 re-reviewed.

 ———

 Everyone:  does that about cover it?Did I miss anything?The github
 pull requests and gui tools are definitely a good tool chain in certain
 cases and I would still encourage those folks that find value in them to
 continue using them.   However, they cannot be “required”.


 Dan






  On Jun 9, 2015, at 7:57 PM, Clebert Suconic clebert.suco...@gmail.com
 wrote:
 
  +1 to stay with the existing CTR practice that is well established in
 the
  ActiveMQ community. That's why committership is granted. It's a level of
  trust and confidence that you don't make low hanging fruit errors.
 
  I actually screw up all the time ;) But I rather make eventual
  mistakes than not do something :)
 
  Anyways... lets keep the pull requests as a tool. For instance I just
  prevented an issue because of a PR Build
 
  https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/418/
  https://github.com/apache/activemq-artemis/pull/22
 
  But I don't want to talk about the issue itself on this Thread... This
  is a meta discussion.. I will talk about the issue itself on another
  post I'm about to make

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

Re: What does it take to become a committer on ActiveMQ?

[Jim Gomes]

This is a great discussion for our community to have. I wonder if other
Apache communities have a similar document detailing their guidelines.
Something to keep in mind as we form our guidelines is the overall Apache
view of committers (from https://community.apache.org/contributors/):

Becoming a Committer

There is nothing at The Apache Software Foundation that says you must write
code in order to be a committer. Anyone who is supportive of the community
and works in any of the CoPDoC areas (*Co*mmunity, *P*roject, *Do*cumentation,
*C*ode) is a likely candidate for committership.

Apache is a meritocracy. That is, once someone has contributed sufficiently
to any area of CoPDoC they can be voted in as a committer. *Being a
committer does not mean you commit code, it means you are committed to the
project. (emphasis added)*

One of the key contributions people can make to the community is through
the support of a wide user base by assisting users on the user list,
writing user oriented docs and ensuring the user viewpoint is understood by
all developers. A main idea behind being a committer is the ability to be a
mentor and to work cooperatively with your peers.

Some of those users become committers in their own right. Some will test
code, some will write documentation, some will do bug triage and some will
write code.



On Thu, May 21, 2015 at 9:56 AM Christopher Shannon 
christopher.l.shan...@gmail.com wrote:

 I usually like to create Jira tickets and submit pull requests for them
 without first bringing it up on the dev list. I find it's easier to discuss
 the issue directly on Jira after I have a patch already created.  I think
 it gives the reviewer a better idea of what I'm trying to accomplish and
 they can provide more useful feedback if I've submitted something to
 review.  Plus the issue on Jira gets linked automatically with the commit
 so it is easy to view later.

 I agree with Thiago that having a guide is welcome because I've also been
 wondering what is required to become a committer on ActiveMQ.

 On Thu, May 21, 2015 at 11:59 AM, Clebert Suconic 
 clebert.suco...@gmail.com
  wrote:

   Also, when offering pull requests, have they created a JIRA issue? Have
   they discussed their issue on the mailing list? Etc.
 
  Pull requests comments are sent to the dev-list. I don't think we
  should enforce discussion on the list before a Pull Request. It's nice
  in some cases but that's a case by case I think
 

Re: [VOTE] Apache Artemis 1.0.0 (RC3)

[Jim Gomes]

What is the current status of ARTEMIS-106? It's still marked as unresolved.

On Thu, May 21, 2015 at 9:39 AM Martyn Taylor mtay...@redhat.com wrote:

 Hello all.

 I've cut a third release candidate of Apache Artemis 1.0.0, addressing
 the RC2 feedback from community members.

 This is a first release of the Artemis project with protocol support for
 AMQP, STOMP, CORE, HORNETQ and OPENWIRE (alpha).

 N.B. The OpenWire implementation is at alpha with support for ActiveMQ
 JMS clients and basic transport.  More advanced features will be added
 progressively over the next series of releases.


 The release notes can be found here:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920version=12328953


 The binary distributions can be found here:

 https://repository.apache.org/content/repositories/orgapacheactivemq-1060/org/apache/activemq/apache-artemis/1.0.0/


 The source archives can be found here:

 https://repository.apache.org/content/repositories/orgapacheactivemq-1060/org/apache/activemq/apache-artemis/1.0.0/


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

 The source tag:

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


 The project website for that version has been staged to:
 http://people.apache.org/~martyntaylor/

 The vote will remain open for 72 hours.

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

 Here's my (non-binding) +1

 Regards
 Martyn

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

[Jim Gomes]

Another reason for not releasing this build: the destinations are not
automatically created. Server throws *ActiveMQNonExistentQueueException *when
trying to create a destination. Is this a configurable feature? If so, it
should be set to the standard ActiveMQ behavior by default (i.e.,
auto-create destinations). Here's the exception that gets thrown:

ERROR [org.apache.activemq.artemis.core.server] error decoding:
ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
message=AMQ119017: Queue
jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea does
not exist]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
[activemq-client-5.10.0.jar:5.10.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]


On Thu, May 14, 2015 at 8:05 AM, Jim Gomes e.se...@gmail.com wrote:

 -1

 Two reasons:

 1. The default configuration of localhost for the broker does not allow
 connections from off-machine. For some reason, socket connections are
 refused from non-local clients. I had to change the broker.xml config to
 use the machine's actual IP address, and then non-local clients could
 connect.
 2. The basic NMS OpenWire client fails to connect at all. It is getting
 unknown response IDs from the broker. I don't think the OpenWire protocol
 is being negotiated correctly. I am running with the latest NMS trunk
 version (1.8.0).


 On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor mtay...@redhat.com
 wrote:

 Hello all.

 I've cut a second release candidate of Apache Artemis 1.0.0 addressing
 the initial RC feedback from community members.

 This is a first release of the Artemis project with protocol support for
 AMQP, STOMP, CORE, HORNETQ and OPENWIRE.

 The release notes can be found here:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920version=12328953

 The binary distributions can be found here:

 https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/

 The source archives can be found here:

 https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/

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

 The source tag:

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

 The project website for that version has been staged to:
 http

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

[Jim Gomes]

The resource clean up code for dead clients doesn't seem to work reliably.
Probably not a show-stopper for a beta release, but definitely needs to be
cleaned up for production. Basically, when Artemis detected a dead client
(it stopped responding because I hit a breakpoint in my debugger), it tried
to clean it up, but failed. The result is that I can no longer connect a
new client from that client machine, because the broker thinks I already
have a connection. This is after I killed my client app and restarted it.
I'll log a bug for this one, but here's the server log:

WARN  [org.apache.activemq.artemis.core.server] AMQ222067: Connection
failure has been detected: AMQ119014: Did not receive data from
/xxx.xxx.xxx.xxx:53516. It is likely the client has exited or crashed
without closing its connection, or the network between the server and
client has failed. You also might have configured connection-ttl and
client-failure-check-period incorrectly. Please check user manual for more
information. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
WARN  [org.apache.activemq.artemis.core.server] AMQ222061: Client
connection failed, clearing up resources for session
ID:testmachine-63273-635671999039695375-1:0:-1
WARN  [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up
resources for session ID:testmachine-63273-635671999039695375-1:0:-1
WARN  [org.apache.activemq.artemis.core.server] AMQ222061: Client
connection failed, clearing up resources for session
ID:testmachine-63273-635671999039695375-1:0:1
WARN  [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up
resources for session ID:testmachine-63273-635671999039695375-1:0:1
*INFO  [org.apache.activemq.artemis.core.server] AMQ221021: failed to
remove connection*

Attempting to run a fresh client gets the following return exception on the
client:

Apache.NMS.Test.AsyncConsumeTest.TestAsynchronousConsume(Persistent):
Apache.NMS.InvalidClientIDException : Broker: mybroker - Client:
ID:AsyncConsumeTest:1:2 already connected from /xxx.xxx.xxx.xxx:53516




On Thu, May 14, 2015 at 11:37 AM, Jim Gomes e.se...@gmail.com wrote:

 Another reason for not releasing this build: the destinations are not
 automatically created. Server throws *ActiveMQNonExistentQueueException *when
 trying to create a destination. Is this a configurable feature? If so, it
 should be set to the standard ActiveMQ behavior by default (i.e.,
 auto-create destinations). Here's the exception that gets thrown:

 ERROR [org.apache.activemq.artemis.core.server] error decoding:
 ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
 message=AMQ119017: Queue
 jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea does
 not exist]
 at
 org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
 [artemis-server-1.0.0.jar:1.0.0]
 at
 org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
 [artemis-server-1.0.0.jar:1.0.0]
 at
 org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
 [artemis-server-1.0.0.jar:1.0.0]
 at
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
 [artemis-openwire-protocol-1.0.0.jar:1.0.0]
 at
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
 [artemis-openwire-protocol-1.0.0.jar:1.0.0]
 at
 org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
 [activemq-client-5.10.0.jar:5.10.0]
 at
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
 [artemis-openwire-protocol-1.0.0.jar:1.0.0]
 at
 org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
 [artemis-server-1.0.0.jar:1.0.0]
 at
 org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
 [artemis-core-client-1.0.0.jar:1.0.0]
 at
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

[Jim Gomes]

If it was done on purpose for security reasons, that's cool. However, it is
doubtful this is the way any broker will ever be run for real. The whole
purpose of a broker is to integrate disparate systems. It's like having a
web server start up without the ability to server web pages by default.
Kind of silly.

Anyway, I will log the bug with the NMS clients, and I do think the release
should be held up because of this problem. It's a show-stopper for NMS
clients.  Here's the server exception being thrown:

ERROR [org.apache.activemq.artemis.core.server] error decoding:
java.lang.IllegalStateException: Cannot handle command: ConsumerControl
{commandId = 0, responseRequired = false, consumerId =
ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
false, start = false, flush = false, prefetch = 32766, destination =
topic://UnitTest.Status}
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]



On Thu, May 14, 2015 at 8:20 AM, Justin Bertram jbert...@apache.com wrote:

 IMO the broker correctly binds to localhost only and does not, by default,
 allow connections from remote machines.  This is a simple security/sanity
 measure to prevent access to default (i.e. unsecured) instances.

 The merit of this configuration is obviously up for debate, but it's worth
 noting it was done on purpose.


 Justin

 - Original Message -
 From: Jim Gomes e.se...@gmail.com
 To: ActiveMQ Dev dev@activemq.apache.org
 Sent: Thursday, May 14, 2015 10:05:55 AM
 Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)

 -1

 Two reasons:

 1. The default configuration of localhost for the broker does not allow
 connections from off-machine. For some reason, socket connections are
 refused from non-local clients. I had to change the broker.xml config to
 use the machine's actual IP address, and then non-local clients could
 connect.
 2. The basic NMS OpenWire client fails to connect at all. It is getting
 unknown response IDs from the broker. I don't think the OpenWire protocol
 is being negotiated correctly. I am running with the latest NMS trunk
 version (1.8.0).


 On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor mtay...@redhat.com
 wrote:

  Hello all.
 
  I've cut a second release candidate of Apache Artemis 1.0.0 addressing
 the
  initial RC feedback from community members.
 
  This is a first release of the Artemis project with protocol support for
  AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
 
  The release notes can be found here:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920version=12328953
 
  The binary distributions can be found here:
 
 
 https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
 
  The source archives can be found here:
 
 
 https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
 
  The Maven repository is here:
 
 https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
 
  The source tag:
 
 
 https://git-wip-us.apache.org/repos/asf

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

[Jim Gomes]

Thanks, Clebert!

And thanks for the quick update on the default bindings.

On Thu, May 14, 2015 at 8:59 AM, Clebert Suconic clebert.suco...@gmail.com
wrote:

 here is the JIRA with the current progress on the renames:

 https://issues.apache.org/jira/browse/INFRA-9543

 On Thu, May 14, 2015 at 11:41 AM, Jim Gomes e.se...@gmail.com wrote:
  Logged bug ACTIVEMQ6-106.
 
  And at the risk of opening a big can of worms, do we need to have
  Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
  something? I was very hesitant to enter a bug there, and had to
  double-check that it was indeed the Artemis bug tracker.
 
  On Thu, May 14, 2015 at 8:28 AM, Jim Gomes e.se...@gmail.com wrote:
 
  If it was done on purpose for security reasons, that's cool. However, it
  is doubtful this is the way any broker will ever be run for real. The
 whole
  purpose of a broker is to integrate disparate systems. It's like having
 a
  web server start up without the ability to server web pages by default.
  Kind of silly.
 
  Anyway, I will log the bug with the NMS clients, and I do think the
  release should be held up because of this problem. It's a show-stopper
 for
  NMS clients.  Here's the server exception being thrown:
 
  ERROR [org.apache.activemq.artemis.core.server] error decoding:
  java.lang.IllegalStateException: Cannot handle command: ConsumerControl
  {commandId = 0, responseRequired = false, consumerId =
  ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
  false, start = false, flush = false, prefetch = 32766, destination =
  topic://UnitTest.Status}
  at
 
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
  [artemis-openwire-protocol-1.0.0.jar:1.0.0]
  at
 
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
  [artemis-openwire-protocol-1.0.0.jar:1.0.0]
  at
 
 org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
  [artemis-server-1.0.0.jar:1.0.0]
  at
 
 org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
  [artemis-core-client-1.0.0.jar:1.0.0]
  at
 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
 
 
 
  On Thu, May 14, 2015 at 8:20 AM, Justin Bertram jbert...@apache.com
  wrote:
 
  IMO the broker correctly binds to localhost only and does not, by
  default, allow connections from remote machines.  This is a simple
  security/sanity measure to prevent access to default (i.e. unsecured)
  instances.
 
  The merit of this configuration is obviously up for debate, but it's
  worth noting it was done on purpose.
 
 
  Justin
 
  - Original Message -
  From: Jim Gomes e.se...@gmail.com
  To: ActiveMQ Dev dev@activemq.apache.org
  Sent: Thursday, May 14, 2015 10:05:55 AM
  Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
 
  -1
 
  Two reasons:
 
  1. The default configuration of localhost for the broker does not allow
  connections from off-machine. For some reason, socket connections are
  refused from non-local clients. I had to change the broker.xml config
 to
  use the machine's actual IP address, and then non-local clients could
  connect.
  2. The basic NMS OpenWire client fails to connect at all. It is getting
  unknown response IDs from the broker. I don't think the OpenWire
 protocol
  is being negotiated correctly. I am running with the latest NMS trunk
  version (1.8.0).
 
 
  On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor mtay...@redhat.com
  wrote:
 
   Hello all

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

[Jim Gomes]

-1

Two reasons:

1. The default configuration of localhost for the broker does not allow
connections from off-machine. For some reason, socket connections are
refused from non-local clients. I had to change the broker.xml config to
use the machine's actual IP address, and then non-local clients could
connect.
2. The basic NMS OpenWire client fails to connect at all. It is getting
unknown response IDs from the broker. I don't think the OpenWire protocol
is being negotiated correctly. I am running with the latest NMS trunk
version (1.8.0).


On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor mtay...@redhat.com wrote:

 Hello all.

 I've cut a second release candidate of Apache Artemis 1.0.0 addressing the
 initial RC feedback from community members.

 This is a first release of the Artemis project with protocol support for
 AMQP, STOMP, CORE, HORNETQ and OPENWIRE.

 The release notes can be found here:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920version=12328953

 The binary distributions can be found here:

 https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/

 The source archives can be found here:

 https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/

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

 The source tag:

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

 The project website for that version has been staged to:
 http://people.apache.org/~martyntaylor/

 The vote will remain open for 72 hours.

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

 Here's my (non-binding) +1

 Regards
 Martyn

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

[Jim Gomes]

Logged bug ACTIVEMQ6-106.

And at the risk of opening a big can of worms, do we need to have
Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
something? I was very hesitant to enter a bug there, and had to
double-check that it was indeed the Artemis bug tracker.

On Thu, May 14, 2015 at 8:28 AM, Jim Gomes e.se...@gmail.com wrote:

 If it was done on purpose for security reasons, that's cool. However, it
 is doubtful this is the way any broker will ever be run for real. The whole
 purpose of a broker is to integrate disparate systems. It's like having a
 web server start up without the ability to server web pages by default.
 Kind of silly.

 Anyway, I will log the bug with the NMS clients, and I do think the
 release should be held up because of this problem. It's a show-stopper for
 NMS clients.  Here's the server exception being thrown:

 ERROR [org.apache.activemq.artemis.core.server] error decoding:
 java.lang.IllegalStateException: Cannot handle command: ConsumerControl
 {commandId = 0, responseRequired = false, consumerId =
 ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
 false, start = false, flush = false, prefetch = 32766, destination =
 topic://UnitTest.Status}
 at
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
 [artemis-openwire-protocol-1.0.0.jar:1.0.0]
 at
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
 [artemis-openwire-protocol-1.0.0.jar:1.0.0]
 at
 org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
 [artemis-server-1.0.0.jar:1.0.0]
 at
 org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
 [artemis-core-client-1.0.0.jar:1.0.0]
 at
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at
 io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
 [netty-all-4.0.20.Final.jar:4.0.20.Final]
 at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]



 On Thu, May 14, 2015 at 8:20 AM, Justin Bertram jbert...@apache.com
 wrote:

 IMO the broker correctly binds to localhost only and does not, by
 default, allow connections from remote machines.  This is a simple
 security/sanity measure to prevent access to default (i.e. unsecured)
 instances.

 The merit of this configuration is obviously up for debate, but it's
 worth noting it was done on purpose.


 Justin

 - Original Message -
 From: Jim Gomes e.se...@gmail.com
 To: ActiveMQ Dev dev@activemq.apache.org
 Sent: Thursday, May 14, 2015 10:05:55 AM
 Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)

 -1

 Two reasons:

 1. The default configuration of localhost for the broker does not allow
 connections from off-machine. For some reason, socket connections are
 refused from non-local clients. I had to change the broker.xml config to
 use the machine's actual IP address, and then non-local clients could
 connect.
 2. The basic NMS OpenWire client fails to connect at all. It is getting
 unknown response IDs from the broker. I don't think the OpenWire protocol
 is being negotiated correctly. I am running with the latest NMS trunk
 version (1.8.0).


 On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor mtay...@redhat.com
 wrote:

  Hello all.
 
  I've cut a second release candidate of Apache Artemis 1.0.0 addressing
 the
  initial RC feedback from community members.
 
  This is a first release of the Artemis project with protocol support for
  AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
 
  The release notes can be found here:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920version=12328953
 
  The binary distributions can be found here:
 
 
 https://repository.apache.org/content

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

[Jim Gomes]

It's impossible to run any of the NMS unit tests with destination
autocreate set to false. If Artemis is meant to be a drop-in replacement
(as much as possible) for ActiveMQ, then we should match feature defaults,
unless there is an definite problem that is being solved by changing the
defaults.

On Thu, May 14, 2015 at 11:55 AM, Andy Taylor andy.tayl...@gmail.com
wrote:

 I think it's fine to release with auto create set to false. Remember 1.0.0
 is just a starting point. We can discuss what needs changing after the
 release in a separate discussion. I'm sure there will be lots of
 differences like this but we shouldn't let them block this first release.

 Great job on kicking Artemis's tyres by the way Jim.
 On 14 May 2015 19:37, Jim Gomes e.se...@gmail.com wrote:

  Another reason for not releasing this build: the destinations are not
  automatically created. Server throws *ActiveMQNonExistentQueueException
  *when
  trying to create a destination. Is this a configurable feature? If so, it
  should be set to the standard ActiveMQ behavior by default (i.e.,
  auto-create destinations). Here's the exception that gets thrown:
 
  ERROR [org.apache.activemq.artemis.core.server] error decoding:
  ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
  message=AMQ119017: Queue
  jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea does
  not exist]
  at
 
 
 org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
  [artemis-server-1.0.0.jar:1.0.0]
  at
 
 
 org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
  [artemis-server-1.0.0.jar:1.0.0]
  at
 
 
 org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
  [artemis-server-1.0.0.jar:1.0.0]
  at
 
 
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
  [artemis-openwire-protocol-1.0.0.jar:1.0.0]
  at
 
 
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
  [artemis-openwire-protocol-1.0.0.jar:1.0.0]
  at
 
 org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
  [activemq-client-5.10.0.jar:5.10.0]
  at
 
 
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
  [artemis-openwire-protocol-1.0.0.jar:1.0.0]
  at
 
 
 org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
  [artemis-server-1.0.0.jar:1.0.0]
  at
 
 
 org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
  [artemis-core-client-1.0.0.jar:1.0.0]
  at
 
 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 
 io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 
 io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 
 io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 
 io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 
 io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at
 
 
 io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
  [netty-all-4.0.20.Final.jar:4.0.20.Final]
  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
 
 
  On Thu, May 14, 2015 at 8:05 AM, Jim Gomes e.se...@gmail.com wrote:
 
   -1
  
   Two reasons:
  
   1. The default configuration of localhost for the broker does not allow
   connections from off-machine. For some reason, socket connections are
   refused from non-local clients. I had to change the broker.xml config
 to
   use the machine's actual IP address, and then non-local clients could
   connect.
   2. The basic NMS OpenWire client fails to connect at all. It is getting
   unknown response IDs from the broker. I don't think the OpenWire
 protocol
   is being negotiated correctly. I am running with the latest NMS trunk
   version (1.8.0).
  
  
   On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor mtay...@redhat.com

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

[Jim Gomes]

Yeah, we don't have to have everything fixed, however, ACTIVEMQ6-106 is a
showstopper, because consumers are getting kicked off even when the are
sending KeepAlive and even when they are active. I attached a sample
application to the JIRA that can reproduce the item.

As far as I can tell, the destinations are getting created (at least I
could send/receive messages), but it's throwing a server side exception.
That can be put off as a fix for next release.


On Thu, May 14, 2015 at 12:52 PM, Clebert Suconic clebert.suco...@gmail.com
 wrote:

 This is going to be the first release... and even the first with
 OpenWire...  there certainly going to be other issues.


 I Think of this like a Beta...  people will then have time to kick it
 out and raise issues...

 then this should be released very frequently...


 On Thu, May 14, 2015 at 3:29 PM, Clebert Suconic
 clebert.suco...@gmail.com wrote:
  Is that what it is? just setting auto-create to true will fix it?
 
 
  if that's the case... it's an easy fix?
 
  On Thu, May 14, 2015 at 3:06 PM, Andy Taylor andy.tayl...@gmail.com
 wrote:
  Agreed. But there are lots of them. Let's get 1.0.0 out and then come up
  with a migration path for all of them.
  On 14 May 2015 20:04, Jim Gomes e.se...@gmail.com wrote:
 
  It's impossible to run any of the NMS unit tests with destination
  autocreate set to false. If Artemis is meant to be a drop-in
 replacement
  (as much as possible) for ActiveMQ, then we should match feature
 defaults,
  unless there is an definite problem that is being solved by changing
 the
  defaults.
 
  On Thu, May 14, 2015 at 11:55 AM, Andy Taylor andy.tayl...@gmail.com
  wrote:
 
   I think it's fine to release with auto create set to false. Remember
  1.0.0
   is just a starting point. We can discuss what needs changing after
 the
   release in a separate discussion. I'm sure there will be lots of
   differences like this but we shouldn't let them block this first
 release.
  
   Great job on kicking Artemis's tyres by the way Jim.
   On 14 May 2015 19:37, Jim Gomes e.se...@gmail.com wrote:
  
Another reason for not releasing this build: the destinations are
 not
automatically created. Server throws
 *ActiveMQNonExistentQueueException
*when
trying to create a destination. Is this a configurable feature? If
 so,
  it
should be set to the standard ActiveMQ behavior by default (i.e.,
auto-create destinations). Here's the exception that gets thrown:
   
ERROR [org.apache.activemq.artemis.core.server] error decoding:
ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST
message=AMQ119017: Queue
   
 jms.queue.TEST.AsyncConsumeTest.2df14c0d-4e0c-4d74-91ab-8abbd3ba02ea
  does
not exist]
at
   
   
  
 
 org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1401)
[artemis-server-1.0.0.jar:1.0.0]
at
   
   
  
 
 org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1390)
[artemis-server-1.0.0.jar:1.0.0]
at
   
   
  
 
 org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1380)
[artemis-server-1.0.0.jar:1.0.0]
at
   
   
  
 
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.deleteQueue(OpenWireProtocolManager.java:689)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
   
   
  
 
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processRemoveDestination(OpenWireConnection.java:1641)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
   
  
 
 org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:124)
[activemq-client-5.10.0.jar:5.10.0]
at
   
   
  
 
 org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
   
   
  
 
 org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
at
   
   
  
 
 org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
at
   
   
  
 
 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
   
   
  
 
 io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
   
   
  
 
 io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
   
   
  
 
 io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty

Re: [DISCUSS] Should ActiveMQ {CodeName} Support Backward Compatibility with HornetQ...

[Jim Gomes]

There's a difference between should and can. Is this a short term support
via deprecated and planned obsolescence, or is it long term first class
support? I don't really know much about what the HornetQ support entails.

On Wed, Apr 15, 2015, 9:18 AM Clebert Suconic clebert.suco...@gmail.com
wrote:

 I think it doesn't hurt to do it. it's only beneficial.


 The concern probably started from this Pull Request:
 https://github.com/apache/activemq-6/pull/205

 Which we will merge it.. I will just extend the change to coupe with
 old clients.




 On Wed, Apr 15, 2015 at 10:53 AM, Hiram Chirino hi...@hiramchirino.com
 wrote:
  Yep.  I think supporting old HornetQ clients should be a goal too.  If
  it's not too much effort will open our projects to more users which I
  think is a good thing.
 
  On Wed, Apr 15, 2015 at 11:43 AM, James Carman
  ja...@carmanconsulting.com wrote:
  It has come to light that some folks feel that ActiveMQ {CodeName}
  should support backward compatibility with HornetQ.  I don't think
  this has been discussed specifically within the community yet, so I
  thought I'd bring it up.
 
  James
 
 
 
  --
  Hiram Chirino
  Engineering | Red Hat, Inc.
  hchir...@redhat.com | fusesource.com | redhat.com
  skype: hiramchirino | twitter: @hiramchirino



 --
 Clebert Suconic
 http://community.jboss.org/people/clebert.suco...@jboss.com
 http://clebertsuconic.blogspot.com

Re: [DISCUSS] ActiveMQ {CodeName} Must-Have Features...

[Jim Gomes]

Must have:

Support for the Timestamp plugin, or (better) built-in equivalent. My usage
requires the ability to override timestamps on submitted messages to
correct for out of synch clocks between clients and server.

On Wed, Apr 15, 2015, 8:58 AM James Carman ja...@carmanconsulting.com
wrote:

 In order for ActiveMQ {CodeName} to take over as the next generation
 of ActiveMQ, it obviously must have some level of feature parity with
 the existing ActiveMQ 5.x (or 6.x if it's released before that
 transition) offering.  We should come up with some level of a roadmap
 together about which features are required.  Thus far, the only
 big-ticket items that have been addressed are:

 1.  The OpenWire protocol is supported
 2.  Auto-creation of destinations (mostly complete).

 This is obviously not all of what the existing ActiveMQ is all about.
 What other features are folks wanting to see in the next generation
 ActiveMQ?

 James

Re: [DISCUSS] Should ActiveMQ {CodeName} Support Backward Compatibility with HornetQ...

[Jim Gomes]

Then I would say yes, we should support them through a transition plan. It
might be helpful to lay out a time line of which version this support will
be removed. That gives fair notice to everyone involved.

From what I've seen in other messages, it seems like this support is there,
or almost there, already. Is that correct?
 On Apr 15, 2015 11:20 AM, Clebert Suconic clebert.suco...@gmail.com
wrote:

 I would say it's a short term for older clients being able to connect
 via deprecated.

 On Wed, Apr 15, 2015 at 12:37 PM, Jim Gomes jgo...@apache.org wrote:
  There's a difference between should and can. Is this a short term support
  via deprecated and planned obsolescence, or is it long term first class
  support? I don't really know much about what the HornetQ support entails.
 
  On Wed, Apr 15, 2015, 9:18 AM Clebert Suconic clebert.suco...@gmail.com
 
  wrote:
 
  I think it doesn't hurt to do it. it's only beneficial.
 
 
  The concern probably started from this Pull Request:
  https://github.com/apache/activemq-6/pull/205
 
  Which we will merge it.. I will just extend the change to coupe with
  old clients.
 
 
 
 
  On Wed, Apr 15, 2015 at 10:53 AM, Hiram Chirino hi...@hiramchirino.com
 
  wrote:
   Yep.  I think supporting old HornetQ clients should be a goal too.  If
   it's not too much effort will open our projects to more users which I
   think is a good thing.
  
   On Wed, Apr 15, 2015 at 11:43 AM, James Carman
   ja...@carmanconsulting.com wrote:
   It has come to light that some folks feel that ActiveMQ {CodeName}
   should support backward compatibility with HornetQ.  I don't think
   this has been discussed specifically within the community yet, so I
   thought I'd bring it up.
  
   James
  
  
  
   --
   Hiram Chirino
   Engineering | Red Hat, Inc.
   hchir...@redhat.com | fusesource.com | redhat.com
   skype: hiramchirino | twitter: @hiramchirino
 
 
 
  --
  Clebert Suconic
  http://community.jboss.org/people/clebert.suco...@jboss.com
  http://clebertsuconic.blogspot.com
 



 --
 Clebert Suconic
 http://community.jboss.org/people/clebert.suco...@jboss.com
 http://clebertsuconic.blogspot.com

Re: [DISCUSS] Should ActiveMQ {CodeName} Support Backward Compatibility with HornetQ...

[Jim Gomes]

Sounds good. Thanks for the update, Clebert!

On Wed, Apr 15, 2015, 1:36 PM Clebert Suconic clebert.suco...@gmail.com
wrote:

 It's hard to come up with a time.. it only depends on users.  We
 need to make proper announcements at the hornetq community first and
 talk to users there about that. So far we are in wait mode for the
 first release.

  From what I've seen in other messages, it seems like this support is
 there,
  or almost there, already. Is that correct?

 There are a few places like internal properties where this would cause
 semantic issues, so we left those untouched. (which was the PR sent).

 That PR sent will break compatibility but I will follow up with
 something preserving compatibility without offending new clients.

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

[Jim Gomes]

+0

Have no preference for any of them, but recommend going with the fewest
syllables.
On Apr 14, 2015 8:43 AM, Hiram Chirino hi...@hiramchirino.com wrote:

 Now that we have chosen to give the HornetQ code donation a code name,
 it's time to pick what that code name will be.  Please select from one
 of the following options:

 [a] ActiveMQ Artemis
 [b] ActiveMQ Luna
 [c] ActiveMQ Reactive

 Vote will be open for 72 hours.  The option with the most votes will win.

 Regards,
 Hiram

 --
 Hiram Chirino
 Engineering | Red Hat, Inc.
 hchir...@redhat.com | fusesource.com | redhat.com
 skype: hiramchirino | twitter: @hiramchirino

Re: [DISCUSS] Fix Sorting of Board Reports

[Jim Gomes]

Thanks for the explanation. That helps.

So, I guess we could discuss the merits of keeping the Board Reports on our
wiki, as it does seem somewhat redundant. As long as they exist on the
wiki, it would be helpful to have a better indexing system.

Perhaps Hiram can offer background as to the purpose and intent of the
Board Reports being published on the wiki?

Best,
Jim



On Thu, Apr 9, 2015 at 10:27 AM, Daniel Kulp dk...@apache.org wrote:


  On Apr 9, 2015, at 1:02 PM, Jim Gomes jgo...@apache.org wrote:
 
  Thanks for the link, Dan. I didn't know those were there. I think the
 main
  difference here is that link is to the Board Minutes, whereas the
 ActiveMQ
  wiki has the Board Report. They seem to be identical, but will they
 always
  be?

 Possibly not, but it would NORMALLY be because the board has decided
 something should be private (like names of people being voted on or
 something) in which case it should likely not have been in our public
 version as well.   Doesn't happen too often.  Also, they would remove any
 wiki formatting type things that wouldn't look right in the text form
 they use.


  And even if they are identical, do we still need to have the redundancy
  for trace-ability? For instance, if the Board, for whatever reason,
 claims
  they didn't receive the report, we have documentation on the wiki showing
  the Report was produced.

 I don't really think the board would care if one was produced or not.
  It's the chair's job to make sure the board gets the report.  If they
 don't get it, they ask the chair to report again next month.   If the chair
 consistently has issues, they'd likely replace the chair.Another thing
 to keep in mind:  it's the Chairs job to create the report that reflects
 the state of the community.  The chair MAY include the wider community in
 creating that report, but that's not a requirement.   Thus, saying the
 community produced one, the chair didn't submit it really wouldn't matter
 at all.

 Dan


 
  That's me just trying to understand the reason for the Board Report
 page's
  existence.
 
  -Jim
 
 
  On Thu, Apr 9, 2015 at 9:53 AM, Daniel Kulp dk...@apache.org wrote:
 
 
  No objection, but why don't we just delete the page and point at the
  official records:
 
  https://whimsy.apache.org/board/minutes/ActiveMQ.html
 
  Dan
 
 
  On Apr 9, 2015, at 12:35 PM, Jim Gomes jgo...@apache.org wrote:
 
  I recently went out to look at previous Board Reports (
  http://activemq.apache.org/apache-activemq-board-reports.html) and
 found
  the current sorting method difficult to deal with. Unless we are
 required
  to use the page naming format, I would like to change it to the
 following
  format:
 
  Apache ActiveMQ Board Report - 2009.01 January
  Apache ActiveMQ Board Report - 2009.04 April
  Apache ActiveMQ Board Report - 2009.07 July
  .
  .
  .
 
  I would then set it to sort in reverse order so the most recent report
 is
  automatically at the top, and they descend in chronological order. The
  current sorting puts the most recent board report (2015/02) in the
 middle
  of the pack, making it difficult to find. Good luck trying to find the
  report directly prior to that.
 
  I will make the changes, unless anyone has other suggestions.
 
  Best,
  Jim
 
  --
  Daniel Kulp
  dk...@apache.org - http://dankulp.com/blog
  Talend Community Coder - http://coders.talend.com
 
 

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

Re: [DISCUSS] Fix Sorting of Board Reports

[Jim Gomes]

Thanks, Tim. That is a clear and compelling reason to keep them there.

With that clarified, does anyone have any comments on the renaming of the
pages to improve the indexing?

Best,
Jim


On Thu, Apr 9, 2015 at 11:16 AM, Timothy Bish tabish...@gmail.com wrote:

 On 04/09/2015 02:13 PM, Jim Gomes wrote:
  Thanks for the explanation. That helps.
 
  So, I guess we could discuss the merits of keeping the Board Reports on
 our
  wiki, as it does seem somewhat redundant. As long as they exist on the
  wiki, it would be helpful to have a better indexing system.
 
  Perhaps Hiram can offer background as to the purpose and intent of the
  Board Reports being published on the wiki?
 
  Best,
  Jim
 
 
 
  On Thu, Apr 9, 2015 at 10:27 AM, Daniel Kulp dk...@apache.org wrote:
 
  On Apr 9, 2015, at 1:02 PM, Jim Gomes jgo...@apache.org wrote:
 
  Thanks for the link, Dan. I didn't know those were there. I think the
  main
  difference here is that link is to the Board Minutes, whereas the
  ActiveMQ
  wiki has the Board Report. They seem to be identical, but will they
  always
  be?
  Possibly not, but it would NORMALLY be because the board has decided
  something should be private (like names of people being voted on or
  something) in which case it should likely not have been in our public
  version as well.   Doesn't happen too often.  Also, they would remove
 any
  wiki formatting type things that wouldn't look right in the text form
  they use.
 
 
  And even if they are identical, do we still need to have the redundancy
  for trace-ability? For instance, if the Board, for whatever reason,
  claims
  they didn't receive the report, we have documentation on the wiki
 showing
  the Report was produced.
  I don't really think the board would care if one was produced or not.
   It's the chair's job to make sure the board gets the report.  If they
  don't get it, they ask the chair to report again next month.   If the
 chair
  consistently has issues, they'd likely replace the chair.Another
 thing
  to keep in mind:  it's the Chairs job to create the report that reflects
  the state of the community.  The chair MAY include the wider community
 in
  creating that report, but that's not a requirement.   Thus, saying the
  community produced one, the chair didn't submit it really wouldn't
 matter
  at all.
 
  Dan
 
 
  That's me just trying to understand the reason for the Board Report
  page's
  existence.
 
  -Jim
 
 
  On Thu, Apr 9, 2015 at 9:53 AM, Daniel Kulp dk...@apache.org wrote:
 
  No objection, but why don't we just delete the page and point at the
  official records:
 
  https://whimsy.apache.org/board/minutes/ActiveMQ.html
 
  Dan
 
 
  On Apr 9, 2015, at 12:35 PM, Jim Gomes jgo...@apache.org wrote:
 
  I recently went out to look at previous Board Reports (
  http://activemq.apache.org/apache-activemq-board-reports.html) and
  found
  the current sorting method difficult to deal with. Unless we are
  required
  to use the page naming format, I would like to change it to the
  following
  format:
 
  Apache ActiveMQ Board Report - 2009.01 January
  Apache ActiveMQ Board Report - 2009.04 April
  Apache ActiveMQ Board Report - 2009.07 July
  .
  .
  .
 
  I would then set it to sort in reverse order so the most recent
 report
  is
  automatically at the top, and they descend in chronological order.
 The
  current sorting puts the most recent board report (2015/02) in the
  middle
  of the pack, making it difficult to find. Good luck trying to find
 the
  report directly prior to that.
 
  I will make the changes, unless anyone has other suggestions.
 
  Best,
  Jim
  --
  Daniel Kulp
  dk...@apache.org - http://dankulp.com/blog
  Talend Community Coder - http://coders.talend.com
 
 
  --
  Daniel Kulp
  dk...@apache.org - http://dankulp.com/blog
  Talend Community Coder - http://coders.talend.com
 
 
 I believe that he does this as a place to create and edit them and allow
 for other members to contribute if they so desire before he submits
 them.  I've edited a couple in the past prior to submission to add CMS
 or NMS release notes.

 --
 Tim Bish
 Sr Software Engineer | RedHat Inc.
 tim.b...@redhat.com | www.redhat.com
 twitter: @tabish121
 blog: http://timbish.blogspot.com/

[DISCUSS] Fix Sorting of Board Reports

[Jim Gomes]

I recently went out to look at previous Board Reports (
http://activemq.apache.org/apache-activemq-board-reports.html) and found
the current sorting method difficult to deal with. Unless we are required
to use the page naming format, I would like to change it to the following
format:

Apache ActiveMQ Board Report - 2009.01 January
Apache ActiveMQ Board Report - 2009.04 April
Apache ActiveMQ Board Report - 2009.07 July
.
.
.

I would then set it to sort in reverse order so the most recent report is
automatically at the top, and they descend in chronological order. The
current sorting puts the most recent board report (2015/02) in the middle
of the pack, making it difficult to find. Good luck trying to find the
report directly prior to that.

I will make the changes, unless anyone has other suggestions.

Best,
Jim

Re: [DISCUSS] Fix Sorting of Board Reports

[Jim Gomes]

Thanks for the feedback, everyone. It looks like there's no technical
reason for the current naming scheme. I just wanted to make sure I wasn't
breaking some kind of formatting requirement from the Board.

I'll get them fixed up shortly.

Best,
Jim


On Thu, Apr 9, 2015 at 12:12 PM, Gary Tully gary.tu...@gmail.com wrote:

 renaming makes sense to me.
 On 9 Apr 2015 19:44, Jim Gomes e.se...@gmail.com wrote:

  Thanks, Tim. That is a clear and compelling reason to keep them there.
 
  With that clarified, does anyone have any comments on the renaming of the
  pages to improve the indexing?
 
  Best,
  Jim
 
 
  On Thu, Apr 9, 2015 at 11:16 AM, Timothy Bish tabish...@gmail.com
 wrote:
 
   On 04/09/2015 02:13 PM, Jim Gomes wrote:
Thanks for the explanation. That helps.
   
So, I guess we could discuss the merits of keeping the Board Reports
 on
   our
wiki, as it does seem somewhat redundant. As long as they exist on
 the
wiki, it would be helpful to have a better indexing system.
   
Perhaps Hiram can offer background as to the purpose and intent of
 the
Board Reports being published on the wiki?
   
Best,
Jim
   
   
   
On Thu, Apr 9, 2015 at 10:27 AM, Daniel Kulp dk...@apache.org
 wrote:
   
On Apr 9, 2015, at 1:02 PM, Jim Gomes jgo...@apache.org wrote:
   
Thanks for the link, Dan. I didn't know those were there. I think
 the
main
difference here is that link is to the Board Minutes, whereas the
ActiveMQ
wiki has the Board Report. They seem to be identical, but will they
always
be?
Possibly not, but it would NORMALLY be because the board has decided
something should be private (like names of people being voted on or
something) in which case it should likely not have been in our
 public
version as well.   Doesn't happen too often.  Also, they would
 remove
   any
wiki formatting type things that wouldn't look right in the text
  form
they use.
   
   
And even if they are identical, do we still need to have the
  redundancy
for trace-ability? For instance, if the Board, for whatever reason,
claims
they didn't receive the report, we have documentation on the wiki
   showing
the Report was produced.
I don't really think the board would care if one was produced or
 not.
 It's the chair's job to make sure the board gets the report.  If
 they
don't get it, they ask the chair to report again next month.   If
 the
   chair
consistently has issues, they'd likely replace the chair.Another
   thing
to keep in mind:  it's the Chairs job to create the report that
  reflects
the state of the community.  The chair MAY include the wider
 community
   in
creating that report, but that's not a requirement.   Thus, saying
  the
community produced one, the chair didn't submit it really wouldn't
   matter
at all.
   
Dan
   
   
That's me just trying to understand the reason for the Board Report
page's
existence.
   
-Jim
   
   
On Thu, Apr 9, 2015 at 9:53 AM, Daniel Kulp dk...@apache.org
  wrote:
   
No objection, but why don't we just delete the page and point at
  the
official records:
   
https://whimsy.apache.org/board/minutes/ActiveMQ.html
   
Dan
   
   
On Apr 9, 2015, at 12:35 PM, Jim Gomes jgo...@apache.org
 wrote:
   
I recently went out to look at previous Board Reports (
http://activemq.apache.org/apache-activemq-board-reports.html)
 and
found
the current sorting method difficult to deal with. Unless we are
required
to use the page naming format, I would like to change it to the
following
format:
   
Apache ActiveMQ Board Report - 2009.01 January
Apache ActiveMQ Board Report - 2009.04 April
Apache ActiveMQ Board Report - 2009.07 July
.
.
.
   
I would then set it to sort in reverse order so the most recent
   report
is
automatically at the top, and they descend in chronological
 order.
   The
current sorting puts the most recent board report (2015/02) in
 the
middle
of the pack, making it difficult to find. Good luck trying to
 find
   the
report directly prior to that.
   
I will make the changes, unless anyone has other suggestions.
   
Best,
Jim
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
   
   
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
   
   
   I believe that he does this as a place to create and edit them and
 allow
   for other members to contribute if they so desire before he submits
   them.  I've edited a couple in the past prior to submission to add CMS
   or NMS release notes.
  
   --
   Tim Bish
   Sr Software Engineer | RedHat Inc.
   tim.b...@redhat.com | www.redhat.com
   twitter: @tabish121
   blog: http://timbish.blogspot.com/
  
  
 

Re: [DISCUSS] Fix Sorting of Board Reports

[Jim Gomes]

Thanks for the link, Dan. I didn't know those were there. I think the main
difference here is that link is to the Board Minutes, whereas the ActiveMQ
wiki has the Board Report. They seem to be identical, but will they always
be? And even if they are identical, do we still need to have the redundancy
for trace-ability? For instance, if the Board, for whatever reason, claims
they didn't receive the report, we have documentation on the wiki showing
the Report was produced.

That's me just trying to understand the reason for the Board Report page's
existence.

-Jim


On Thu, Apr 9, 2015 at 9:53 AM, Daniel Kulp dk...@apache.org wrote:


 No objection, but why don't we just delete the page and point at the
 official records:

 https://whimsy.apache.org/board/minutes/ActiveMQ.html

 Dan


  On Apr 9, 2015, at 12:35 PM, Jim Gomes jgo...@apache.org wrote:
 
  I recently went out to look at previous Board Reports (
  http://activemq.apache.org/apache-activemq-board-reports.html) and found
  the current sorting method difficult to deal with. Unless we are required
  to use the page naming format, I would like to change it to the following
  format:
 
  Apache ActiveMQ Board Report - 2009.01 January
  Apache ActiveMQ Board Report - 2009.04 April
  Apache ActiveMQ Board Report - 2009.07 July
  .
  .
  .
 
  I would then set it to sort in reverse order so the most recent report is
  automatically at the top, and they descend in chronological order. The
  current sorting puts the most recent board report (2015/02) in the middle
  of the pack, making it difficult to find. Good luck trying to find the
  report directly prior to that.
 
  I will make the changes, unless anyone has other suggestions.
 
  Best,
  Jim

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

Re: [VOTE] HornetQ Code Donation should use a codename

[Jim Gomes]

+1
On Apr 9, 2015 7:25 AM, Clebert Suconic clebert.suco...@gmail.com wrote:

 +1


 On Thu, Apr 9, 2015 at 9:06 AM, Hiram Chirino hi...@hiramchirino.com
 wrote:
  Lots of confusion has occurred since we did not use a code name for
  the code donation from the start.  Everyone refers to it as HornetQ
  which adds to the Trademark confusions.  Also the current state of the
  code is not ready to become ActiveMQ 6.  We can figure out what the
  code name should be later with community and trademarks input.
 
  Please choose an option:
 
  [ ] +1 : Rename the hornetq code grant source code from ActiveMQ 6 to
  an ActiveMQ ${codename}
  [ ] -1 : No don't rename
  [ ] 0 : No preference
 
  Vote is open for 72 hours.
 
  --
  Hiram Chirino
  Engineering | Red Hat, Inc.
  hchir...@redhat.com | fusesource.com | redhat.com
  skype: hiramchirino | twitter: @hiramchirino



 --
 Clebert Suconic
 http://community.jboss.org/people/clebert.suco...@jboss.com
 http://clebertsuconic.blogspot.com

Re: [PROPOSAL] Pluggable Brokers...

[Jim Gomes]

I'm with Guillaume on this. From the NMS perspective, the broker already is
a plugin implementation. I don't understand why it would need to go any
deeper than that. NMS can talk to TIBCO or ActiveMQ brokers via one common
API. The idea of pluggable brokers already exists.

On Mon, Mar 30, 2015, 8:32 AM Guillaume Nodet gno...@apache.org wrote:

 Fwiw, the whole broker implementation looks like an implementation detail
 from a user point of view that uses the JMS spec... ;-)

 2015-03-30 17:12 GMT+02:00 Hadrian Zbarcea hzbar...@gmail.com:

  +1.
 
  The blocking today it merely an implementation detail than can be
  addressed.
 
  Hadrian
 
 
  On 03/30/2015 09:23 AM, James Carman wrote:
 
  All,
 
  With all the talk over the last week or so regarding the Broker
  Wars, especially after reading Rob Davies' email about how the broker
  has been tweaked through the years to emphasize different aspects
  (long-term storage for instance), it occurred to me that we might be
  able to move past all this craziness by providing an abstraction layer
  above the broker and try to make them pluggable.
 
  If there really are situations where the broker needs to focus on one
  particular aspect of message delivery, that sounds to me like the
  strategy pattern.  If a broker can be written in such a way that it
  is allowed to focus on certain aspects and maybe ignore or completely
  forego others, then it would seem to me that the code could be made
  much more straight-forward, because it doesn't have to try to be the
  swiss army knife, solving everyone's problems at one time.
 
  Of course, this may be just a pipe dream and there's no way to do it
  (admittedly I'm not terribly familiar with the code), but I thought
  I'd throw it out there as a possible approach.  I mean, we do this
  sort of thing already with the persistence providers, so maybe there's
  an opportunity here as well.
 
  Thoughts?
 
  James
 
 

Re: [PROPOSAL] Pluggable Brokers...

[Jim Gomes]

I guess if this would help the ActiveMQ developer by reducing code debt and
making maintenance simpler, it's a Good Thing. Pluggable architectures have
a certain amount of overhead, though.

I don't want to discourage interesting and new areas of architecture. The
original message said the pluggable interface would be above the broker,
not within it. That's what didn't make a lot of sense to me. If it's above
it, then the obvious plugin interface would be the existing wire protocols:
JMS via OpenWire or STOMP. If it's within the broker, where are the plugin
interface points? Is that what would need to be rearchitected, and is this
a significant amount of effort? I don't know enough of ActiveMQ's internals
to know where the boundaries are for clean separation.

On Wed, Apr 8, 2015, 12:15 AM James Carman ja...@carmanconsulting.com
wrote:

 Pluggable *within* ActiveMQ.  That is what doesn't exist.  The idea is that
 the underlying engine could be optimized on a case-by-case basis.  For
 instance, you may be able to streamline the implementation of a broker that
 doesn't require persistence at all.  Right now, we have one implementation
 that tries to be the end-all-be-all solution for everything.

 On Wednesday, April 8, 2015, Jim Gomes jgo...@apache.org wrote:

  I'm with Guillaume on this. From the NMS perspective, the broker already
 is
  a plugin implementation. I don't understand why it would need to go any
  deeper than that. NMS can talk to TIBCO or ActiveMQ brokers via one
 common
  API. The idea of pluggable brokers already exists.
 
  On Mon, Mar 30, 2015, 8:32 AM Guillaume Nodet gno...@apache.org
  javascript:; wrote:
 
   Fwiw, the whole broker implementation looks like an implementation
 detail
   from a user point of view that uses the JMS spec... ;-)
  
   2015-03-30 17:12 GMT+02:00 Hadrian Zbarcea hzbar...@gmail.com
  javascript:;:
  
+1.
   
The blocking today it merely an implementation detail than can be
addressed.
   
Hadrian
   
   
On 03/30/2015 09:23 AM, James Carman wrote:
   
All,
   
With all the talk over the last week or so regarding the Broker
Wars, especially after reading Rob Davies' email about how the
 broker
has been tweaked through the years to emphasize different aspects
(long-term storage for instance), it occurred to me that we might be
able to move past all this craziness by providing an abstraction
 layer
above the broker and try to make them pluggable.
   
If there really are situations where the broker needs to focus on
 one
particular aspect of message delivery, that sounds to me like the
strategy pattern.  If a broker can be written in such a way that
 it
is allowed to focus on certain aspects and maybe ignore or
 completely
forego others, then it would seem to me that the code could be made
much more straight-forward, because it doesn't have to try to be the
swiss army knife, solving everyone's problems at one time.
   
Of course, this may be just a pipe dream and there's no way to do it
(admittedly I'm not terribly familiar with the code), but I thought
I'd throw it out there as a possible approach.  I mean, we do this
sort of thing already with the persistence providers, so maybe
 there's
an opportunity here as well.
   
Thoughts?
   
James
   
   
  
 

Re: Naming Suggestions?

[Jim Gomes]

I vote for ActiveMQ-RS. Four reasons:

1. RS stands for Research.
2. RS is alphabetically sequential after Q, and it's fun to say.
3. Seriously doubt it'll clash with a trademarked name.
4. Fits with our other existing sub-project naming conventions
(ActiveMQ-NMS, ActiveMQ-CPP, etc.).
 On Apr 8, 2015 3:06 PM, Greg Stein gst...@gmail.com wrote:

 On Wed, Apr 08, 2015 at 05:34:37PM -0400, Daniel Kulp wrote:
 ...
  That said, since what we are talking about is a code name and not a
  name of a *Project* SHOULD be easier (but again, we'll verify with
  trademarks@ when we've decided on  name).   The name should always
  be referred to as Apache ActiveMQ-BLAH and never Apache BLAH or
  just BLAH.  The exception would be the normal dev chatter on our
  dev list.  This is just like the Apache ActiveMQ-NMS and Apache
  ActiveMQ-CMS we have now.

 Right. Since ActiveMQ will be in its release name, you've already
 got your trademark bits handled, and avoided conflict with anything
 else. Find a codename and move along. trademarks@ isn't really needed
 as long as it remains a sub-name of ActiveMQ. Chris is just reacting
 strongly because of the past use of HornetQ, which is RH's mark. That
 is past, so we can skip worrying about that.

 I look forward to your choices, and the Board report in a couple weeks.

 Cheers,
 -g

Re: [DISCUSS] dev mailing list is cluttered

[Jim Gomes]

I'm OK with moving JIRA notices to a separate list.

On Tue, Apr 7, 2015, 1:22 PM Hiram Chirino hi...@hiramchirino.com wrote:

 Do we need an official vote thread for these kinds of changes?
 Perhaps this discussion thread is good enough?

 On Tue, Apr 7, 2015 at 3:14 PM, James Carman ja...@carmanconsulting.com
 wrote:
  I think we need to have Hiram request this since he is the chair of the
 PMC.
 
  On Tuesday, April 7, 2015, James Carman ja...@carmanconsulting.com
 wrote:
 
  Actually the mailing lists are different
 
  https://infra.apache.org/officers/mlreq
 
 
  On Tuesday, April 7, 2015, Bruce Snyder bruce.sny...@gmail.com
  javascript:_e(%7B%7D,'cvml','bruce.sny...@gmail.com'); wrote:
 
  Anything that requires assistance from the Infra team is accomplished
 by
  creating a JIRA issue. Just create a new issue in JIRA (
  https://issues.apache.org/jira/secure/Dashboard.jspa) and select the
  Infrastructure project.
 
  Bruce
 
  On Tue, Apr 7, 2015 at 12:36 PM, artnaseef a...@artnaseef.com wrote:
 
   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.
  
 
 
 
  --
  perl -e 'print
  unpack(u30,D0G)U8V4\@4VYY95R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT*
 );'
 
  ActiveMQ in Action: http://bit.ly/2je6cQ
  Blog: http://bruceblog.org/
  Twitter: http://twitter.com/brucesnyder
 
 



 --
 Hiram Chirino
 Engineering | Red Hat, Inc.
 hchir...@redhat.com | fusesource.com | redhat.com
 skype: hiramchirino | twitter: @hiramchirino

Re: [DISCUSS] dev mailing list is cluttered

[Jim Gomes]

+1 for lazy consensus.

On Tue, Apr 7, 2015, 1:44 PM James Carman ja...@carmanconsulting.com
wrote:

 Sounds good.  There's no reason to rush this by any stretch of the
 imagination.  Lazy consensus is just fine for this sort of thing, I'd
 think.


 On Tue, Apr 7, 2015 at 4:36 PM, Hiram Chirino hi...@hiramchirino.com
 wrote:
  How about this.. Lets request the change 72 hours after this thread
  was started. So 3 days - 5 hours :)  That way, we lets folks in
  different time zones get a chance to object if they want.  After that
  we can call it lazy consensus and be done with it.
 
  On Tue, Apr 7, 2015 at 4:30 PM, Bruce Snyder bruce.sny...@gmail.com
 wrote:
  I don't think we need a vote, but I won't stand in the way of one.
 
  Bruce
 
  On Tue, Apr 7, 2015 at 2:26 PM, James Carman 
 ja...@carmanconsulting.com
  wrote:
 
  Unless anyone objects, I don't think we need an official VOTE.  Thus
  far, it appears we have consensus.  Anyone?  Anyone?  Bueller?
 
  On Tue, Apr 7, 2015 at 4:21 PM, Hiram Chirino hi...@hiramchirino.com
  wrote:
   Do we need an official vote thread for these kinds of changes?
   Perhaps this discussion thread is good enough?
  
   On Tue, Apr 7, 2015 at 3:14 PM, James Carman 
 ja...@carmanconsulting.com
  wrote:
   I think we need to have Hiram request this since he is the chair of
 the
  PMC.
  
   On Tuesday, April 7, 2015, James Carman ja...@carmanconsulting.com
 
  wrote:
  
   Actually the mailing lists are different
  
   https://infra.apache.org/officers/mlreq
  
  
   On Tuesday, April 7, 2015, Bruce Snyder bruce.sny...@gmail.com
   javascript:_e(%7B%7D,'cvml','bruce.sny...@gmail.com'); wrote:
  
   Anything that requires assistance from the Infra team is
 accomplished
  by
   creating a JIRA issue. Just create a new issue in JIRA (
   https://issues.apache.org/jira/secure/Dashboard.jspa) and select
 the
   Infrastructure project.
  
   Bruce
  
   On Tue, Apr 7, 2015 at 12:36 PM, artnaseef a...@artnaseef.com
 wrote:
  
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.
   
  
  
  
   --
   perl -e 'print
   unpack(u30,D0G)U8V4\@4VYY95R\F)R=6-E+G-N61ED\!G;6%I;\
 YC;VT*
  );'
  
   ActiveMQ in Action: http://bit.ly/2je6cQ
   Blog: http://bruceblog.org/
   Twitter: http://twitter.com/brucesnyder
  
  
  
  
  
   --
   Hiram Chirino
   Engineering | Red Hat, Inc.
   hchir...@redhat.com | fusesource.com | redhat.com
   skype: hiramchirino | twitter: @hiramchirino
 
 
 
 
  --
  perl -e 'print
  unpack(u30,D0G)U8V4\@4VYY95R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT*
 );'
 
  ActiveMQ in Action: http://bit.ly/2je6cQ
  Blog: http://bruceblog.org/
  Twitter: http://twitter.com/brucesnyder
 
 
 
  --
  Hiram Chirino
  Engineering | Red Hat, Inc.
  hchir...@redhat.com | fusesource.com | redhat.com
  skype: hiramchirino | twitter: @hiramchirino

Re: [VOTE] Apache ActiveMQ 5.11.0 (rc3)

[Jim Gomes]

+1

On Mon, Feb 2, 2015, 8:11 AM Hadrian Zbarcea hzbar...@gmail.com wrote:

 +1 (binding)

 * Sigs ok
 * Legal ok (almost)
- a bunch of Copyright notices pointing to 2014 or 2013 (need to
 cleanup)
 * Builds from source ok (almost)

 There is one consistent failure in activemq-karaf-itest, however test
 does pass when ran individually. No product defect, but should be
 addressed.
 ActiveMQAMQPBrokerFeatureTestActiveMQBrokerFeatureTest.test:66-
 AbstractJmsFeatureTest.produceMessage:67-getConnection:53
 » ClassNotFound


 All in all, quite impressive. Very solid release, awesome work.

 Thanks Gary,
 Hadrian


 On 01/30/2015 09:00 AM, Gary Tully wrote:
  Hi folks,
 
  I've just cut a third release candidate for the long-awaited 5.11.0
 release.
  This release has more than 120 bug fixes and improvements.
 
  -note-
  this candidate includes the fix for the 'reliably' broken test case from
 rc2
  however there can be no expectation of a 'reliable' full test run from
  mvn install.
  I have raised https://issues.apache.org/jira/browse/AMQ-5552 to address
 that.
  I think a resolution to that issue would address all of the
  disapproving commentary on the rc2 vote. If you voted -1 last time
  round, please chime in on AMQ-5552.
  -end note-
 
  Could you please review the artifacts and vote?
 
  The list of resolved issues is here:
  https://issues.apache.org/jira/secure/ReleaseNote.jspa?
 projectId=12311210version=12324951
 
  You can get binary distributions here:
  https://repository.apache.org/content/repositories/
 orgapacheactivemq-1016/org/apache/activemq/apache-activemq/5.11.0/
 
  Source archives are here:
  https://repository.apache.org/content/repositories/
 orgapacheactivemq-1016/org/apache/activemq/activemq-parent/5.11.0/
 
  Maven2 repository is at:
  https://repository.apache.org/content/repositories/
 orgapacheactivemq-1016/
 
  Source tag:
  https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=
 66bd5da9405765ddbc950b4f1c5a6ef6195207e5
 
  The vote will remain open for 72 hours.
 
  [ ] +1  approve the release as Apache ActiveMQ 5.11.0
  [ ] +0  no opinion
  [ ] -1  disapprove (and reason why)
 
 
  Here's my +1
 
  Regards,
  Gary.

Re: {VOTE] Release Apache.NMS.ActiveMQ 1.6.5

[Jim Gomes]

+1

On Mon, Feb 2, 2015, 8:33 AM Timothy Bish tabish...@gmail.com wrote:

 Hello

 This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.6.5

 This is a small bugfix release that addresses an issue in the OpenWire
 support around tight marshalling of data.  Also a fix for message
 consumers that can wrongly mark messages as redelivered was added.

 The binaries and source bundles for the Release Candidate can be found
 here:
 http://people.apache.org/~tabish/nms-1.6.0

 The Wiki Page for this release is here:
 http://activemq.apache.org/nms/apachenmsactivemq-v165.html

 The list of issues resolved is here:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?
 projectId=12311201version=12329150

 Please cast your votes (the vote will be open for 72 hrs):

 [ ] +1 Release the source as Apache NMS.ActiveMQ v1.6.5
 [ ] -1 (provide specific comments)

 Here's my +1

 --
 Tim Bish
 Sr Software Engineer | RedHat Inc.
 tim.b...@redhat.com | www.redhat.com
 skype: tabish121 | twitter: @tabish121
 blog: http://timbish.blogspot.com/

Re: [VOTE] Apache ActiveMQ 5.11.0 (rc3)

[Jim Gomes]

+1

On Fri, Jan 30, 2015, 10:34 PM Claus Ibsen claus.ib...@gmail.com wrote:

 Hi

 +1

 Tested against Camel in Action source code also.

 On Fri, Jan 30, 2015 at 3:00 PM, Gary Tully gary.tu...@gmail.com wrote:
  Hi folks,
 
  I've just cut a third release candidate for the long-awaited 5.11.0
 release.
  This release has more than 120 bug fixes and improvements.
 
  -note-
  this candidate includes the fix for the 'reliably' broken test case from
 rc2
  however there can be no expectation of a 'reliable' full test run from
  mvn install.
  I have raised https://issues.apache.org/jira/browse/AMQ-5552 to address
 that.
  I think a resolution to that issue would address all of the
  disapproving commentary on the rc2 vote. If you voted -1 last time
  round, please chime in on AMQ-5552.
  -end note-
 
  Could you please review the artifacts and vote?
 
  The list of resolved issues is here:
  https://issues.apache.org/jira/secure/ReleaseNote.jspa?
 projectId=12311210version=12324951
 
  You can get binary distributions here:
  https://repository.apache.org/content/repositories/
 orgapacheactivemq-1016/org/apache/activemq/apache-activemq/5.11.0/
 
  Source archives are here:
  https://repository.apache.org/content/repositories/
 orgapacheactivemq-1016/org/apache/activemq/activemq-parent/5.11.0/
 
  Maven2 repository is at:
  https://repository.apache.org/content/repositories/
 orgapacheactivemq-1016/
 
  Source tag:
  https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=
 66bd5da9405765ddbc950b4f1c5a6ef6195207e5
 
  The vote will remain open for 72 hours.
 
  [ ] +1  approve the release as Apache ActiveMQ 5.11.0
  [ ] +0  no opinion
  [ ] -1  disapprove (and reason why)
 
 
  Here's my +1
 
  Regards,
  Gary.



 --
 Claus Ibsen
 -
 Red Hat, Inc.
 Email: cib...@redhat.com
 Twitter: davsclaus
 Blog: http://davsclaus.com
 Author of Camel in Action: http://www.manning.com/ibsen
 hawtio: http://hawt.io/
 fabric8 http://hawt.io/fabric8: http://fabric8.io/

Re: [DISCUSS] Have every committer on the PMC by default

[Jim Gomes]

I don't think every committer should be on the PMC by default. Not all may
want that responsibility, and may not be ready for it, either. Lowering the
bar to entry may be useful, but this seems too low.

On Thu, Jan 29, 2015, 7:36 AM Hadrian Zbarcea hzbar...@gmail.com wrote:

 They can indicate the same by doing whatever they want to do, nobody
 stops them to self elect and do whatever they like, scratch an itch.
 They prove that they understand the ASF values and they get voted in. I
 am not ok with providing blanket binding votes in this community where
 proper mentorship has been a problem. I do encourage however any
 committer to be proactive and do all the management he's interested in.
 I encourage any contributor to keep contributing, improve their skills,
 and *their* project (activemq) and become, if they want, committers
 (speaking of which, doesn't necessarily need to be only code, I got a
 lot of complaints lately about documentation). They all got my full
 support.

 -1 (binding)
 Hadrian



 On 01/29/2015 08:42 AM, Gary Tully wrote:
  In that way, committers that are interested in project management
  duties can indicate same with their votes. Effectively self elect to
  step up to the task.
 
  What is the down side?

Re: [VOTE] Apache ActiveMQ 5.11.0

[Jim Gomes]

+1

On Mon, Jan 26, 2015, 1:03 PM Gary Tully gary.tu...@gmail.com wrote:

 Hi folks,

 I've just cut a second release candidate for the long-awaited 5.11.0
 release.
 This release has more than 120 bug fixes and improvements.

 Could you review the artifacts and vote? Especially, it would be great if
 you could test the unix shell script and make sure there's no any
 regressions
 on the platform you're using.

 The list of resolved issues is here:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?
 projectId=12311210version=12324951

 You can get binary distributions here:
 https://repository.apache.org/content/repositories/
 orgapacheactivemq-1014/org/apache/activemq/apache-activemq/5.11.0/

 Source archives are here:
 https://repository.apache.org/content/repositories/
 orgapacheactivemq-1014/org/apache/activemq/activemq-parent/5.11.0/

 Maven2 repository is at:
 https://repository.apache.org/content/repositories/orgapacheactivemq-1014/

 Source tag:
 https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=
 f6eb86ee31640427d0f953847f38fcf81a71f9e1

 The vote will remain open for 72 hours.

 [ ] +1 Release the binary as Apache ActiveMQ 5.11.0
 [ ] -1 Veto the release (provide specific comments)

 Here's my +1

 Regards

 Gary

Re: [VOTE] Release Apache ActiveMQ 5.10.1 (3rd attempt)

[Jim Gomes]

+1

On Thu, Jan 15, 2015, 11:04 PM Claus Ibsen claus.ib...@gmail.com wrote:

 Hi

 I gave the RC a test spin with latest Camel source code.
 And the spring XSD schema 5.10.1 is included.

 +1




 On Thu, Jan 15, 2015 at 6:10 PM, artnaseef a...@artnaseef.com wrote:
  The release candidate for the activemq 5.10.1 release is now built and
 ready
  for a vote.
  This release comes with 34 fixes and 1 administrative jira entry.
 
  Please see the list of jira entries here:
  https://issues.apache.org/jira/issues/?jql=fixVersion%
 20%3D%205.10.1%20AND%20project%20%3D%20AMQ
 
 
  You can get binary distributions here:
  https://repository.apache.org/content/repositories/
 orgapacheactivemq-1013/org/apache/activemq/apache-activemq/5.10.1/
 
 
  Source archives are here:
  https://repository.apache.org/content/repositories/
 orgapacheactivemq-1013/org/apache/activemq/activemq-parent/5.10.1/
 
 
  Maven2 repository is here:
  https://repository.apache.org/content/repositories/
 orgapacheactivemq-1013/
 
  Source tag:
  https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=
 8938d14d434447193b02ba635606aa0fb7a80353
 
 
  NOTE: I used Hadrian's prior thread as a template (thank you Hadrian).
 
 
 
  --
  View this message in context: http://activemq.2283324.n4.
 nabble.com/VOTE-Release-Apache-ActiveMQ-5-10-1-3rd-attempt-tp4689959.html
  Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



 --
 Claus Ibsen
 -
 Red Hat, Inc.
 Email: cib...@redhat.com
 Twitter: davsclaus
 Blog: http://davsclaus.com
 Author of Camel in Action: http://www.manning.com/ibsen
 hawtio: http://hawt.io/
 fabric8 http://hawt.io/fabric8: http://fabric8.io/

Re: {VOTE] Release Apache.NMS.ActiveMQ 1.7.0

[Jim Gomes]

+1

On Mon, Jan 12, 2015, 6:47 AM Timothy Bish tabish...@gmail.com wrote:

 Hello

 This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.7.0

 This is first release of the Apache.NMS.ActiveMQ v1.7.x line.  This
 release incorporates many fixes and improvements along with updates to
 the .NET compression library used to resolve some edge cases that can
 occur if a message compresses to a specific size and compliance with the
 v1.7.0 NMS API has been added.

 The binaries and source bundles for the Release Candidate can be found
 here:
 http://people.apache.org/~tabish/nms-1.7.x

 The Wiki Page for this release is here:
 http://activemq.apache.org/nms/apachenmsactivemq-v170.html

 The list of issues resolved is here:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?
 projectId=12311201version=12325350

 Please cast your votes (the vote will be open for 72 hrs):

 [ ] +1 Release the source as Apache NMS.ActiveMQ v1.7.0
 [ ] -1 (provide specific comments)

 Here's my +1

 --
 Tim Bish
 Sr Software Engineer | RedHat Inc.
 tim.b...@redhat.com | www.redhat.com
 skype: tabish121 | twitter: @tabish121
 blog: http://timbish.blogspot.com/

Re: [DISCUSS] Renaming trunk to master

[Jim Gomes]

I don't really know the conventions of git, but are the branches still
called branches, or are they servants? Trunk/branches is a consistent
metaphor. Master/branches is mixing metaphors.

On Mon, Jan 5, 2015, 1:52 PM Timothy Bish tabish...@gmail.com wrote:

 +1

 On 01/05/2015 01:27 PM, Hadrian Zbarcea wrote:
  It's a bit confusing, a leftover from the svn days.
 
  I think the rename was supposed to happen but it was somehow
  overlooked. Any objection to rename?
 
  Hadrian
 


 --
 Tim Bish
 Sr Software Engineer | RedHat Inc.
 tim.b...@redhat.com | www.redhat.com
 skype: tabish121 | twitter: @tabish121
 blog: http://timbish.blogspot.com/

Re: [VOTE] Release Apache.NMS API 1.7.0

[Jim Gomes]

+1

On Mon, Jan 5, 2015, 7:00 AM Timothy Bish tabish...@gmail.com wrote:

 Hello

 This is a call for a vote on the release of the Apache.NMS API v1.7.0.
 This package contains the API for the various Apache.NMS client along
 with utility classes and unit test cases against the abstract NMS API.

 This version of the API will be the basis for the next set of NMS client
 releases including Apache.NMS.ActiveMQ and Apache.NMS.Stomp etc.

 Changes in this version include:

 * Added IDisposable as a base of IDestination.
 * Added some improvements to the Unit tests framework.
 * Added some new provider names (AMQP and MQTT) to allow for future
 clients.

 The binaries and source bundles for the Release Candidate can be found
 here:
 [ http://people.apache.org/~tabish/nms-1.7.x ]

 The Wiki Page for this release is here:
 [ http://activemq.apache.org/nms/apachenms-api-v170.html ]

 Please cast your votes (the vote will be open for 72 hrs):

 [ ] +1 Release the source as Apache NMS API 1.7.0
 [ ] -1 (provide specific comments)

 Here's my +1

 Regards,
 Tim

 --
 Tim Bish
 Sr Software Engineer | RedHat Inc.
 tim.b...@redhat.com | www.redhat.com
 skype: tabish121 | twitter: @tabish121
 blog: http://timbish.blogspot.com/

Re: [VOTE] Accept hornetq code grant and active committers

[Jim Gomes]

+1

On Wed, Sep 24, 2014 at 8:44 AM, Gary Tully gary.tu...@gmail.com wrote:

 we need to formally vote to:

 1)  accept the code grant from RedHat for hornetq[1]
 2)  invite the active core committers (Clebert Suconic, Andy Taylor, Justin
 Bertram, Youg Hao Gao, Martyn Taylor) from hornetq to become activemq
 committers.

 For background, the dev thread with the original discussion is at [2]

 Please vote, adoption by lazy consensus is acceptable but not recommended.

 [ ] +1 - Accept hornetq code grant and new active committers
 [ ] -1 -  Don't accept the code grant and/or new activemq committers
 because

 This vote will be open for 72 hours.

 here is my +1

 Thank you,
 Gary.

 [1] http://incubator.apache.org/ip-clearance/hornetq.html
 [2] http://mail-archives.apache.org/mod_mbox/activemq-dev/201407.mbox/%
 3ccakf+bsovr7hvn-rmykb3pf6hogjx7nujwzt_nh8myc4usrb...@mail.gmail.com%3E

Re: {VOTE] Release Apache.NMS.ActiveMQ 1.6.4

[Jim Gomes]

+1

On Mon, Sep 8, 2014 at 7:43 AM, Timothy Bish tabish...@gmail.com wrote:

 Hello

 This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.6.4

 This is a bug fix only release focusing on some issues with Consumers in
 local transacted sessions where messages were getting marked as duplicates
 in error after failover and some other edge cases that could lead to a
 missed redelivery.

 The binaries and source bundles for the Release Candidate can be found
 here:
 http://people.apache.org/~tabish/nms-1.6.0

 The Wiki Page for this release is here:
 http://activemq.apache.org/nms/apachenmsactivemq-v164.html

 The list of issues resolved is here:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?
 projectId=12311201version=12327446

 Please cast your votes (the vote will be open for 72 hrs):

 [ ] +1 Release the source as Apache NMS.ActiveMQ v1.6.4
 [ ] -1 Veto the release (provide specific comments)

 Here's my +1

 Regards

 --
 Tim Bish
 Sr Software Engineer | RedHat Inc.
 tim.b...@redhat.com | www.redhat.com
 skype: tabish121 | twitter: @tabish121
 blog: http://timbish.blogspot.com/

[jira] [Commented] (AMQNET-454) Add Apache Qpid provider to NMS

[Jim Gomes (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQNET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14104564#comment-14104564
 ] 

Jim Gomes commented on AMQNET-454:
--

Hi Chuck,
That's fantastic! I added the default provider mapping to the 
NMSConnectionFactory.  I'm excited to see this new provider implementation 
become part of the product.

 Add Apache Qpid provider to NMS
 ---

 Key: AMQNET-454
 URL: https://issues.apache.org/jira/browse/AMQNET-454
 Project: ActiveMQ .Net
  Issue Type: New Feature
  Components: NMS
Affects Versions: 1.6.0
Reporter: Chuck Rolke
Assignee: Jim Gomes
 Attachments: Apache.NMS.AMQP-21-Add-Map-Text-Message-tests.patch, 
 Apache.NMS.AMQP-22-add-more-tests.patch, 
 Apache.NMS.AMQP-23a-MessageDeliveryTest.cs.patch, 
 Apache.NMS.AMQP-23b-MSConnectionFactoryTest.cs.patch, 
 Apache.NMS.AMQP-23c-NmsConsoleTracer.cs.patch, 
 Apache.NMS.AMQP-23d-addTraceStatements.patch, 
 Apache.NMS.AMQP-23e-addFilesToTestProject.patch, 
 Apache.NMS.AMQP-24-tidy-up.patch, Apache.NMS.AMQP-25-use-qpid-0.28.patch, 
 Apache.NMS.AMQP-26-hook-in-session-ack.patch, 
 Apache.NMS.AMQP-27-nant-unmanaged-copy.patch, 
 Apache.NMS.AMQP-28-close-qpid-sender-receiver.patch, 
 Apache.NMS.AMQP-29-stop-sessions-before-connection.patch, 
 Apache.NMS.AMQP-30-lock-x86-only.patch, 
 Apache.NMS.AMQP-Add-message-cloning-19.patch, 
 Apache.NMS.AMQP-add-connection-property-table-17.patch, 
 Apache.NMS.AMQP-add-hello-world-example-11.patch, 
 Apache.NMS.AMQP-add-hello-world-example-retry-12.patch, 
 Apache.NMS.AMQP-add-hello-world-to-vs2008-18.patch, 
 Apache.NMS.AMQP-add-message-conversions-06.patch, 
 Apache.NMS.AMQP-add-message-test-20.patch, 
 Apache.NMS.AMQP-add-topic-05.patch, 
 Apache.NMS.AMQP-connectionProperties-07.patch, 
 Apache.NMS.AMQP-copyrights-conn-str-fix-09.patch, 
 Apache.NMS.AMQP-fix-destination-to-use-qpid-address-10.patch, 
 Apache.NMS.AMQP-fix-helloworld-13.patch, 
 Apache.NMS.AMQP-fix-list-message-body-15.patch, 
 Apache.NMS.AMQP-fix-map-message-body-14.patch, 
 Apache.NMS.AMQP-fix-replyTo-and-receive-timeouts-16.patch, 
 Apache.NMS.AMQP-object-lifecycle-04.patch, 
 Apache.NMS.AMQP-provider-configs-03.patch, 
 Apache.NMS.AMQP-qpid-object-lifecycle-02.patch, 
 Apache.NMS.AMQP-set-connection-credentials-08.patch, RELEASE.txt, 
 vendor-Apache.QPID-00-replace-debug-with-release.patch, 
 vendor-QPid-nant-01.patch


 NMS includes various providers ActiveMQ, STOMP, MSMQ, EMS, and WCF. This 
 issue proposes to add [Apache Qpid|http://qpid.apache.org/index.html] as 
 another provider.
 Qpid has a [Messaging .NET 
 Binding|http://qpid.apache.org/releases/qpid-0.24/programming/book/ch05.html] 
 that is layered on top of the native C++ Qpid Messaging client. The Qpid .NET 
 binding is attractive as the hook for tying in Qpid as an NMS provider.
 The proposed NMS provider supports [AMQP 
 1.0|http://qpid.apache.org/amqp.html] by including [Qpid 
 Proton|http://qpid.apache.org/proton/index.html] libraries.
 From a high level this addition to Active.NMS would consist of two parts
 * Add Qpid as a vendor kit. This includes both the Qpid .NET Binding and Qpid 
 Proton in a single kit.
 * Add the new provider with code linking NMS to Qpid



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQNET-454) Add Apache Qpid provider to NMS

[Jim Gomes (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQNET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102830#comment-14102830
 ] 

Jim Gomes commented on AMQNET-454:
--

Chuck, I'll move the release DLLs into a single folder, and patch up the build 
script. It'll probably be easier that way.

I wish there were an easier way to handle these external dependencies. We have 
an internal tool that I've written that would solve this problem easily.  
Unfortunately, it's a Windows only solution (PowerShell), and would not be 
realistic for others to use. Maybe one of these days, I'll port it to Python 
and release it as open source.

 Add Apache Qpid provider to NMS
 ---

 Key: AMQNET-454
 URL: https://issues.apache.org/jira/browse/AMQNET-454
 Project: ActiveMQ .Net
  Issue Type: New Feature
  Components: NMS
Affects Versions: 1.6.0
Reporter: Chuck Rolke
Assignee: Jim Gomes
 Attachments: Apache.NMS.AMQP-21-Add-Map-Text-Message-tests.patch, 
 Apache.NMS.AMQP-22-add-more-tests.patch, 
 Apache.NMS.AMQP-23a-MessageDeliveryTest.cs.patch, 
 Apache.NMS.AMQP-23b-MSConnectionFactoryTest.cs.patch, 
 Apache.NMS.AMQP-23c-NmsConsoleTracer.cs.patch, 
 Apache.NMS.AMQP-23d-addTraceStatements.patch, 
 Apache.NMS.AMQP-23e-addFilesToTestProject.patch, 
 Apache.NMS.AMQP-24-tidy-up.patch, Apache.NMS.AMQP-25-use-qpid-0.28.patch, 
 Apache.NMS.AMQP-26-hook-in-session-ack.patch, 
 Apache.NMS.AMQP-27-nant-unmanaged-copy.patch, 
 Apache.NMS.AMQP-28-close-qpid-sender-receiver.patch, 
 Apache.NMS.AMQP-29-stop-sessions-before-connection.patch, 
 Apache.NMS.AMQP-30-lock-x86-only.patch, 
 Apache.NMS.AMQP-Add-message-cloning-19.patch, 
 Apache.NMS.AMQP-add-connection-property-table-17.patch, 
 Apache.NMS.AMQP-add-hello-world-example-11.patch, 
 Apache.NMS.AMQP-add-hello-world-example-retry-12.patch, 
 Apache.NMS.AMQP-add-hello-world-to-vs2008-18.patch, 
 Apache.NMS.AMQP-add-message-conversions-06.patch, 
 Apache.NMS.AMQP-add-message-test-20.patch, 
 Apache.NMS.AMQP-add-topic-05.patch, 
 Apache.NMS.AMQP-connectionProperties-07.patch, 
 Apache.NMS.AMQP-copyrights-conn-str-fix-09.patch, 
 Apache.NMS.AMQP-fix-destination-to-use-qpid-address-10.patch, 
 Apache.NMS.AMQP-fix-helloworld-13.patch, 
 Apache.NMS.AMQP-fix-list-message-body-15.patch, 
 Apache.NMS.AMQP-fix-map-message-body-14.patch, 
 Apache.NMS.AMQP-fix-replyTo-and-receive-timeouts-16.patch, 
 Apache.NMS.AMQP-object-lifecycle-04.patch, 
 Apache.NMS.AMQP-provider-configs-03.patch, 
 Apache.NMS.AMQP-qpid-object-lifecycle-02.patch, 
 Apache.NMS.AMQP-set-connection-credentials-08.patch, RELEASE.txt, 
 vendor-Apache.QPID-00-replace-debug-with-release.patch, 
 vendor-QPid-nant-01.patch


 NMS includes various providers ActiveMQ, STOMP, MSMQ, EMS, and WCF. This 
 issue proposes to add [Apache Qpid|http://qpid.apache.org/index.html] as 
 another provider.
 Qpid has a [Messaging .NET 
 Binding|http://qpid.apache.org/releases/qpid-0.24/programming/book/ch05.html] 
 that is layered on top of the native C++ Qpid Messaging client. The Qpid .NET 
 binding is attractive as the hook for tying in Qpid as an NMS provider.
 The proposed NMS provider supports [AMQP 
 1.0|http://qpid.apache.org/amqp.html] by including [Qpid 
 Proton|http://qpid.apache.org/proton/index.html] libraries.
 From a high level this addition to Active.NMS would consist of two parts
 * Add Qpid as a vendor kit. This includes both the Qpid .NET Binding and Qpid 
 Proton in a single kit.
 * Add the new provider with code linking NMS to Qpid



--
This message was sent by Atlassian JIRA
(v6.2#6252)