Non Authoritative Information in saga persister

[nordbergmikael]

Having ~7 sagas that all are started by the same message and a unique property, UId, in the saga data.
Data.UId = message.Id in saga handler.

1st run -> ok, 7 new sagas are created and stored in database.
2nd run -> In RavenSagaPersister.GetByUniqueProperty a call to Session.Load(lookupId) is made. In the Raven console GET request "loops" for ~20 sec then an "Non Authoritative Information" exception is thrown.

Less than 7 sagas works on my dev box.

[andreasohlund]

We need to check this against the latest raven

[andreasohlund]

Please recheck this simon

[SimonCropp]

@nordbergmikael I am having trouble reproducing this. Can you share the code that causes the problem?

[SimonCropp]

Since I cant reproduce this I am closing the issue. @nordbergmikael if you can provide a repro please re-open the issue

[leblancmeneses]

I got here from this post: "Multiple saga mapping of a single message"
http://stackoverflow.com/questions/11567706/multiple-saga-mapping-of-a-single-message

And have a related question:

What happens if an exception happens when initializing one of the sagas. The message will go into the error queue. If returned to source queue once the saga is fixed I'm guessing the unique property attribute will make sure 6 sagas are not started twice if currently running.

What if it already completed and user replayed (returned to source queue) do i need to maintain storage of saga name + [Unique] to avoid replay or does NServiceBus infrastructure handle this for us?

[danielmarbach]

That is handled by the infrastructure. The uniqueness information is kept in the storage. Only the data is removed

Am 13.01.2014 um 05:35 schrieb Leblanc Meneses notifications@github.com:

I got here from this post: "Multiple saga mapping of a single message"
http://stackoverflow.com/questions/11567706/multiple-saga-mapping-of-a-single-message

And have a related question:

What happens if an exception happens when initializing one of the sagas. The message will go into the error queue. If returned to source queue once the saga is fixed I'm guessing the unique property attribute will make sure 6 sagas are not started twice if currently running.

What if it already completed and user replayed (returned to source queue) do i need to maintain storage of saga name + [Unique] to avoid replay or does NServiceBus infrastructure handle this for us?

—
Reply to this email directly or view it on GitHub.

[leblancmeneses]

great - thanks. is there a term that describes the scenario I'm describing: reprocessing avoidance scenario?