Since we migrated to PASOE from classic appserver we had to exchange the "clientconnect" (symbiont) JMS connections for "brokerconnect" connections that go thru a central java process.
This "brokerconnect" adapter is a centralized point of failure. All agent processes and sessions are relying on the "brokerconnect" adapter process when they are exchanging messages with a remote JMS resource.
Since it is a critical component of a PASOE server, is there any HealthScanner mechanism available to monitor this "brokerconnect" adapter? An unhealthy adapter can cause problems that quickly extend to PASOE as well.
Ideally there would be some healthscanner mechanism that would effectively call "adaptman -query" and look for servers that were unresponsive and then cycle them or else cycle the entire adapter process. Better yet, Progress should consider bringing back "clientconnect" for independent and reliable JMS interactions with remote JMS resources.
Any tips would be appreciated. I suppose it may be possible for us to implement our own healthscanner that parses the output from "adaptman -query". But it seems that other customers would benefit if it was built into the OE product itself.
Right now there is no support from PASOE to get sonicMQ adapter health check information. However you can raise a new enhancement request. knowledgebase.progress.com/.../P11255
Right now there is no support from PASOE to get sonicMQ adapter health check information. However you can raise a new enhancement request. knowledgebase.progress.com/.../P11255
Thanks,
I think the design of that IDEAS forum is being revisited. I may use it again once that happens. As it is now, I already have some ideas out there that are a higher priority and I don't want to muddy the water.
I suppose other customers or partners will run into this at some point on PASOE.... And maybe the reliability issues will be addressed at that time.
I also suspect that most customers running PASOE on windows are probably not using the Progress "ubroker generic adapter" at all. I suspect they are making use of the CLR-Bridge to connect directly to a messaging broker via stomp or an AMQP assembly or an NMS assembly. We may abandon the "generic adapter". I'm happy this "generic adapter" component was enabled for use by PASOE sessions, since it simplified our migration, but it seems to have been an afterthought. (The configuration of it was pretty irregular. Our configuration of that on our appserver hosts is still not 100% right. For example, we don't see it in the OEE console even though all the adaptman commands work fine. But this is another story. )
I have also contacted tech support. We have gathered the details about a specific example where the brokerconnect adapter became hung and caused the connected clients to keep their record locks for an afternoon.