Are you using the PI Buffer Subsystem on the PI-to-PI interface node? Also, where is your PI-to-PI interface installed, on the source server?
Thank you for your comments.
I'm using the PI Buffer Subsystem on the PI-to-PI interface node.
PI-to-PI interface is installed on the source server.
I have a tech support case for this issue. (Case 810345)
The machine is getting this error.
Asynch read failed.  The semaphore timeout period has expired.
We have a KB for this issue.
KB01168 - Error: Asynch read failed.  The semaphore timeout period has expired.
>The error code "121" is a positive number which indicates it’s not coming from PI products.
I guess there is a possibility that cloud vendor changed the hosted place and it causes the issue.
In the community if someone has experienced the issue (cloud environment and 121 semaphore timeout), please share the knowledge.
Thank you for commets,
But KB01168 is not same issue with mine. Because KB01168 does not say about multiple PI to PI sessions.
>I guess there is a possibility that cloud vendor changed the hosted place and it causes the issue.
There are no pssiblilty that cloud vendor changed the hosted place .
Because I'm using AWS and AWS said that they will not move the server's location during the vurtual machine running.
1 of 1 people found this helpful
If you are experiencing the error that is reported above (121 - The semaphore timeout period has expired), this is not necessarily a PI issue but an issue with the network between the PItoPI interface node and the target PI Data Archive or with the NIC on the PItoPI interface node. As per the Microsoft KB article that is given in KB01168, it clearly states that this is a network connectivity problem, and this is an issue that must be dealt with on the network level (the transport layer) and not something that we can necessarily address directly in the interface.
You will need to potentially adjust the NIC settings on the interface node so that you can address this error properly. It may be possible that your VPN software creates a virtual NIC on the node itself, so the settings for that NIC would need to be tuned so that the timeouts do not occur. As stated in KB01168, please refer to the Microsoft KB for further information regarding this.
There is a Japanese version of this KB available as well.
Thank you for comments,
I already visited the web sites what you wrote. I'm understanding possibility of network connecting broblem.
But I could not understand why multiple PI to PI sessions are made.
Within the case 810345, I checked the interface machine's log.
It shows 2 errors.
Snapshot registration failed. [-10723] PINET: No Connection.
Connection to XXXX is bad: [-10734] PINET: Broken Connection.
After these 2 errors, 121 semaphre timeout was recorded.
So following happens.
1. The network problem happens (10723, 10734)
2. 121 semaphore timeout happens
3. Close connection
4. Create new connection
This is why multiple connection can be seen.
For deleting dead connection, you can refer to
Troubleshooting PI client connection problems - White Paper
Problems Related to Large Numbers of "Dead" connections
It suggests to set Keepalive, MaxConnIdleTime.