Reverse Invoke Server Accumulating Connections

Hi,

I need help with setting up my internal IS 4.6 server with my RI IS 4.6 server.

As, I understood from these forums, I did the following:

  1. Scheduled wm.server.security.revInvoke:keepAliveConnections every 60 seconds.
  2. Scheduled services to:
    wm.server.remote:getServerAliases
    wm.server.security.revInvoke:listRegisteredConnections
    wm.server.security.revInvoke:registerReverseConnections
    • This solved my problem of the internal server loosing/dropping registered connections to the proxy.

However, I still have a problem that my Reverse Invoke server is STILL showing all connections. For example, if I loose 5 connections, and my internal connections registers 5 more (because they were dropped/lost), then my Reverse Invoke Server shows 10 registered connections.

And when our partners send transmissions, the RI server attempts to invoke services on the closed/dropped connections, and goes into “pending” status.

Can someone help me solve this? Is there a way for me drop all RI connections before registering new ones?

Regards

Jez

Check your “idle timeout setting” on the remote server definition on the RI server. I have seen this issue when the idle timeout was set to -1 (never timeout).

Let us know if that helps.

HTH,

Mark

Check this fix - available from webMethods: IS_4-6_Fix144.zip

Fix144 Readme
IS_4-6_Fix144_README.txt (3.3 k)

For IS 6.0.1 the corresponding fix is: IS_6-0-1_Fix81

FYI,
I submitted this problem to webMethods and received this response:
“… In general, when RepoV2 starts up, it searches for the WmRDBContainer table anywhere in the Oracle Instance. Not sure if you have tried connecting earlier to the same database with a different user for the repo, causing this table to be created initially. In case you then switched to another user, its possible that this table is still found in the database from the first user install of reposerver and it assumes that the RepoV2 tables are already there. However, when RepoV2 tries to do a select on the WmRDBContainer table it doesn’t find it amongst the tables of the new user causing the exception. …”

This, indeed, explained the cause of the exception, in my case. I was able to drop the old tables and was able to start the repov2 server without error.

Hi,

The “idle timeout was set to -1” solution doesn’t seem to work. I came to work on Monday, and noticed that the Proxy was still not dropping ‘dead’ connections.

I am also a little puzzled with Steps 3-4 of Fix144 patch:
>3. Create a stateless dummy service on the Internal Reverse Invoke
> Server.
I have to create a dummy service on the RI server, or my internal integration server?? Why do I need to do this

>4. Add the property below to the Proxy Reverse Invoke Server
> IntegrationServerdirectory/config/server.cnf file.
>
> watt.server.security.revInvoke.remoteSvc
>
> and specify the service created in step 3 for this property.
Why do I need to do this, when I am going to schedule: wm.server.security.revInvoke:checkRemoteConnections?

Can somebody please advise?

Thanks in advance,

Jez

Hi Jez,

The wordings in readme.txt are definitely confusing.

You should create a service without any steps on your internal server. This should be a stateless service.

You have to schedule wm.server.security.revInvoke:checkRemoteConnections on your reverse invoke server. wm.server.security.revInvoke:checkRemoteConnections reads watt.server.security.revInvoke.remoteSvc from the config file, makes one connection for each connection between rev/invoke and internal server, and tries to execute dummy service that you have created. If it fails, it would mark connection as dead and remove it.

Note: As per the code, if you have not configured watt.server.security.revInvoke.remoteSvc, it should call wm.server:ping. In case you do not want to create any dummy service, you can set watt.server.security.revInvoke.remoteSvc to wm.server:ping.

I hope this helps.

Hi Jez,

any reason for not registering with wmusers.com?

Thanks Chirag.

So, can I simply specify: “watt.server.security.revInvoke.remoteSvc=wm.server:ping”
or should I specify:
“watt.server.security.revInvoke.remoteSvc=http://internalServer:socketPort/wm.server:ping”?

In regards to not registering. Well, I am new to these boards (and also fairly new to webMethods). I will register shortly, and hope that I can also contribute.

Regards,

Jez

Jez,
You just specify:
“watt.server.security.revInvoke.remoteSvc=wm.server:ping”

Thanks John,

I will carry on monitoring, and see if this has solved the problem.

Hi All,

I am new to WebMethods.

We are also facing the same problem in our system.

In case the inactive connections are not dropped,and as per the code,wm.server:ping is called in case of using the inactive connections,will the server logs be populated with “[ISS.0036.0009E] Ping Failed”?