Re: Kannel 1.4.2 out

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
--------------------------------