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:
Thanks!
Tags:
Yes.....#1 is the pattern you should be following. just create it once...send many :)
Marty,
Is this safe to do concurrently from multiple threads?
Michael (whose reply is below) is suggesting a to use a Publisher pool.
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.
That's a good idea Michael, I will go down this path if Marty's idea doesn't pan out.
Thanks.
Neuron ESB Product Support Forums and Communities
© 2024 Created by Neuron Admin. Powered by