FTP connection fails then get resolved itself in channel monitoring in RWB

[Former Member]

Hi,

I have a scenario in PI where we are using FTP server to pick or place files. We have been facing this issue for very long time That the connection to server fails. The error message which comes to Channel monitoring is "Connection to server ftpABC failed".

But we never bothered much about it as it gets reolved itself that too with in minutes. But the problem is that we keep getting loads of tickets every month regarding this issue, which are consuming our time with out much purpose.

I want to know the exact reason why is this happening? Has anyone of you faced similar issue ? How did you resolve it ?

I am getting a probable explaination from my fellow team members that it occurs when a large number of messages come to one node simultaneously and that node gets clouted thus kinda gets hanged up...thus raising a tikcet saying "connection to server failed." (ofcourse during this bottleneck time only). Once the phase of these large number of messages passes the channel starts polling normally.

Is this a valid explaination ? if yes is there any way we can enhance/control this capacity of node to process large number of messages with out getting clouted.

I must mention here that no messages are failing in moni.

Regards

Saurabh

[Former Member]

Hi Saurabh,

can you pls let us know the below

message size

FTP connection active/passive

what is the FTP time out mentioned in the third party system

what is the processing mode and File type.

is there any proxy setup in your network

You mentioned, issue is resolving automatically, it means you might have mentioned timeout in the channel and threads are getting released automatically. pls check how many threads allocated?

PS: you can pull the network logs when the channel got failed, just to check any network issues

Cheers,

Hidayat

[Former Member]

Hi Hidayat,

Here are the specs you asked for:

1. I am not sure about message size I think its 5MB.

2. FTP connection is active.

3 FTP timeout is 1800 secs

4. Processing mode is "Delete" and File Type is .txt

5. Yes there is a proxy setup at receiver end.

6. There are 3 threads are allocated.

I am not sure if its a network issue because its been prevailing for more than a year, and I think network issues are temporary. I think Its failing on technical design specification front.

Regards

Saurabh

[Former Member]

Hi Saurabh,

if the issue is coming every day then  change the FTP time out to 120 sec.  check the behaviour of the channel, you can ask your basis team or if you have access then read the trace and log files.

when the issue occured, check whether the three threads are occupied?

Cheers,

Hidayat

[Former Member]

Hi Hidyat,

What will be the advantage of changing time out to 120 secs ?

And in case out of three thread if only one thread is occupied when this issue occurs whats the solution to divide this load to other threads as well that too...approx..equally. ?

[marksmyth]

Hello Saurabh,

If you have a high volume interface like this, you can increase the number of threads that are available to the File adapter receiver connections. See this blog for details on how to increase the values - Messaging System queue properties after XI 3.0 SP19 / XI 7.0SP11. If they are currently at the default value of 5, increase to 10 and see if this improves the situation.

You can also monitor the queues by following the steps in 1662269 How to Monitor the PI Adapter Framework queues.

Regards

Mark