New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ServiceName parameter is ignored when importing failed audit messages #1511

Closed
TraGicCode opened this Issue Dec 3, 2018 · 3 comments

Comments

Projects
None yet
4 participants
@TraGicCode
Copy link

TraGicCode commented Dec 3, 2018

I just performed an upgrade from servicecontrol 2.1.2 to the latest release version. When i stop the servicecontrol service to import failed audit messages it blows up claiming the servicecontrol queue doesn't exist. It actually looks like it's connecting to the wrong queue name.

PS C:\Windows\system32> & "C:\Program Files (x86)\Particular Software\Particular.ServiceControl.real-prod\ServiceControl
.exe" --serviceName=Particular.ServiceControl.real-prod --import-failed-audits
2018-12-03 09:32:27.2449|33|Fatal|NServiceBus.ReceiveComponent|Receiver Main failed to start.
RabbitMQ.Client.Exceptions.OperationInterruptedException: The AMQP operation was interrupted: AMQP close-reason, initiat
ed by Peer, code=404, text="NOT_FOUND - no queue 'Particular.ServiceControl' in vhost 'real-prod'", classId=60, methodId
=20, cause=
   at RabbitMQ.Client.Impl.SimpleBlockingRpcContinuation.GetReply(TimeSpan timeout)
   at RabbitMQ.Client.Impl.ModelBase.BasicConsume(String queue, Boolean autoAck, String consumerTag, Boolean noLocal, Bo
olean exclusive, IDictionary`2 arguments, IBasicConsumer consumer)
   at RabbitMQ.Client.Impl.AutorecoveringModel.BasicConsume(String queue, Boolean autoAck, String consumerTag, Boolean n
oLocal, Boolean exclusive, IDictionary`2 arguments, IBasicConsumer consumer)
   at NServiceBus.Transport.RabbitMQ.MessagePump.Start(PushRuntimeSettings limitations)
   at NServiceBus.TransportReceiver.Start()
   at NServiceBus.ReceiveComponent.Start()�
                                                                           

Is this something that got barked in the upgrade process? Why is it trying to connect to a queue named Particular.ServiceControl? It should be connecting to a queue named Particular.ServiceControl.real-prod instead.

@WilliamBZA

This comment has been minimized.

Copy link
Member

WilliamBZA commented Dec 4, 2018

Looks like we don't take the serviceName into account in the ImportFailedAuditsCommand, a definite oversight. We're working on a new version of SC right now, I'll see if we can get a fix in with that release too or if we need a separate release. In the meantime, can you hold off on trying to import failed audit messages for a bit?

@SzymonPobiega SzymonPobiega changed the title Importing audit messages fails due to queue not found exception ServiceName parameter is ignored when importing failed audit messages Dec 4, 2018

@TraGicCode

This comment has been minimized.

Copy link

TraGicCode commented Dec 4, 2018

Yes we can hold off for a bit on this one. Thank you

@TraGicCode

This comment has been minimized.

Copy link

TraGicCode commented Dec 11, 2018

Seems resolved in 3.4.0 but #1505 still happens....

@TraGicCode TraGicCode closed this Dec 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment