Access to the Error Queue

[PeterOscarsson]

Hi. Just started to use DNWQ and find it very suitable to my use case with the Redis Transport.
I have one question though, I would like to intercept when a message is moved to the error queue, either direct or after the defined number of retries.

Also, is there any automatic handling (clearing) of the error queue?

Is there any samples regarding the error queue that I've missed?

Btw, is this the right place for this kind of questions?

Tnx for a nice Library

[blehnen]

Hi,

You can intercept the error handler by implementing IReceiveMessagesError as a decorator and injecting your implementation into the QueueContrainer.

Here is an example of an error message decorator:

https://github.com/blehnen/DotNetWorkQueue/blob/master/Source/DotNetWorkQueue/Metrics/Decorator/IReceiveMessagesErrorDecorator.cs

You'll see that a enum indicates if the record will be retried or moved to the error queue. If you wanted to prevent the record from moving to the error queue, that's a bit trickier. You would need to decorator the redis command handler for moving the record, and do something else; that would include stopping it from re-processing.

https://github.com/blehnen/DotNetWorkQueue/blob/master/Source/DotNetWorkQueue.Transport.Redis/Basic/CommandHandler/MoveRecordToErrorQueueCommandHandler.cs

Decorators are registered with 'RegisterDecorator' when you create the queue container.

There is no automatic clearing of the error queue. We internally have to manually handle errors, and so we manually clear the error data. I had always intended to write an admin tool that showed the current queue state and allowed for removing/moving records but have not yet had the time.

-Brian

[PeterOscarsson]

Brian, thanx. The decorator worked perfectly.
I will also have to handle errors manually, so I will clear the errors the same way.
At least until I get the time to send a PR with error handling. :-)

Another quick question. The messages sent does need to be public, I tried to use Internal but there was a problem with the deserialization. Is this something you know why. Not a big Issue, but as my team is using this I would like to keep the "Internal" messages internal. :-)

Thanx for a great Lib.

[blehnen]

I seem to remember that the serialization issue is due to MessagePack requiring public classes. I had the same issue, and could not figure out a work around. I didn't spend much time on it though.

I had forgotten all about that until now. I guess I should have put it in the wiki somewhere - whoops.

Unfortunately, the redis transport is hard coded to use messagepack in a few spots - this is because that was the only serializer built into redis, and we use that in the LUA scripting for the queue commands.

I found MessagePack to be rather picky about the data it works with compared to JSON.net. I wish they had supported JSON instead inside redis, but I understand why they didn't.