c# - Azure Service Bus Client Connection Persistence -

i have below basic wrapper around azure service bus code using within worker role. servicebusclient instantiated each time worker role run; used access queue until there no remaining items left enumerate through.

public class servicebusclient : idisposable, iservicebusclient {     private const int default_wait_time_in_seconds = 120;      private const string service_bus_connection_string_key = "service.bus.connection.string";      private readonly messagingfactory _messagingfactory;      private readonly namespacemanager _namespacemanager;      private readonly queueclient _queueclient;      private readonly isettingsmanager _settingsmanager;      public servicebusclient(isettingsmanager settingsmanager, string queuename)     {         _settingsmanager = settingsmanager;          var connectionstring = _settingsmanager.getsetting<string>(service_bus_connection_string_key);          _namespacemanager = namespacemanager.createfromconnectionstring(connectionstring);         _messagingfactory = messagingfactory.createfromconnectionstring(connectionstring);          _queueclient = getorcreatequeue(queuename);     }      public void dispose()     {         _messagingfactory.close();     }      public brokeredmessage receivetopmessage()     {         return _queueclient.receive(timespan.fromseconds(default_wait_time_in_seconds));     }      public void sendmessage(object bodyobject)     {         var message = new brokeredmessage(bodyobject);          _queueclient.send(message);     }      private queueclient getorcreatequeue(string queuename)     {         var queue = !_namespacemanager.queueexists(queuename)                         ? _namespacemanager.createqueue(queuename)                         : _namespacemanager.getqueue(queuename);          return _messagingfactory.createqueueclient(queue.path, receivemode.peeklock);     }  } 

as can see initialise namespacemanager, messagingfactory , queueclient inside constructor: reused when calling sendmessage() , receivetopmessage() connection closed using dispose() method.

my question whether approach using safe; keeping single instance of queueclient open whilst worker role enumerates through messages on queue (a process keep connection open quite while long wait between calls receivetopmessage()) work consistently without transient issues, or prudent open , close connection each time?

as aside; how transient fault handling conducted in microsoft service bus code? conducted default or need implement transient fault handling framework?

the queueclient class uses connection managed messagingfactory object used create it. recommended reuse same client object multiple requests. documented in best practices performance improvements using service bus brokered messaging:

the service bus enables clients send , receive messages via 2 protocols: service bus client protocol, , http. service bus client protocol more efficient, because maintains connection service bus service long message factory exists. implements batching , prefetching. service bus client protocol available .net applications using .net managed api. (...) service bus client objects, such queueclient or messagesender, created through messagingfactory object, provides internal management of connections. should not close messaging factories or queue, topic, , subscription clients after send message, , re-create them when send next message. closing messaging factory deletes connection service bus service, , new connection established when recreating factory. establishing connection expensive operation can avoided re-using same factory , client objects multiple operations. (...) clients (senders in addition receivers) created same factory share 1 tcp connection.

regarding transient fault handling, queueclient has retrypolicy property that determines whether request should retried. there transient fault handling application block, supersedes transient fault handling framework.

regarding message receive loops, there guidance in implementing reliable message receive loops. microsoft has recognized it's hard implement well-writen, resilient message receive loop, have introduced event-driven message programing model alternative.