D
dbeavon
Guest
@onnodehaan ... I only heard about one other customer that encountered the same issue. And I only heard about it when I happened upon their KB article with the same symptoms. I suspect there are not many OE customers who actually use JMS in the first place. If it was more popular then Progress might not have unloaded the Sonic MQ product to Aurea. I think I agree with the Progress theory that the root cause might be related to a TCP transport issue in the third-party JMS library. The JMS specification itself doesn't seem to care about the wire protocol, or the TCP/IP layers ... so Progress really isn't able to care about those things either. There probably isn't any perfect way for the Progress "generic JMS" interface to interact with TCP/IP settings in a generic way (given that the underlying client library might be sonic or active mq or websphere or whatever).. My strategy now is to incorporate some additional TCP timeout settings to my connection string and then cross my fingers. These settings are supposed to impact the active mq client library that we are using today: "&soTimeout=60000&soWriteTimeout=60000" Hopefully that will reduce or eliminate the hangs. If the hangs continued then I suppose the next step would be to write a custom health-checker. It might do an "adaptman -query" on a regular basis and if there is anything that looks wrong, or hung, then we could kill off the whole broker-connect-mess and restart it again from scratch. Given that we have a busy and long-running PASOE service on that server, then we can't really afford any hangs, or leaked client connections within the adapter.
Continue reading...
Continue reading...