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... Did I miss something?
Thanks, Olivier -----Original Message----- From: Rob Godfrey <rob.j.godf...@gmail.com> Sent: vendredi 6 mars 2020 17:54 To: users@qpid.apache.org 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 <olivier.vermeu...@murex.com> 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: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
