On Mon, 9 Mar 2020 at 09:36, VERMEULEN Olivier <[email protected]> wrote:
> Hello Rob, > > "Are you looking to have Broker-J trigger the deletion on the blob at the > point at which it believes it no longer needs the message?" > Yes that's exactly what I'm trying to do. > Note that I managed to do it by creating my own vhost, just wanted to > check if there was a less intrusive way of doing it... > I agree that we shouldn't be able to modify the message but today I can't > even read it easily. > What I'm interested in are the headers but from a StoredMessage instance I > have to go through internal classes and package-protected classes to get > them: > ((InternalMessageMetaData) storedMessage.getMetaData()).getHeader(); > getHeader being package-protected here... > Note that this will only work if the message is an "Internal" message (i.e. the casting here would fail if the message were an AMQP 0-9, AMQP 0-10 or AMQP 1.0 message sent over the wire). The store API is basically built to be as unaware of the form of the message as possible, and the api here is basically designed to allow the store to clean up a message which was potentially stored in multiple queues, but which has now been removed from all of them. As such it's not really designed to make it easy for you to access the headers (or content - since the "content" will include structure for 1.0 messages). > Did I miss something? > No - I think to do this safely we'd have to expose some new API here. -- Rob > > Thanks, > Olivier > > -----Original Message----- > From: Rob Godfrey <[email protected]> > Sent: vendredi 6 mars 2020 17:54 > To: [email protected] > Subject: Re: [Broker-J] Claim-check pattern and MessageDeleteListener > > Hi Olivier > > I'm not entirely sure what your exact idea here is - are you looking to > have Broker-J trigger the deletion on the blob at the point at which it > believes it no longer needs the message? Or maybe to update the blob store > to make clear that the broker no longer needs to retain a copy of the > message? > > Clearly the API is not designed for allowing extensions here - and I think > if we were to try to make it an extension / interception point then we > would have to be careful in limiting what could be done here (e.g. offering > only some read-only view of the message). > > Without such an interception extension mechanism, you are correct I think > that you would need to create a new vhost type (potentially using a new > store type of your own implementation) > > -- Rob > > On Fri, 6 Mar 2020 at 16:37, VERMEULEN Olivier < > [email protected]> > wrote: > > > Hello, > > > > We're trying to implement the claim-check pattern on top of our broker > > + dispatch-router topology. > > So we have a blob store and the idea is for each message above 10KB to > > store the payload in it and to only keep an ID in the message. > > The tricky part is the delete of the payload in the blob store, > > especially since some of our use cases are using multicast... > > When looking at the Broker-J source code I found this > > MessageDeleteListener which would be really helpful for this use case: > > > > https://github.com/apache/qpid-broker-j/blob/c018e1ac9d21e9f5eb38d2ae7 > > a26a31e63c07fdf/broker-core/src/main/java/org/apache/qpid/server/store > > /MessageStore.java#L84 > > > > My first question would be, is it ok to use it? > > Second, so far the only way I found to register a new listener is to > > define my own VirtualHost, is there an easier way ? > > > > Thanks, > > Olivier > > ******************************* > > This e-mail contains information for the intended recipient only. It > > may contain proprietary material or confidential information. If you > > are not the intended recipient you are not authorized to distribute, > > copy or use this e-mail or any attachment to it. Murex cannot > > guarantee that it is virus free and accepts no responsibility for any > > loss or damage arising from its use. If you have received this e-mail > > in error please notify immediately the sender and delete the original > > email received, any attachments and all copies from your system. > > > ******************************* > This e-mail contains information for the intended recipient only. It may > contain proprietary material or confidential information. If you are not > the intended recipient you are not authorized to distribute, copy or use > this e-mail or any attachment to it. Murex cannot guarantee that it is > virus free and accepts no responsibility for any loss or damage arising > from its use. If you have received this e-mail in error please notify > immediately the sender and delete the original email received, any > attachments and all copies from your system. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
