RSB - Is there some sort of default timeout of 10 minutes?

[Daventry]

Hi,

 

We've noticed that when our message is being processed, after 10 minutes the message is processed even though the first run hasn't errored. So they both run in parallel (because we have set the bus threadcount to 5).

If the first run finishes in less than 10 minutes, then we don't see such behavior.

 

We don't have this problem when threadcount is set to 1.

 

Regards.

[Corey Kaylor]

The TransactionScope timeout would be much sooner than 10 minutes. I'm not sure why you would be seeing this behavior. Which transport is being used?

--
You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/VvCvUP1WXI8J.
To post to this group, send email to rhino-t...@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.

[Daventry]

Hi Corey,

 

I think I replied just to you instead of posting to the group.

 

We're using Rhino Queues as transport. RSB version is 2.3.4.0

 

We're also supressing the TransactionScope because otherwise the DTC kicks in every time we open a second connection to a DB (which is SQL Server 2008 R2). I thought this was a SQL Server 2005 bug and should not happen in the 2008 version...

 

Thanks.

[Corey Kaylor]

DTC will kick in regardless due to Rhino.Queues participating in the distributed transaction. We're using almost the identical setup you describe minus the transaction supress and we have never seen this type of problem. I would look there first. Is it possible a connection to the database is opened prior to supressing the transaction?

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/nn1PmHy5Ir0J.

[Daventry]

No, the transaction suppression is the first line of code in our consumer.

[Corey Kaylor]

To be more specific, you're not doing anything with a unit of work in an IMessageModule?

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/qWwyRPUyj8cJ.

[Daventry]

No, we're not.

[nightwatch77]

That's quite bad that RSB cannot do transactional processing correctly. Fine if you can live with that but imho it should be safe by default.

And imho 10 minutes is way too long for a single transaction, especially a distributed transaction. If your processing takes so long you should probably use some long-running task for storing intermediate status, for example a saga.
And I confirm, there is a difference between SQL 2005 and 2008 in how they handle distributed transactions - in SQL 2005 you will be promoted to a distributed transaction if you open a second connection to same database inside a transaction scope. SQL 2008 will not use DTC in such case.

I've been fighting with transactional processing of messages for quite a long time and have even built an SQL-only message bus just to be able to guarantee ACID without resorting to DTC. It's nice to have it working but there are many pitfalls and if you can, it's better to avoid using DTC at all.

Best regards

RG

[Kaylor Mail]

We take pull requests.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/WZEpY0Z1ogoJ.

[miles]

I just got bitten by something which seems similar.

It seems there's a default timeout for transactions which is TransactionManager.MaximumTimeout and set at 10 minutes.  All system.transactions transactions have that as a maximum and it's only overrideable at the machine level:

http://social.msdn.microsoft.com/forums/en-US/adodotnetdataproviders/thread/91bab4ff-a8c9-426f-8766-f8873b392622

http://blogs.msdn.com/b/madhuponduru/archive/2005/12/16/504730.aspx

http://blogs.msdn.com/b/ajit/archive/2008/06/18/override-the-system-transactions-default-timeout-of-10-minutes-in-the-code.aspx

I'm hoping this will fix my problem...

Miles

[Daventry]

That worked, thanks!