I can see messages in poison queue but they get purged after some time. I am not sure how this is happening.
How can I keep them in poison queue and then manually delete them?
This is my netMsmqBinding in WCF service:
<-netMsmqBinding
<-binding name="MsmqBindingNonTransactionalNoSecurity" exactlyOnce="true" maxReceivedMessageSize="2147483647"
closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"
receiveRetryCount="5"
maxRetryCycles="1"
retryCycleDelay="00:00:20"
receiveErrorHandling="Move">
<-readerQuotas maxStringContentLength="2147483647" maxArrayLength="2147483647" maxNameTableCharCount="2147483647" />
<-security mode="None"/>
<-/binding>
<-/netMsmqBinding>
Look at timeToLive attribute here
Basically, the default is one day and the message will be discarded if it sits in a queue for longer than a day.
Related
I am using eJabberd server (MAM enabled) with client library Strophe.js. Client app is storing fixed amount of the messages in local storage.
All the messages, that I receive from the server include elements <archived/> and <stanza-id/>, which provide server-side generated IDs:
<message
xmlns="jabber:client" to="aaa#example.net/8667085700924567016834" from="aaa#example.net">
<result
xmlns="urn:xmpp:mam:2" id="1520510373346685">
<forwarded
xmlns="urn:xmpp:forward:0">
<message
xmlns="jabber:client" xml:lang="en" to="bbb#example.net" from="aaa#example.net/60965696931000870402419" type="chat">
<archived
xmlns="urn:xmpp:mam:tmp" by="aaa#example.net" id="1520510373346685"/>
<stanza-id
xmlns="urn:xmpp:sid:0" by="aaa#example.net" id="1520510373346685"/>
<body>asdf</body>
</message>
<delay
xmlns="urn:xmpp:delay" from="example.net" stamp="2018-03-08T11:59:33.346685Z"/>
</forwarded>
</result>
</message>
I use these IDs to get fixed amount of messages on each MAM call (using RSM paging - before/after/max attributes). For example:
params = {
"before": "1520510373346685",
"max": 10,
onMessage: <some handler>,
onComplete: <some handler>,
}
this.connection.mam.query(Strophe.getBareJidFromJid(this.myJid), params);
This gets me 10 messages before the message with stanza-id 1520510373346685.
However, the messages I send inherently do not have this ID, until I send them and retrieve from MAM.
I did not find any examples on getting the currently sent message ID from the server, and the Strophe does not provide any callbacks after the message was sent from the client and received by the server.
So, the question - is there any way to get the server-generated message ID (stanza-id/archived) for the currently sent message?
Maybe my own approach is wrong - should I generate my own IDs and add it to each message from the client?
There is currently no mechanism specified besides querying the archive. One prominent idea within the XMPP community to solve this in the future is to reflect the send carbon back to the original sender, which would include a stanza-id element with the ID assigned by the archive.
I am trying to send and receive message to and from JMS topics.
<testcase name="DeliveryToPT3PLIT">
...
<actions>
...
<send endpoint="fromEndpoint">
<message>
<resource file="com/roche/icc/citrus/messages/input/PT-3PLWoBatchSplit.xml"/>
</message>
<header>
...
</header>
</send>
<receive endpoint="toEndpoint">
<description>Receive asynchronous message from topic</description>
<message>
<resource file="com/roche/icc/citrus/messages/output/PT-3PLWoBatchSplit.xml"/>
</message>
<header>
...
</header>
</receive>
</actions>
</testcase>
It seems that these operations go one after another. The problem is that my application works really fast and when I send a message to first topic it appears on "toEndpoint" almost immediately. So the receive operation does not manage to catch appropriate message since it has been already processed.
Is there any way to make this operations simultaneously?
Regards
There is one thing to note about using JMS topics, because they work in a publish/subscribe manner, you have to subscribe first in order to receive the message.
That means you need to subscribe to the topic before a message is going to be published. Also, if you say that your application is fast, you may need to wait a few millis before sending the message. Here is a Java DSL example of what I think may work for you. (Note: I have tested this example with a JMS topic)
parallel().actions(
sequential().actions( // Thread #1
...
receive(action -> action.endpoint(toEndpoint).payload("message to be received"))),
sequential().actions( // Thread #2
sleep(500),
send(action -> action.endpoint(fromEndpoint).payload("message to be sent"))));
Notice the parallel() action container. It will execute every action inside it in a separate thread. Each sequential() represents a series of actions that allows you to group them together. Because both sequential() containers are inside the parallel(), the actions inside each of them will be executed on different threads.
So what happens here: you split your actions on two threads. On the first thread you wait for a message. On the second thread, you make it sleep for 500 millis first, after which you send the message.
I'm sorry that I don't have an XML example, but I hope this helps anyway.
Also don't forget to set the pub-sub-domain property to true on your endpoints. See the Citrus documentation on JMS topics: here.
I tried to find answer to my question in the Internet, but no effect. From what I know when I got some message it is hold in queue until the moment I ack it. So it may be very long, in particular infinitely longly. At it is ok for me.
However, the question is about what in case of sending nack ??
it is requeued ? What does it mean ? Don't remove it form queue or remove it and push at the end of queue ?
Thanks in advance,
Regards
According to the RabbitMQ documentation on NACKs, when a consumer sends a NACK, it also specifies if the message should be requeued or not. Example with Pika's basic_nack:
channel.basic_nack(delivery_tag = method.delivery_tag, requeue = True)
If the requeue parameter is set to False, the message will be discarded by RabbitMQ (and therefore lost).
If the requeue parameter is set to True, the message will stay in the queue until a consumer receives and ACKs it.
We are using hornetq-core 2.2.21.Final stand-alone after reading a non-transnational message , the message still remains in queue although it acknowledge
session is created using
sessionFactory.createSession(true, true, 0)
locator setting:
val transConf = new TransportConfiguration(classOf[NettyConnectorFactory].getName,map)
val locator = HornetQClient.createServerLocatorWithoutHA(transConf)
locator.setBlockOnDurableSend(false)
locator.setBlockOnNonDurableSend(false)
locator.setAckBatchSize(0) // also tried without this setting
locator.setConsumerWindowSize(0)// also tried without this setting
Message is acknowledge using message.acknowledge ()
I think that the problem might be two queues on the same address
also tried to set the message expiration but it didn't help , messages are still piling up in the queue
please advise
It seems you are using the core api. Are you explicitly calling acknowledge on the messages?
If you have two queues on the same address ack will only ack the messages on the queue you are consuming. On that case the system is acting normally.
Occasionally when NServiceBus picks up a message, it fails with the exception below. This causes NServiceBus to retry (up to it's configured retry limit). Sometimes one of the retries result in the message being handled successfully, but it's common for all retries to fail with the same exception. In this case, the message is routed to the error queue as expected when all retries fail.
My question is... what would cause this exception in the first place? It doesn't appear related to my message handler code, as my code doesn't appear in the stack trace.
NServiceBus version: 2.6.0.1504
OS: Windows Server 2003
Handler code is targeting .NET 3.5 or earlier
Here is the full exception message and stack trace:
NServiceBus.Unicast.Transport.Msmq.MsmqTransport [(null)] - Failed raising 'finished message processing' event. System.Messaging.MessageQueueException: Cannot enlist the transaction.
at System.Messaging.MessageQueue.SendInternal(Object obj, MessageQueueTransaction internalTransaction, MessageQueueTransactionType transactionType)
at System.Messaging.MessageQueue.Send(Object obj, MessageQueueTransactionType transactionType)
at NServiceBus.Unicast.Transport.Msmq.MsmqTransport.SendMsmqMessage(Message m, String destination)
at NServiceBus.Unicast.Transport.Msmq.MsmqTransport.Send(TransportMessage m, String destination)
at NServiceBus.Unicast.UnicastBus.SendReadyMessage(Boolean startup)
at NServiceBus.Unicast.UnicastBus.TransportFinishedMessageProcessing(Object sender, EventArgs e)
at NServiceBus.Unicast.Transport.Msmq.MsmqTransport.OnFinishedMessageProcessing()
I see the method NServiceBus.Unicast.UnicastBus.SendReadyMessage(Boolean startup) in your stack trace.
This tells me that your endpoint is connected to a Distributor. After all your message handlers have completed, an endpoint connected to a distributor will send the ReadyMessage back to the Distributor's control queue to say "I'm done with that work. Please send more!"
This is supposed to happen within the same transaction as the rest of your work, but apparently the MSMQ send is having trouble enlisting in that transaction. This could point to a problem with DTC. It would be interesting to know what else you have going on in your message handlers for that message type that also enlist in the transaction. You aren't manually committing or rolling anything back are you?