Ok, here is the problem. We register 8 reverse invoke connections with the external Proxy server. This works fine. So, by time morning comes around, the connections have disappeared. So, we lose data trying to come in. So, this just started a month ago and we have not made any change to production. We are running Server version 4.0.2 and Trading Networks version 4.5.1
The servers are running on Windows environment both external and Internal server. So the log file reveals that the connections are being deleted…
- 2002-10-10 07:45:11 00800103D Exception in
SocketLink receive:Connection reset by peer:
- 2002-10-10 07:45:11 00800104D Closing
SocketLink to endpoint:moin24.pitts.bayer.com:8484
- 2002-10-10 07:54:29 00790101V Unable to
register Reverse Connection with alias:moin24
- 2002-10-10 08:16:09 00800101V SocketLink
successfully created to
So, HELP…what is happening???
Network services is saying that they did nothing. But what could they have done to cause webMethods to lose its proxy connections???
We encounter similar problem now and then.
Did you find why? and do you have a solution.
We would greatly appreciate if you can share with us.
We occassionally have the exact same issue. The reverse proxy connections disappear. We utilize IS 4.6. Have you found resolution with webMethods? Any info would be great.
We have seen this as well. There are a lot of reasons why this could happen but generally speaking if you are going through a firewall, it times out and drops the connection due to inactivity. There can be other reasons as well and finding the exact reason can be time consuming and fruitless. We found that the best solution for us is to write a scheduled service that at an interval goes out removes the connection(s) and then adds them back. We have found this to be very reliable and that way you know the connections are up. The keep alive service provided by webMethods doesn’t seem to work 100% of the time.
So if you code something like, getNumConnections, deleteConnection, registerReverseConnections. Not the ideal solution but it does work and we haven’t had any problems with it.
The connection between Reverse Invoke Server in DMZ and Internal server
will not be stable and it will go away.
Eventhough if you have a dummy service goes between Internal server and
Reverse invoke server for every 30 seconds the connection will die.
we worked with webM and we could not solve it.
use third party Reverse proxy , do not use webMethods IS as reverse
proxy. we are using network appliance Reverse proxy.
We used a similar approach to Mark’s… We defined a property in the server.cnf file that contains the number of connections to keep open. We then built a scheduled task/service that reads the property and verifies that the appropriate number of connections exist. If they don’t, it restarts them and sends an alert e-mail.
There are two benefits to this approach… the first is that there is never a period when the reverse invoke connections are gone (which happens if you delete and restart all of them).
The second benefit is when you restart the Reverse Invoke server, you don’t need to worry about restarting the connections when the RI box comes back up. The scheduled task will do it for you.
The connections may be getting deleted due to:
- Firewall and other network devices dropping connections.
- connections timing out(Especially the missing connections we find in the morning. Since there is no activity during night…)
We use the approach suggested by Josh. And it works, when connections are dropped.
What I have been facing is: Connections are dropped, and detected by RI Server and not detected (show as still connected) by Internal Server.
I had also faced issue when connections were dropped and not detected by RI Server, internal server detected it. We have implemented a fix provided by webMethods support and it seems to be working for a while.
There should be a built in scheduled task on the IS box that runs a ping over the reverse invoke connections. That should detect any bad connections. It works the same way as the webMethods fix does. You may want to verify that the scheduled task is running correctly, and on a timely basis.