Perhaps what Andreas is looking is different. Supporting his API
(Streams) on top of the broker, and instead of using internal APIs
using an established API?
The current contract we have on the broker is based on the messages
where you can call message.individualAck or message.ack (The protocol
layers are using this call).
I would think all you need is to find a way to locate a message with a
given ID for plugin your API?
On Tue, Jan 8, 2019 at 1:32 PM Arthur Naseef <a...@amlinv.com> wrote:
>
> I agree. Messaging and Database patterns are very different, with
> different optimizations and considerations.
>
> That's why folks often hear me repeat a part of a Jeff Genender's
> presentation - "don't use ActiveMQ as a message store".
>
> Messaging is about moving messages as quickly as possible between
> endpoints. Databases, on the other hand, are oriented to solve "source of
> truth" problems. One example of where this becomes clear - ActiveMQ has
> almost no means to randomly access messages, and those means that exist are
> not good for production - they are only useful for testing and maybe
> diagnostic purposes.
>
> While it could be desirable from an application perspective to simplify the
> application, having messages stored for long periods of time in messaging
> middleware, that's not how ActiveMQ (or other messaging middleware) are
> oriented.
>
> With all of that said, I am curious to know what motivations exist to drive
> this request.
>
> Hope this helps.
>
> Art
>
>
>
>
> On Tue, Jan 8, 2019 at 10:23 AM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > Random access queues don't make sense for a message broker and is not
> > supported. Based on your use case Artemis or any message broker does not
> > sound like the correct product.
> >
> > It sounds like you need something like one of the many key/value stores
> > that exist. (you can search around and see what's out there)
> >
> > On Tue, Jan 8, 2019 at 7:17 AM Andreas Mueller <a...@iit.de> wrote:
> >
> > > Hi,
> > >
> > > we have a sub project that currently runs within SwiftMQ as a plugin and
> > > uses SwiftMQ’s Swiftlet API to communicate with the internal components.
> > > I’m currently evaluating to port it to Artemis where it should run as a
> > > broker plugin. If that is possible with reasonable effort, we intend to
> > > make this sub project available as open source.
> > >
> > > This library uses queues as kind of database. We do not want to use a
> > real
> > > database such as JDBC for it because we want it completely broker centric
> > > without dependencies and we want it transactional consistent, e.g. when a
> > > HA broker fails over, the data should be transactional save at the new HA
> > > instance.
> > >
> > > To accomplish this, we need random access to queues as specified in this
> > > little interface:
> > >
> > > public interface RandomAccessQueue {
> > > /**
> > > * Returns keys of all messages in this queue.
> > > * @return List of keys
> > > */
> > > List<Object> getKeys();
> > >
> > > /**
> > > * Returns a message by its key. The message is not locked.
> > > * @param key
> > > * @return Message
> > > */
> > > Message getMessageByKey(Object key);
> > >
> > > /**
> > > * Locks all messages for removal by their key
> > > * @param txid Transaction id
> > > * @param keys List of keys
> > > */
> > > void lockForRemoval(Object txid, List<Object> keys);
> > >
> > > /**
> > > * Commits a transaction. Removes all messages that are locked in
> > this
> > > transaction id.
> > > * @param txid Transaction id
> > > */
> > > void commit(Object txid);
> > >
> > > /**
> > > * Aborts a transaction. All messages locked for this transaction are
> > > simply unlocked.
> > > * @param txid Transaction id
> > > */
> > > void abort(Object txid);
> > > }
> > >
> > > I’ve walked through the Artemis docs but did not find a way to do this.
> > >
> > > Can anyone tell me if that is possible? If yes, what are the implications
> > > in terms of performance if I get a message from an arbitrary position of
> > > the queue and remove it? I want to avoid a full scan of the transaction
> > > log, for example.
> > >
> > > Thanks!
> > >
> > > Regards,
> > > Andreas
> > >
> > > --
> > > Andreas Mueller
> > > IIT Software GmbH
> > > http://www.swiftmq.com
> > >
> > >
> > >
> > >
> > >
> > > IIT Software GmbH
> > > Falkenhorst 11, 48155 Münster, Germany
> > > Phone: +49 (0)251 39 72 99 00
> > > Managing Director: Andreas Müller
> > > District Court: Amtsgericht Münster, HRB 16294
> > > VAT-No: DE199945912
> > >
> > > This e-mail may contain confidential and/or privileged information. If
> > you
> > > are not the intended recipient (or have received this e-mail in error)
> > > please notify the sender immediately and destroy this e-mail. Any
> > > unauthorized copying, disclosure or distribution of the material in this
> > > e-mail is strictly forbidden.
> > >
> > >
> >
--
Clebert Suconic
