Publisher.SendXml seems slow...

[Scott Roberts]

We're noticing when we try to call Neuron to send a message with the Neuron SDK that it takes about 3 seconds to Connect and Send the message (code below).

using (var publisher = new Publisher())
            {
                publisher.Connect();
                publisher.SendXml("sync.out", xmlDoc, "http://www.w3.org/2001/XMLSchema-instance");
            }

Our monitoring tool shows all of these calls being made from the above operation.

Neuron.Esb.EsbService.IESBConfigurationService.GetZone()
Neuron.Esb.EsbService.IESBConfigurationService.GetOsMajorVersion()
Neuron.Esb.EsbService.IESBConfigurationService.IsSubscriberAnonymous()
Neuron.Esb.EsbService.IESBConfigurationService.SignonAnonymous()
Neuron.Esb.EsbService.IESBConfigurationService.GetEnvironmentMetabase()
Neuron.Esb.EsbService.IESBConfigurationService.GetActiveDeployment()
Neuron.Esb.EsbService.IESBConfigurationService.SignIn()

Neuron.Esb.EsbService.IESBManagementService.SubscriberDisconnect()

On our local instances and our deployed servers, we see this call taking 1-3 seconds everytime we try to send a message.  If we just create one Publisher and share it between multiple threads (ASP.NET Web Requests), we notice that it only takes 0.2 seconds to SendXml.  As such, we have the following questions:

1. Is the Publisher class thread safe, so that we can use the Publisher as a singleton, calling Connect only once, and have individual threads only call SendXml?
2. If not, how else can we make this call faster, so that it's not necessary to perform all of these calls every time we want to send a message (e.g. cache metabase)?

Thanks!

[Martin Wasznicky]

Yes.....#1 is the pattern you should be following.  just create it once...send many :)

[Daniel Gabriel]

Marty,

Is this safe to do concurrently from multiple threads?

Michael (whose reply is below) is suggesting a to use a Publisher pool.

[Michael Collins]

The Publisher class can be shared between threads, but I wouldn't necessarily recommend doing so. Under the hood, the Publsher class is using WCF to communicate with the topics and calls will be serialized over the WCF channel when called from multiple threads. When connecting and disconnecting rapidly like your example, that can be problematic obviously because each connection has to re-establish the ESB session and download the configuration data for the server that the client application is connecting to.

For ASP.NET, I would recommend creating an object pool with established Publisher objects that are connected to the service bus. For each request, you can retrieve a Publisher object from the pool, publish your message, and then release the Publisher back to the pool. This would probably be the most efficient solution and would allow for more concurrent processing versus sharing a single Publisher object across multiple ASP.NET requests.

[Daniel Gabriel]

That's a good idea Michael, I will go down this path if Marty's idea doesn't pan out.

Thanks.