Comments (18)
How are you hosting this?
Just a hunch but can you force UseSingleBrokerQueue to true?
Configure.ScaleOut(s=>s.UseSingleBrokerQueue());
from nservicebus.rabbitmq.
I'm hosting both services with NserviceBus.Host. ServiceA is hosted AsA_Client and ServiceB is hosted AsA_Server. Service A is actually an integration test project. Both are services are sitting on the same box, RabbitMQ is on separate box.
Configuring services to use single broker queue has no effect on behavior.
Currently, I'm working around the issue by
- intercepting outgoing transport messages (IMutateOutgoingTransportMessages.MutateOutgoing),
- and overriding machine name in TransportMessage.ReplyToAddress based on configuration
This works alright for now, since I can do everything using interceptors.
from nservicebus.rabbitmq.
Apparently, the timeout messages get wrong machine name as well. I tracked down the issue to TimeoutManager.Initialize(). DispacherAddress always gets the value on the processing machine, not the queue machine.
I couldn't figure out a workaround not involving reflection - I'm overriding TimeoutManager.DispacherAddress by force.
from nservicebus.rabbitmq.
Can you share your message mappings from config? (something spound vierd, the rabbit transport should ignore all machine names if UseSingleBrokerQueue is true)
from nservicebus.rabbitmq.
Sure. These are on service B:
<MessageEndpointMappings>
<add Messages="System.Storage.Messages.V1" Endpoint="[email protected]" />
<add Messages="System.Config.Messages.V1" Endpoint="[email protected]" />
</MessageEndpointMappings>
and this is on service A (integration test client)
<MessageEndpointMappings>
<add Messages="Customer.Storage.Adapter.Messages.V1" Endpoint="[email protected]" />
</MessageEndpointMappings>
Afaik, you just described the problem - ignoring machine name even if I have set it. The name of the processing machine always pops up.
from nservicebus.rabbitmq.
Now I'm confused. Machine names are ignored since all endpoints connect to the same broker which you specify in the connectionstring?
What is it your trying to acheive by putting machine names in the message mappings?
Sent from my iPhone
On 19 mar 2014, at 16:45, peuramaki [email protected] wrote:
Sure. These are on service B:
<MessageEndpointMappings> <add Messages="System.Storage.Messages.V1" Endpoint="[email protected]" /> <add Messages="System.Config.Messages.V1" Endpoint="[email protected]" /> </MessageEndpointMappings>
and this is on service A (integration test client)
<MessageEndpointMappings> <add Messages="Customer.Storage.Adapter.Messages.V1" Endpoint="[email protected]" /> </MessageEndpointMappings>
Afaik, you just described the problem - ignoring machine name even if I have set it. The name of the processing machine always pops up.
—
Reply to this email directly or view it on GitHub.
from nservicebus.rabbitmq.
Why, I'm trying to force NSB to use my RabbitMQ box instead of NSB box of course, using the approach of trying anything. It's not working though, behavior is the same with or without the specified queue server.
If you take a look at TimeoutManager.Initialize()
DispatcherAddress = Address.Parse(Configure.EndpointName).SubScope("TimeoutsDispatcher");
the result always points to local box, not rabbit box defined in transport config. I haven't been able to work around this. There's a promisingly named method
Address.OverrideDefaultMachine(rabbitMqHost);
but it doesn't seem to have any effect either.
from nservicebus.rabbitmq.
I think I'm missing something, the way to specify which broker you connect
to through the "NServiceBus/Transport" connection string?
Is that not working for you?
On Thu, Mar 20, 2014 at 7:29 AM, peuramaki [email protected] wrote:
Why, I'm trying to force NSB to use my RabbitMQ box instead of NSB box of
course, using the approach of trying anything. It's not working though,
behavior is the same with or without the specified queue server.If you take a look at TimeoutManager.Initialize()
DispatcherAddress = Address.Parse(Configure.EndpointName).SubScope("TimeoutsDispatcher");
the result always points to local box, not rabbit box defined in transport
config. I haven't been able to work around this. There's a promisingly
named methodAddress.OverrideDefaultMachine(rabbitMqHost);
but it doesn't seem to have any effect either.
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-38138693
.
from nservicebus.rabbitmq.
Yes, I have defined the transport connection string
<add name="NServiceBus/Transport" connectionString="host=rabbitmq01.localdomain" />
And this is working out for me, excecpt when
- I use Saga.ResponseToOrginator
- Timeouts are being used
- SLR's are being used
And I'm not using explicit timeouts in the saga with problems, NSB seems to use them sometimes (I'm not sure on what conditions).
The problem is non-deterministic: sometimes it works, sometimes it doesn't.
from nservicebus.rabbitmq.
Any chance you can create a little sample project I can run to expose this?
On Thu, Mar 20, 2014 at 8:22 AM, peuramaki [email protected] wrote:
Yes, I have defined the transport connection string
And this is working out for me, excecpt when
- I use Saga.ResponseToOrginator
- Timeouts are being used
- SLR's are being used
And I'm not using explicit timeouts in the saga with problems, NSB seems
to use them sometimes (I'm not sure on what conditions).
The problem is non-deterministic: sometimes it works, sometimes it doesn't.Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-38140753
.
from nservicebus.rabbitmq.
I wrote a little project that should reproduce the issue but it doesn't..
I've done some more debugging though. Apparently, using rabbit transport and UseSingleBrokerQueue=true, NServiceBus.Address.Machine never gets used. Instead, address to send messages is always defined in rabbit channel that gets it from NServiceBus/Transport configuration. Am I correct?
Current suspect for the cause of this issue is RabbitMqUnitOfWork - sometimes message sending actions do get added to UoW, but are never run.
from nservicebus.rabbitmq.
I've done some more debugging though. Apparently, using rabbit transport
and UseSingleBrokerQueue=true, NServiceBus.Address.Machine never gets used.
Instead, address to send messages is always defined in rabbit channel that
gets it from NServiceBus/Transport configuration. Am I correct?
That is correct!
Current suspect for the cause of this issue is RabbitMqUnitOfWork -
sometimes message sending actions do get added to UoW, but are never run.
This sounds vierd, possibly a bug!
On Thu, Mar 20, 2014 at 2:35 PM, peuramaki [email protected] wrote:
I wrote a little project that should reproduce the issue but it doesn't..
I've done some more debugging though. Apparently, using rabbit transport
and UseSingleBrokerQueue=true, NServiceBus.Address.Machine never gets used.
Instead, address to send messages is always defined in rabbit channel that
gets it from NServiceBus/Transport configuration. Am I correct?Current suspect for the cause of this issue is RabbitMqUnitOfWork -
sometimes message sending actions do get added to UoW, but are never run.Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-38166859
.
from nservicebus.rabbitmq.
Right. I was able to reproduce and "fix" the issue. Turned out that queries to SQL Server in sagas somehow messed up NSB transactions - sometimes transactions were never completed.
Apparently, NServiceBus.RabbitMQ sends messages when Transaction.TransactionCompleted event is raised. If transaction is not committed, messages are not sent. Probably works like it should, but an exception would be nice to get.
"Fixing" the issue involved changing depencency lifecycle of my SQL client component to 'single instance' - using 'instance per unit of work' leads to non-deterministic behavior. SqlConnection is created in components constructor and disposed in IDispose.Dispose().
The issue is reproduced at https://github.com/peuramaki/NServiceBus.RabbitMq.Issue22, please take a look.
To be honest, I don't know what actually causes the problem. Insight appreciated ;-)
from nservicebus.rabbitmq.
Yes we delay the sending until the tx completes to make it easier for you to handle the lack of DTC. Ie it avoid "ghost" messages to be published in case of a db rollback. To avoid that behaviour you can make sure that there no TransactionScope wrapping the handler by calling:
"Fixing" the issue involved changing depencency lifecycle of my SQL client component to 'single instance' - using 'instance per unit of work' leads to non-deterministic behavior. SqlConnection is created in components constructor and disposed in IDispose.Dispose().
What container are you using?
from nservicebus.rabbitmq.
The delaying thingy makes perfect sense. I'd just want to get exception if something goes wrong.
I need to have transactional message handlers, suppressing transactions is not an option.
I'm using default Autofac, but NHIbernate for saga persistence.
from nservicebus.rabbitmq.
I've continued investigations further with the issue.
It appears that when custom SQL queries to MS SQL Server (using SqlConnection) are made during the lifetime of a NServiceBus message handler, non-deterministic behavior is resulted. Sometimes ambient transaction is never committed, which results in NServiceBus.RabbitMQ never sending out messages that should be sent. That is because flushing of NSB's unit of work is bound to TransactionCompleted event, which sometimes never launhes.
I'm able to work around the issue the following way: instead of letting SqlConnection to automatically enlist to ambient transaction, I'm preventing it using 'Enlist=false' in connection string. I don't use System.Transactions at all with the SqlConnection, but I hook up SqlTransaction using NServiceBus'es IManageUnitsOfWork interface.
Maybe I should close this bug and open up a new one?
from nservicebus.rabbitmq.
Yes, please reopen another one!
Thanks!!
On Wed, Mar 26, 2014 at 12:54 PM, peuramaki [email protected]:
I've continued investigations further with the issue.
It appears that when custom SQL queries to MS SQL Server (using
SqlConnection) are made during the lifetime of a NServiceBus message
handler, non-deterministic behavior is resulted. Sometimes ambient
transaction is never committed, which results in NServiceBus.RabbitMQ never
sending out messages that should be sent. That is because flushing of NSB's
unit of work is bound to TransactionCompleted event, which sometimes never
launhes.I'm able to work around the issue the following way: instead of letting
SqlConnection to automatically enlist to ambient transaction, I'm
preventing it using 'Enlist=false' in connection string. I don't use
System.Transactions at all with the SqlConnection, but I hook up
SqlTransaction using NServiceBus'es IManageUnitsOfWork interface.Maybe I should close this bug and open up a new one?
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-38674858
.
from nservicebus.rabbitmq.
Closing this one, see #26
from nservicebus.rabbitmq.
Related Issues (20)
- Investigate if ability to provide a custom ArrayPool can provide any performance benefit
- Expose ConnectionFactory.MaxMessageSize on the transport configuration API
- Stopping an endpoint floods the log with "Reconnecting to the broker failed: System.ObjectDisposedException" HOT 1
- Add automated tests that runs against AmazonMQ
- Add automated tests that runs against CloudAMQP
- Endpoint never reconnects to RabbitMQ after channel timeout HOT 7
- Multi target commandline to net6, net7 and newer
- Retries of headerless message causes indefinite requeuing on classic queues HOT 5
- Message loss in migrate-to-quorum command HOT 3
- Automatic rate limiting feature might cause duplicate messages HOT 1
- nsbVersion can't be computed in single file deployments HOT 2
- Messages go into infinite immediate retries in case there are a lot of messages (over 100) with persistent issue while processing. HOT 5
- ChannelProvider Publish reconnection attempts continue forever after IEndpointInstance had been stopped HOT 9
- Suppress creation of `nsb.v2.verify-stream-flag-enabled` queue HOT 2
- Ability to not have the delayed delivery infrastructure created
- Should we expose a way to configure the Consumer Acknowledgement Timeout HOT 1
- Immediate retry count does not increase for rabbit messages which are sent to queue without "message_id" property after upgrade to NServiceBus 8 HOT 5
- Enhance code readability and using .NET 8 new features HOT 1
- Vulnerabilities in transitive dependencies HOT 1
- Easy way to configure Exchange names HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nservicebus.rabbitmq.