{"action":"created","issue":{"url":"https://api.github.com/repos/rebus-org/Rebus/issues/564","repository_url":"https://api.github.com/repos/rebus-org/Rebus","labels_url":"https://api.github.com/repos/rebus-org/Rebus/issues/564/labels{/name}","comments_url":"https://api.github.com/repos/rebus-org/Rebus/issues/564/comments","events_url":"https://api.github.com/repos/rebus-org/Rebus/issues/564/events","html_url":"https://github.com/rebus-org/Rebus/issues/564","id":191104289,"number":564,"title":"Timeout Manager questions","user":{"login":"stevengopmo","id":14218631,"avatar_url":"https://avatars.githubusercontent.com/u/14218631?v=3","gravatar_id":"","url":"https://api.github.com/users/stevengopmo","html_url":"https://github.com/stevengopmo","followers_url":"https://api.github.com/users/stevengopmo/followers","following_url":"https://api.github.com/users/stevengopmo/following{/other_user}","gists_url":"https://api.github.com/users/stevengopmo/gists{/gist_id}","starred_url":"https://api.github.com/users/stevengopmo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stevengopmo/subscriptions","organizations_url":"https://api.github.com/users/stevengopmo/orgs","repos_url":"https://api.github.com/users/stevengopmo/repos","events_url":"https://api.github.com/users/stevengopmo/events{/privacy}","received_events_url":"https://api.github.com/users/stevengopmo/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-11-22T19:39:02Z","updated_at":"2016-11-22T20:50:00Z","closed_at":"2016-11-22T20:50:00Z","body":"Hi,  I have a number of timeout manager questions.  Probably some could be opened as separate issues and I will if you would like.  Here they are in no particular order.\r\n\r\n- does the external timeout manager for 2.x still work as described in your long ago posts on it (http://mookid.dk/oncode/archives/3421)\r\n\r\n- having asked that, do I understand correctly that the external manager just sends the message back to the appropriate place when the timeout occurs?\r\n\r\n- reading the docs it appears SQL Server does not require a timeout manager because SQL transport has built-in message deferral (#555).  It seems this should be possible for any of the database based transports, true?\r\n\r\n- You have storage for RavenDB but it does not include a Transport.  Is there a particular issue or just time?\r\n\r\n- I'm using the in-memory timeout manager with RavenDB as storage.  It seems that that timeouts are removed from storage before processing is complete and in the case of an error or shutdown of the service the 'next' timeouts are lost.  For example my code gets the timeout tries to do some processing then sets another timeout. but for some reason I no longer see the timeouts in the db.  Now that I've type it all, it sounds maybe my code problem :)\r\n\r\n- This last may be an edge case...  I'm using RavenDB for storing my timeouts and it depends on a store singleton (my DI container is SimpleInjector).  The store has a Listener that depends on something that is context specific.  In this case the specific details of the principal retrieved from details in the message.  Is there a place where I can capture the request for the timeout manager so I can begin the execution scope and pass it the specific principal I need?  I hope that makes sense."},"comment":{"url":"https://api.github.com/repos/rebus-org/Rebus/issues/comments/262361608","html_url":"https://github.com/rebus-org/Rebus/issues/564#issuecomment-262361608","issue_url":"https://api.github.com/repos/rebus-org/Rebus/issues/564","id":262361608,"user":{"login":"mookid8000","id":32968,"avatar_url":"https://avatars.githubusercontent.com/u/32968?v=3","gravatar_id":"","url":"https://api.github.com/users/mookid8000","html_url":"https://github.com/mookid8000","followers_url":"https://api.github.com/users/mookid8000/followers","following_url":"https://api.github.com/users/mookid8000/following{/other_user}","gists_url":"https://api.github.com/users/mookid8000/gists{/gist_id}","starred_url":"https://api.github.com/users/mookid8000/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mookid8000/subscriptions","organizations_url":"https://api.github.com/users/mookid8000/orgs","repos_url":"https://api.github.com/users/mookid8000/repos","events_url":"https://api.github.com/users/mookid8000/events{/privacy}","received_events_url":"https://api.github.com/users/mookid8000/received_events","type":"User","site_admin":false},"created_at":"2016-11-22T20:50:00Z","updated_at":"2016-11-22T20:50:00Z","body":"> Probably some could be opened as separate issues and I will if you would like.\r\n\r\nNah, I'll just answer them here quickly 😄 \r\n\r\n> does the external timeout manager for 2.x still work as described in your long ago posts on it (http://mookid.dk/oncode/archives/3421)\r\n\r\nyes and no ... there's no ready-made timeout manager anymore, because each Rebus endpoint can work as a timeout manager now.... if you want a dedicated timeout manager, just start an \"empty\" endpoint and treat it like your dedicated centralized timeout manager, because that will be it then\r\n\r\n> having asked that, do I understand correctly that the external manager just sends the message back to the appropriate place when the timeout occurs?\r\n\r\nyes... to be more precise, the timeout manager will return the message to the queue specified by the `rbs2-return-address` header, which by default will be the input queue of the sender, _unless you explicitly set it something else_ (which is how you can send delayed messages to other queues) \r\n\r\n> reading the docs it appears SQL Server does not require a timeout manager because SQL transport has built-in message deferral (#555). It seems this should be possible for any of the database based transports, true?\r\n\r\nI guess that is true... however, if the database happens to support some kind of pessimistic locking, that makes it much easier to share a timeout storage... e.g. if multiple timeout managers are using the same table in a central SQL Server, they will NOT snatch each other's timeouts because the SQL Server timeout manager will grab a lock on the rows \r\n\r\n> You have storage for RavenDB but it does not include a Transport. Is there a particular issue or just time?\r\n\r\nMostly because RavenDB does not support any kind of pessimistic locking. Competing consumers (even just multiple threads in the same process competing for messages) would snatch each other's messages.\r\n\r\nThe RavenDB timeout manager has this \"problem\" too, so it will NOT work with multiple timeout managers sharing the same RavenDB database.\r\n\r\n> I'm using the in-memory timeout manager with RavenDB as storage. It seems that that timeouts are removed from storage before processing is complete and in the case of an error or shutdown of the service the 'next' timeouts are lost. For example my code gets the timeout tries to do some processing then sets another timeout. but for some reason I no longer see the timeouts in the db. Now that I've type it all, it sounds maybe my code problem :)\r\n\r\nyeah well.... I am pretty sure that [this code](https://github.com/rebus-org/Rebus.RavenDb/blob/master/Rebus.RavenDb/Timouts/RavenDbTimeoutManager.cs#L48-L75) defers the deletion of the timeout documents until AFTER the due messages have been sent\r\n\r\n> This last may be an edge case... I'm using RavenDB for storing my timeouts and it depends on a store singleton (my DI container is SimpleInjector). The store has a Listener that depends on something that is context specific. In this case the specific details of the principal retrieved from details in the message. Is there a place where I can capture the request for the timeout manager so I can begin the execution scope and pass it the specific principal I need? I hope that makes sense.\r\n\r\nit sounds a little bit involved... but yet, all incoming messages are passed through the [incoming messages pipeline](https://github.com/rebus-org/Rebus/wiki/Incoming-messages-pipeline) which you can inspect by [logging its contents](https://github.com/rebus-org/Rebus/wiki/Log-message-pipelines) and then you can [inject a step into it](http://mookid.dk/oncode/archives/3938) that establishes whichever context is required"}}
{"actor":{"display_login":"mookid8000"}}