We receive error message "RWF Error rsslInitChannel, RSSL Error Code -1, System Error Code 11, Text = <Impl/ripcsrvr.c:2119> Error: 1002 Could not read IPC Mount Request. System errno: (11), rsslInitChannel fail”. We have traced this to the load balancer sending heartbeats/ACK/keep alive messages. We think UPA handles these like they are a UPA Client program connecting, and when these get to our code we see it as an error, with the above error message returned from the UPA API. The same happens when a telnet connection is established to the same port which the application is listening to.
If there is content being sent to a port that is using our UPA protocols, the content should also be using UPA’s protocols. Anything that would cause one of the sockets to believe there is I/O activity will result in triggering the application to read or accept (and the OS to read the bytes that triggered the notification (regardless of what they came from). When these are processed and interpreted by UPA, it does not recognize them so it throws them away and returns an error because an error has occurred.
This is similar for any protocol built on a socket connection. If you send random byte streams to an FTP server, it will also report similar errors as it will not recognize the FTP protocol it is expecting on that socket.
Our transports are built to leverage its optimized protocols, and if components are attempting to send other formatted content (telnet, load balancer, etc) to these sockets, these rogue components should be reconfigured or be disabled.
For interactive provider on Redhat Linux 6/7 upa8.0.0.L1.linux.rrg, is there a limit to the configuration parameter, maxfragmentsize? In our config value is 64K (65536). However, on connection ADH, we the value down-graded to default.