Queue Maintenance

[Rob Tennyson]

Is there anything built into MT that can help manage the queues?

I'm specifically thinking of the error queues. I saw the thread
similar to this, but I'm not looking to manage it with a utility, but
rather in code.

Scenario:

- Web client - commands are published as messages with MT to a remote
queue on an application server.

- App server - the commands are consumed and executed. If the command
throws during execution, it's placed in the error queue.

- Web client - end users can view all commands in the error queue.
They resolve them one at a time and have them re-published to be
executed again.

The first two are easy enough. The third one is where I'm at now.
Any suggestions greatly appreciated.

Thanks,
Rob

[Dru Sellers]

look in src/tools/busdriver for a CLI type thing.

otherwise just enumerate the messages in the queue, they should be xml, make the edit and then resubmit?

-d

--

You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To post to this group, send email to masstrans...@googlegroups.com.
To unsubscribe from this group, send email to masstransit-dis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/masstransit-discuss?hl=.

[Chris Patterson]

Would your "Manager of the Queues" be an administrative function or a user view of "things that didn't finish properly and need attention?"

You could use the Endpoint Receive function to enumerate the messages in the queue (just return null from the Func<object, Action<object>> call, which would give you every message in the queue. Then when you actually want to receive you could use that same function, but that's kind of annoying.

The Transport deals with the messages directly (the MSMQ Message object), but you would have to deserialize them yourself (not difficult). Here though you would have the transport Id if you want to build a function around the management object or something to move a message between queues via the transport (using the transport message Id).

Just some random thoughts. There is a MsmqEndpointManagement class that has some functions like creating and removing queues that would seem like a place for this type of functionality but I'm trying to think about it.

--

You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To post to this group, send email to masstrans...@googlegroups.com.
To unsubscribe from this group, send email to masstransit-dis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/masstransit-discuss?hl=.

Chris Patterson

chrisfr...@gmail.com

[Rob Tennyson]

Definitely an end user view of things that went wrong while executing
commands - no "manager of the queues" in their eyes.

I've been looking at MsmqEndpointManagement and it definitely seems
like the best candidate for adding functionality. It looks like I
just need to add:

- the ability to enumerate the endpoint
- the ability to selectively remove a message (so I can either discard
or re-publish)

I think that's it anyway.

Thanks for the input guys

> chrisfromtu...@gmail.com

[Chris Patterson]

Yeah, the two things you mention are actually how the Receive() on IEndpoint works.

Func<Message, Action<Message>>

You are passed the message (which in this case, I'm referring to the IMsmqTransport version that uses the MSMQ Message class), and you can decide if you want to consume it (i.e. read it) from the queue. If you return null, it is skipped. If you return an Action<Message> it will read the message and call your action if the message was still available (i.e. hasn't expired or been received by a competing consumer).

So those items are present, you just need to put a bow around them for your use case.

For more options, visit this group at http://groups.google.com/group/masstransit-discuss?hl=.

Chris Patterson

chrisfr...@gmail.com

[Rob Tennyson]

Two things I don't see though

- I need to be able to show the users the exception that was raised and the command that was attempted.  I'll also need the message ID for the next one

- I then need to be able to remove a specified message rather than just the next one in the queue. I can't see the users being OK with having to handle the errors in order.


I'm a bit fearful of how much of the code will have to be touched to enable these.  Do you think this is a one-off scenario that shouldn't muddle up the MT codebase?

Rob

[Chris Patterson]

Sounds like you might want to capture the exception yourself in the message handler and perhaps send the message to the failure endpoint yourself.

The framework will publish a Fault<T> where T is your message type if it encounters an exception being returned by the consumer. You could do something similar with a more explicit usage in your application domain.

public class MyCommand {}

public class MyFailedCommand<T> {

public T FailedCommand { get; set; }

}

Then it will serialize your command with the properties you add to MyFailedCommand so that you can provide more information.

[Rob Tennyson]

I've definitely considered doing this just to make things easier (wrapping the failed command in an object to hold extra data about the failure).

The things I'm not able to find in the core so far though:

- Getting the actual content of messages without removing them from the queue (think Peek).  Receive seems to be destructive if I want to view the message and not just count it.

- Getting the id of the messages that I view so I can turn around and actually receive any one of them in any order.

Of course, I wasn't able to devote decent blocks of consecutive time to this over the weekend.  Since this is for my current production app at work, I'll be at it all this week so hopefully I'll either find it or add it.  Thanks for all your feedback so far.

Rob