Stipe Tolj skrev: > Alexander Malysh schrieb: >> As far as I know it only happens on SMPP connections with receiver and >> sender thread (not transceiver). Is it correct? >> If yes, then we need to investigate this bug first or disable 2 Threads >> (sender and receiver) and force users to use 2 SMPP connection groups >> (one for receiver and one for sender). > > yep, I can confirm this as seen on some production (high load) systems. > > The effect can be described as following: > > - A SMPP connection that uses 'port' and 'receive-port' in the smsc group. > - Which means we have 1 TCP connection for the transmitter session, and 1 TCP > connection for the receiver session. > - Due to architecture design, a "smsc" can have only 1 state. Normally this > would be "online" internally, so the abstraction layer of bearerbox will > consider in it's routing decision this as a valid route. > - Now, the magic part: We get a so called "silent TCP teardrop", which means > the > TCP connections are "semantically disconnected" by a middle router, but the > TCP > end-points (server, client) don't get a corresponding TCP drop packet. In this > state we (Kannel) "believes" we're still connected. If we use enquire_link > PDUs > to ensure we "are" connected, we will notice we're not and drop the TCP > connections, trying to re-establish the connection. > - The "fun" thing is: if the TCP teardrop happens only for the transmitter > session, the receiver session will still keep getting enquire_link_resp PDUs > back from the SMSC side and keep the overall module state in "online", and > hence > the transmitter part is NOT re-establishing the connection. > - The result: we end up in a transmitter session that seems "online" from the > perspective of the abstractive bearerbox layer, so it WILL route MTs this way, > and we keep pushing them into the "lost sink". > > What we need to check is the state handling here. > > @Arne: is this pretty much the behavior you have also being faced with?
Yes, it happens exactly like that. I have a monitoring service witch reports it being "online", but no messages get sent from the queue. Arne -- -------------------------------- Arne K. Haaje | www.drx.no T: 69 51 15 52 | M: 92 88 44 66 --------------------------------
