On Mon, Aug 29, 2016 at 8:40 AM, Gordon Sim <[email protected]> wrote: > On 29/08/16 13:36, Matt Broadstone wrote: > >> On Mon, Aug 29, 2016 at 8:31 AM, Gordon Sim <[email protected]> wrote: >> >> I've raised a JIRA[1] and committed a fix. >>> >>> >>> Oops, sorry about that. >> > > No problem, I got the JIRA just before yours, and you beat me to the list. > I marked yours as a duplicate. > > Out of curiousity, what is your use case for consuming and releasing on an >>> LVQ? >>> >>> >>> I think generally the same as for a normal queue: if a consumer receives >> a >> message it can't necessarily process at the time (maybe its a worker that >> is actually overloaded at the moment). I understand we could just >> republish >> the message, and had done so up until now, but I'm trying to move our >> internal code to a more consistent and generic rpc abstraction and this >> issue popped up for the one LVQ we are using. >> > > I see, and so the LVQ mechanism is used to remove a redundant previous > request when a new request message is sent? > > Yes. In this particular case I'm using the LVQ to provide a certain level of failover. The work units published to this queue are required to be unique, however if the issuing entity crashes for some reason and someone else picks up the job it seemed more prudent simply to republish the work rather than iterating the queue in copy mode and determining what was missing. Furthermore, because its an LVQ we have the ability to try to "cancel" the job by publishing a no-op version of the work with the same LVQ key.
Is there any chance this would make it into the release? Matt > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
