tag:blogger.com,1999:blog-15136575.post7298831428083079790..comments2023-10-17T12:00:16.772+01:00Comments on Code rant: EasyNetQ: Big Breaking Changes to Request-ResponseMike Hadlowhttp://www.blogger.com/profile/16441901713967254504noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-15136575.post-7067139318610655132014-03-16T10:25:10.140+00:002014-03-16T10:25:10.140+00:00I'm reluctant to change the API at this stage....I'm reluctant to change the API at this stage. I'm trying to stabilise things for a 1.0 release. But thanks, it's an interesting idea. I'm afraid there isn't any alternative to default timeout presently.Mike Hadlowhttps://www.blogger.com/profile/15393720749809796178noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-57090644960033364272014-03-15T01:48:37.308+00:002014-03-15T01:48:37.308+00:00Any chance you could add a Timeout value to the Re...Any chance you could add a Timeout value to the Request/RequestAsync methods? It's great to have a global timeout value, but in some cases, I know a specific message is going to take a while.<br /><br />Example:<br /><br />TResponse IBus.Request(TRequest req<b>, int? TimeoutMS=null</b>)<br /><br />with this, if the TimeoutMS value is null, you can use the global timeout, but if it's set, you can use the connection timeout.<br /><br />I'm using the Request/Response pattern a lot, usually with a single global IBus instance. Some responses come quickly, as the information needed to fulfill them is in memory. Other times there's a costly DB operation.<br /><br />I don't know if it's there and I'm missing it, or if there's a better way to do it. I definitely think being able to specify a per-Request timeout would be beneficial.Unknownhttps://www.blogger.com/profile/02418690694312270787noreply@blogger.com