We have a production database where service broker was disabled.
We have a profiler that logs every backup / restore operation. I cannot find any restore operation in its trace.
Are there any other reasons than a database restore for service broker to be disabled ?
Note that this database is mirrored using high-availability and a witness server. In the error log, I can find
2011-07-29 09:00:52.53 spid25s Error: 1479, Severity: 16, State: 2.
2011-07-29 09:00:52.53 spid25s The mirroring connection to "TCP://DB84200:5022" has timed out for database "XXX" after 10 seconds without a response. Check the service and network connections.
2011-07-29 09:00:53.05 spid24s Database mirroring is inactive for database 'XXX'. This is an informational message only. No user action is required.
2011-07-29 09:00:53.72 spid24s Error: 1404, Severity: 16, State: 6.
2011-07-29 09:00:53.72 spid24s The command failed because the database mirror is busy. Reissue the command later.
Can mirorring failure disable service broker ? Or maybe is it the opposite : mirorring fails because service broker is disabled ?
Any suggestion to solve this issue would be greatly appreciated !
Service Broker provides automatic poison message detection. Automatic poison message detection sets the queue status to OFF if a transaction that receives messages from the queue rolls back five times.
Check the SQL Server Logs for the roll backs.
This looks more like a mirroring error though.
Related
I see that my custom Spring cloud stream sink with log sink stream app dependency loses RabbitMQ connectivity during RabbitMQ outage, tries making a connection for 5 times and then stops its consumer. I have to manually restart the app to make it successfully connect once the RabbitMQ is up. When I see the default properties of rabbitMQ binding here, it gives interval time but there is no property for infinite retry(which i assume to be default behaviour). Can someone please let me know what I might be missing here to make it try connecting infinitely ?
Error faced during outage triggering consumer retry :
2017-08-08T10:52:07.586-04:00 [APP/PROC/WEB/0] [OUT] Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; protocol method: #method<channel.close>(reply-code=404, reply-text=NOT_FOUND - home node 'rabbit#229ec9f90e07c75d56a0aa84dc28f602' of durable queue 'datastream.dataingestor.datastream' in vhost '8880756f-8a21-4dc8-9b97-95e5a3248f58' is down or inaccessible, class-id=50, method-id=10)
It appears you have a RabbitMQ cluster and the queue in question is hosted on a down node.
If the queue was HA, you wouldn't have this problem.
The listener container does not (currently) handle that condition. It will retry for ever if it loses connection to RabbitMQ itself.
Please open a JIRA Issue and we'll take a look. The container should treat that error the same as a connection problem.
I've created a simple saga prototype project with RabbitMQ as the transport and RavenDB as the persistence mechanism. The prototype actually runs as expected, but every few seconds i get this error msg:
ERROR NServiceBus.Transports.RabbitMQ.RabbitMqDequeueStrategy Failed to receive messages from [Assembly].Retries
System.AggregateException: One or more errors occurred. --> System.IO.EndOfStreamException: SharedQueue closed
at RabbitMQ.Util.SharedQueue1.EnsureIsOpen()
at RabbitMQ.Util.SharedQueue1.Dequeue(int 32 milliseconds timeout.......
I also get an almost identical message immediately following the above one but it says it Failed to receive messages from RabbitMGPoller.Timeouts
In addition to that there are constant INFO messages that say:
NServiceBus.Transports.RabbitMQ.RabbitMqConnectionManager Disconnected from RabbitMQ broker, reason: AMQP close-reason, initiated Library, code=0 text="End of stream"... cause=System.IOException:Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host...
I have tried adding a DequeueTimeout=600 value to the transport connection, but the same errors still occur. I've also tried adding the following key in the config file, but it still didn't seem to help.
I eventually figured it out, just my lack of understanding of RabbitMQ and NServiceBus. I changed the RequestedHeartbeat value for the RabbitMQ connection to something larger i.e. RequestedHeartbeat=6000. That solved my issue.
I am a newbie at SQL Service Broker so pardon my ignorance.
We have a SQL Service broker that needs to be enabled again after the database has restarted. How can we get to be automatically enabled after the sql service restart?
Also we are able to send messages when the broker is disabled and it throws no SQL error. We can search the queue and it has nothing (neither of the queues - see below).
Once we enable the broker all the messages appear on the queue. Is that a normal behavior or some missconfiguration.
See below for the configuration of the service broker.
Thank you,
Greg
ALTER DATABASE our_database SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE
CREATE MESSAGE TYPE IncomingFileMessage
VALIDATION = NONE;
CREATE CONTRACT IncomingMessageContract
(IncomingFileMessage SENT BY ANY);
CREATE QUEUE ReceivingQueue
CREATE QUEUE IncomingMessageQueue
CREATE SERVICE ReceivingMessageService
ON QUEUE ReceivingQueue (IncomingMessageContract);
CREATE SERVICE IncomingMessageService
ON QUEUE IncomingMessageQueue (IncomingMessageContract);
You do not need to do anything to re-enable the broker after a service start up. Once enabled it stays enabled until is explicitly disabled or the database is restored. In fact is very likely the database is already enable when you created it.
As to where are the messages sent while the broker is disabled: look in sys.transmission_queue. Storing sent messages when there is a delivery problem (in this case, broker being disabled) is normal behavior.
I am getting the "Connection Reset by Peer" error in Redis Log.
probably your client either timed out or has raised another exception that disconnects the connection before redis was able to write to it. or it has crashed.
either increase your client's timeout, or check the client logs to see what happens.
If you try to connect to redis before it's fully started, you might get this error from the client.
I fixed it by adding a two-second sleep after starting the container and before trying to connect. Better would be to wait for some kind of healthy indicator.
I'm a fairly new user of ActiveMQ and I'm looking for a way to get detailed debug information on the client side of a queue connection. My problem is this: I have a server that is sending a message through a queue to a client. Using the admin web page associated with the broker, I can verify the following: the queue was created, there is a consumer associated with the queue, the message has been enqueued, the message has been dispatched, the dispatched queue size is 1, the message has not been dequeued. This setup was working yesterday but mysteriously stopped working today even though I did a restart of the activemq service. The log file at /var/log/activemq.log does not contain any useful information.
At this point I'm stumped; I'm assuming that there is some sort of problem with the configuration, but it hasn't changed since yesterday. Does anybody have a suggestion about what my next step should be?
Turn on debug (or even trace) logging in the broker first of all in conf/log4j.properties.
log4j.logger.org.apache.activemq=DEBUG
restart the broker and re-run your scenario. The logging will hopefully provide you with some information.
Jconsole is also a useful tool to monitor the running broker.
Does your client use any message filters?
You can also enable remote debugging and then connect with an IDE.
To start remote debugging execute
$ ACTIVEMQ_DEBUG=true bin/activemq
and then start a remote debugger to connect to port 5005