If an FTP session fails and is not logged out, webMethods maintains these sessions until they timeout or the server is restarted. These sessions can be seen by calling the “sessioninfo” flow. My question is how would you remove a session manually if you do not know what the session key was?
Thanks,
Dave
I am also having the same issue… How can you clean up or run some sort of garbage collection on the open FTP sessions… Leaving these sessions open causes problems for us… Any ideas??
Sort of the same thing for us. We have a reverse invoke scenario with incoming ftp’s. Our two internal servers are clustered. Each time someone ftp’s to the reverse invoke server and the request comes to the internal servers, it creates a “Licensed Session” on the internal server. Even with a good logout (from the ftp client), the licensed sessions do not let go. They grow until they reach our licensing limit and we have to restart the servers to reset the number.
Anyone seen this type of situation?
We have the same problem over here. Lots of ftp services hanging up until a server restart.
I was thinking it could be something to do with my flow implementation and exception handling. But, if you have the same problem it seems wM could have some bug.
Fabiano
More info on this. If this is true, this is extremely poor design on WM’s part. Each service should have it’s own FTP session object independent of any others.
> When you develop IS integrations using webMethods FTP services, please be
> aware that there are issues with how webMethods implements their session
> objects. Any new FTP session will use an existing session (if one
exists)
> - there will not be a unique session object for each FTP connection. If
> one of the threads finish the data transfer before any other thread which
> use the same session object and issues a logout, that session object is
> essentially lost and all other threads that use the same FTP session
object
> will fail.
>
> webMethods states this is not a bug and behaves as expected. This I
> disagree with! How do you explain this when I received the same session
ID
> when I separately invoke the login service in every thread. It’s my
> understanding that webMethods is implicitly caching this session object
> resulting in this race condition. So, if you are developing FTP
> integrations for Wave 4, please be aware of this condition and workaround
> this issue, as I needed to do with the SSCS interfaces.
Guys,
Use the ftp flow steps pub.client.ftp:login
Always use the timeout parameter to make sure that the flow
step does not hang around forever waiting for a responce.
Make sure that what every happens the flow step
pub.client.ftp:logout is run.
You must trap all errors and still run the logout.
Eitherwise you leave the ftp session open.
Or the next time you login via ftp it will connect to the
already open session, and all the returncode value will be
different. e.g. not 220 for connected.
Cheers,
Simon
Simon, this still doesnt address the issue of sharing FTP sessions across IS… We have cases where 2 interfaces will run at the same time using the same user ID into the same server, just looking for different files… One ends before another, or one uses the filenamepattern of the other causing us numerous errors… Is there a fix for this???
Jim,
Does this only happen when the service is run from the scheduler?
It depends which service you use to log on. If you use ftp services in WmEDIforTN package, you will experience the problem you explained.
The ftp services in WmEDIforTN package, will cache the session info for given server/user
If you use ftp services in WmPublic package you should be fine, as every time you login it creates new session id.(Verify this by running WmPublic/pub.client.ftp:login two times consecutively)
If you don’t log out it will leave the connection open, until timout. But it will not interfere with other sessions as Jim was witnessing.
I don’t believe it is poor design from wM part. We just need to do proper house keeping. However, pub.client.ftp:sessionInfo could have been developed to return more info like line session id, session open time and last activity using that session id etc. That would have made cleaning up sessions more easier.