Redis dropping message of specific type

ServiceStack.Redis
1

I have a strange scenario with Redis since porting to Core where I have two message types, one is processing while the other is not. (Actually I have more than two types and others are processing correctly but these two types are at the same hierarchy level so should be almost equivalent).

The classes come from the same namespace and are descendant from the same parent object. The descendants actually have no individual properties, they were created simply for the type name so they could be received by separate micro service queue mechanisms. Code for classes is below

What I see is that both sets of messages enter the incoming queue

however after allowing to process, the MqttStreamMessage variant does not process the messages and does not deliver them to the outq

I put breakpoints on the constructors of both ServiceStack.Services. The constructor for the Websocket one is hit while the constructor for Mqtt is not, so appears that the Redis mechanism can’t invoke the execute that was registered here:

        redisMqServer.RegisterHandler<MqttStreamMessage>(ExecuteMessage);
        redisMqServer.RegisterHandler<MqttInboundMessage>(ExecuteMessage);

Any ideas what could be happening or how I may debug this? The code is very similar between these two services, and I’m not seeing any exceptions raised at present. How can I capture the exception that is occurring causing Redis to drop the message ?

public class StreamMessage
{
    ...
    properties
    ...
}

public class WebsocketStreamMessage : StreamMessage
{
}

public class MqttStreamMessage : StreamMessage
{
}
2

If there was an Exception it would go in the .dlq otherwise there is a RegisterHandler overload that lets you specify a custom Exception handler:

My preferred way to debug this is to checkout the ServiceStack.Redis, ServiceStack.Text and ServiceStack GitHub projects and add references to ServiceStack.Interfaces.csproj, ServiceStack.Common.csproj, ServiceStack.Text.csproj and ServiceStack.Redis.csproj projects in your solution so you can debug the sources directly. Alternatively I believe Rider will let you debug the decompiled sources but as it doesn’t use the original source code it can be a bit harder to read/follow.

2 Likes
3

Thanks Mythz, will give that a crack

4

Thanks the approach to debugging helped, I found the root cause it was a namespacing issue.

1 Like