AMQP 1.0 with transactional retirement would partly support my requirements but I still need the keys as I don’t want to load the complete queue. Also, transactional retirement associates a message outcome (settled/rejected) with a tx. Since this is built on top of the Core API, there must be some key/outcome pair that identifies the message.
Or am I wrong? > Am 08.01.2019 um 21:23 schrieb Clebert Suconic <[email protected]>: > > 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> 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 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.
