I'm looking for a way to know who/what purged a queue (specifically Errors queue) in MSMQ. I know that messages were purged because they end up in "Transactional dead-letter messages" with the Type set to "Acknowledgement QueuePurged". But is there any way to know which AD user (or process?) triggered this? Nothing seems to be logged in Event Viewer.
There will be nothing in the security event viewer as there is no auditing enabled by default.
Auditing Message Queuing Objects
Related
I am currently looking to buildout a messaging service where users can send and receive messages privately between each other. I may have a need for multi-user chat, but for the most part, I only want single recipients to be able to read messages sent to them.
With looking at RabbitMQ, does it make sense to use one exchange, and create a queue for each user when they login and destroy each queue on logout? Are there major performance issues with creating a queue for each user or are there better alternatives?
I am building a REST API and plan on having users send messages to others through an endpoint (/send) and subscribe to their own message streams via websockets or something similar. I will probably store messages in MongoDB as well, so users can access all of their previous messages. Any suggestions on structure are appreciated.
I think your approach is correct. You event don't need an exchange if you will use the default exchange (AMQP Default). And during login create a new queue and keep queue name same as user name. (Just need to make sure user names are unique) And if you publish message to the default exchange with username (ie: queue name) as routing key, RbbitMQ will route that message to that queue only. And on logout if you delete the queue then user is going to miss the messages when he is not online. If it is OK then create queue after login and use the configuration exclusive which says queue gets deleted when there is no consumer. But if you want to keep offline messages then you need to create queue permanently during user signup.
I need to get the Id of a msmq message inside of my handler so I can write that Id to a log.
When a message is sent to the error queue an email is sent informing us of a failed message. Once the error that caused the message is resolved we need to use the 'ReturnToSourceQueue' NServiceBus tool to try that message again. Without logging that Id, it would be difficult to track down which message is which when looking through the message queues.
Every where I've looked suggests that Bus.CurrentMessageContext.Id will give me the same Id that's in the Message ID column when looking at the queues in ComputerManagement->Services and Applications->Message Queuing->[Some Queue]->Queue messages. However, those ids don't seem to be the same.
What am I missing?
The reason that the message ID that you see in MMC plugin or Queue Explorer is different is that when the message is "moved" to the error queue, what actually happens is that a new MSMQ message is created with the same body and headers and that is sent to the error queue.
Also, when the processing a message fails, NServiceBus already logs this for you and includes the ID of the message, so that's already done for you.
If you take the ID that was logged and pass that to the ReturnToSourceQueue tool, everything will just work.
The last piece of the puzzle for you is sending an email when a message fails. Now, I'm not sure that that is the wisest idea as you may end up spamming your ops team when a database goes offline or a 3rd party webservice becomes unresponsive. Still, if that's what you want to do, then I'd suggest using an email appender for when errors are logged.
Finally, let me say that we're in the process of building this kind of notification functionality into the Particular Service Platform around NServiceBus. We've got a UI showing errors and allowing messages to be reprocessed coming as a beta in November '13 and the notification functionality will probably be ready towards the end of the year.
It's really a question of whether you want to wait or to build this yourself.
Just create an instance of your bus in your handler:
public IBus Bus { get; set; }
Then use that to get the message id:
this.Bus.CurrentMessageContext.Id
The Bus instance will be injected when the handler is called.
EDIT
Now that I have actually read the question...
The CurrentMessageContext.Id returns what's in the message header under the CorrId field. This can be seen in the Label column in Server Management.
The Message ID displayed in the MessagId column is the message ID as it existed on the sending computer. I am not sure how to access this value from CurrentMessageContext but you should not need to do this to find a local message.
I am developing a xmpp client and currently working on "pubsub".
I created a node in pubsub and subscribed two users to it.
But when a subscriber login(show presence) i get the last published item twice.
I am using ejabberd server.
Can anyone help??
Thank you.
Same here,
There seems to be two different queues. With notification_type=normal, messages are stored offline. When receiver becomes online, it receives the message twice:
from offline spool, without headline attribute
from pubsub send loop (as node is still configured with send_last_published_item = on_sub_and_presence)
As stated here when configuring pubsub node with notification_type=normal, it's best to disable send_last_published_item or set it to on_sub only in order to avoid receiving the message twice.
We have limited the number of maxSession to 5
#ActivationConfigProperty(propertyName = "maxSession", propertyValue = "5")
If more than 5 concurrent request comes, then it has to wait in the queue. Is there any option to view the number of waiting messages in the queue as a list and manage the queue. Is there any API to view and manage the queue. For example, if a JMS message is waiting for long time, using queue management we can re-initiate message or we can drop the message.
JMS Browsers are made to do that.
You can also use the Management API to do that.
Also, the issue with you doing that is going to be concurrency.
The message may be gone by the time you use anything to list the message.
Also, have you looked at expired messages? if you want a timeout for the message, you could set expiration and listen to the expiry queue. That would be a better design for your application.
How is it possible to check that particular user has write rights to Queue / Topic, without affecting Destination.
If user has no such rights exception will be thrown and there would be zero-affection.
But if user has such rights, then new message will appear in Queue / Topic, and this is that shouldn't occur.
Is there any way to perform such test? May be is it possible to use transaction without commit?
I think generally, it will depend on the JMS provider that you're using, as JMS itself does not specify security mechanisms. On IBM MQ, for example, calling Session.createProducer(Destination queueOrTopic) will throw an InvalidDestinationException if you're not authorized to send/publish messages to a destination.