activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <jbert...@apache.com>
Subject Re: [DISCUSS] ActiveMQ utility project name
Date Thu, 02 Feb 2017 14:28:08 GMT
> For large stores I think we will need to do something here in terms of compression otherwise
we could end up with huge XML files.

What specifically are your concerns and ideas here?  Storage appears cheap and plentiful and
files can be compressed after they are created with gzip or similar.  Also, huge message stores
are (IMO) an anti-pattern.  A message broker is not a database after all.  What use-cases
do you have in mind?


Justin

----- Original Message -----
From: "Christopher Shannon" <christopher.l.shannon@gmail.com>
To: dev@activemq.apache.org
Sent: Thursday, February 2, 2017 5:49:22 AM
Subject: Re: [DISCUSS] ActiveMQ utility project name

Based on the feedback I think we can keep the scope of the project just to
command line tools and call it activemq-cli-tools so I will go ahead and
request that repository get created for us.  I agree that for shared
libraries or other stuff we can discuss more if we want to create other
repositories for that.

In terms of KahaDB being exported to Artemis, I think exporting to the XML
format that Artemis already uses for importing should be the first version
of this.  It should be straight forward to write some code to iterate over
a KahaDB store and write out the messages to XML.  For large stores I think
we will need to do something here in terms of compression otherwise we
could end up with huge XML files.  In future versions it might also be nice
to be able to convert directly to an Artemis store and not need the XML
middle step.

On Thu, Feb 2, 2017 at 5:54 AM, Robbie Gemmell <robbie.gemmell@gmail.com>
wrote:

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

Mime
View raw message