recently we upgraded our nServiceBus version to 7. Post this upgrade we are noticing that this endpoint stops processing messages intermediately.
We checked our logs and noticed below message there
Replication destinations cleared for url http://RavendbURL/databases/XXXBusDB. Failover servers count: 0
What could the reason of this message? And if this bringing down the endpoint?
Thanks
Related
I am using ServiceStack 5.0.2 and Redis 3.2.100 on Windows.
I have got several nodes with active Pub/Sub Subscription and a few Pub's per second.
I noticed that if Redis Service restarts while there is no physical network connection (so one of the clients cannot connect to Redis Service), that client stops receiving any messages after network recovers. Let's call it a "zombie subscriber": it thinks that it is still operational, but never actually receives a message: client thinks it has a connection, the same connection on server is closed.
The problem is no exception is thrown in RedisSubscription.SubscribeToChannels, so I am not able to detect the issue in order to resubscribe.
I have also analyzed RedisPubSubServer and I think I have discovered a problem. In the described case RedisPubSubServer tries to restart (send stop command CTRL), but "zombie subscriber" does not receive it and no resubscription is made.
I have a webpage connecting to a rabbit mq broker using javascript/websockets that are exposed by a spring app deployed in tomcat. Messages are produced 1 per second by an external application and are rendered on the webpage. The javascript subscription is durable.
The issue I'm experiencing is that when the network connection is broken on the javascript client for a period of time (say 60 seconds), the first ~24 seconds of messages are missing. I've looked through the logs of the app deployed in tomcat and the missing messages seem to be up until the following log statement:
org.springframework.messaging.simp.stomp.StompBrokerRelayMessageHandler - DEBUG - TCP connection to broker closed in session 14
I think this is the point at which the endpoint realises the javascript client is disconnected and decides to close the connection to the broker resulting in future messages queueing up.
My question is how can I ensure that the messages between the time the network is severed and the time the endpoint realises the client is disconnected are not lost? Should the endpoint put the messages back on the queue somehow? Maybe there's a way to make it transactional?
Thanks in advance.
The RabbitMQ team monitors this mailing list and only sometimes answers questions on StackOverflow.
Your Tomcat application should not acknowledge messages from RabbitMQ until it confirms that your Javascript client has received them. This way, any messages that aren't ack-ed by the JS client won't be ack-ed by Tomcat, and RabbitMQ will re-deliver them.
I don't know how your JS app and Tomcat interact, but you may have to implement your own ack process there.
We have an issue with a windows service which uses nServiceBus. At some random moment, the nServiceBus stops processing messages and direct them directly to Error queue, and I have to restart the service. After the restart, the messages arrived in the input message queue are handled, and everything gets back to normal. If we re-drop the messages which were went to error queue, it is processing it successfully without any issue.
We are using log4net logs to audit the message flow and storing in DB. The NServiceBus Handler stops to log in log4net. After we restart the windows service (NServiceBus) then it start to log again. We are NOT able to redproduce this issue in development environment. We are suspecting this could be a NService Bus Memory Leak issue. But we don't know how to confirm this issue and resolve the same.
We are planning to move this Windows Service (NServiceBus) to different server as a trial and error basis. Did anyone face this issue ever and resolved it? Please help us to resolve this issue as it is causing more troubles in Production environment.
NServiceBus Version that we are using : 2.0.0.1329
Message queue and windows service are in the same machine.
I believe you're running on a version of NServiceBus that is about 5 years old and is no longer supported. While I could give you the standard recommendation of upgrading to a more current release, it could very well be that some of the configuration APIs that you're using have been made obsolete so you may need to make some modifications there and/or in the app.configs.
I'm sorry to say that there probably isn't a better solution for you at this time.
In general, I'd suggest trying to track the NServiceBus releases somewhat more closely. If you're within 6-12 months of the current release, you should generally be in good shape.
My application consumes JMS messages in a Glassfish 3.1.2 server and OpenMQ as JMS provider.
The strange behavior happens when a consumer fails to process a message. In this situation Glassfish correctly move the message to the Dead Message Queue (after 2 attempts). And this is fine.
When I restart the server, the message stored in the DMQ, is sent again to the original destination (and that's ok, althoug I didn't expect this behavior). Now, also if the consumer succeed, the message remains in the destination.
That's incorrect because, after another restart of the server, the message is consumed again. Strangely this time the message is permanently removed from the queue.
The questions are:
why the message remains in the queue?
And why GF try to move automatically the message from the DMQ into the original one, after a restart?
I'm using NserviceBus 2.0 with pub/sub mode.
My subscribers are installed as a windows service.
However after computer restart I always get the following problem in log : "Problem in peeking a message from queue: ServiceNotAvailable".
After digging into source code I found that this is NserviceBus custom error and it occurs in MsmqTransport class. It seems like my subscriber's service is started before Msmq service. Bus this should be impossible because subscriber's service has Msmq as dependency.
After some time service is starting and working correctly. But I have several megabytes of errors in log. And sometimes service is not even starting.
Can anyone help me? I'm using Windows 7. Msmq is installed with NserviceBus utils.
You need to configure your service to be dependent on the MSMQ service. This is should be automatically taken care of if you're using the NServiceBus host.
Installing a Windows Service with dependencies
Have seen the same problem. Actually the impact was even worse since we used log4net and SmtpAppender. Took down the mailserver, ouch! Seems like this is fixed in NSB 3. It sets number of workerthreads to zero and logs "please reboot service". You can even execute own code when the error occurs. Config with lambda using OnCriticalError. We ended up patching the NSB 2 code, since we havent upgraded to NSB 3 yet. Handling MSMQExceptions, logging and stopping the process on errorcode ServiceNotAvailable like they already do when you don't have correct rights to queue. You should probably stop the service on any MSMQExceptions exept IOTimeout.