Mailing List CGatePro@mail.stalker.com Message #99918
From: Wayde Nie <wayde@nie.ca>
Subject: Re: Bouncing off Blackberry users
Date: Tue, 13 Apr 2010 09:41:08 -0400
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
X-Mailer: CommuniGate Pro WebUser v5.2.18
Hi John,

I'm not sure if BB isn't pinging every now and again to maintain the
channel... I don't recall any other connections being so 'long-lived',
however, I admit to not looking too hard lately. I have up'd the log
level and I'll see what I get.

re: upping the IMAP channels... That's been our 'strategy' to date...
However, we're up to 3500 and are approaching the point where we may
need to increase it again (increasing number of support calls about
IMAP connection issues).

We know we can't support 3500 active IMAPs, so, we're a bit concerned
that as we continue to increase it further, we'll hit a point where we
get into trouble if a significant number of BB idlers were to wake up.
(ie; a message to a large distribution group, or other such alignment
of the planets...)

Thanks,
Wayde.

On Tue, 13 Apr 2010 12:36:43 +0300
 John Kougoulos <koug@intracom.gr> wrote:
Hi,

Have in mind this from RFC3501 section 5.4:
5.4.    Autologout Timer

   If a server has an inactivity autologout timer, the duration of that
   timer MUST be at least 30 minutes.  The receipt of ANY command from
   the client during that interval SHOULD suffice to reset the
   autologout timer.

In a small test I did, it looks that my cgpro server (5.2.11)
disconnects idle sessions after 30 minutes.

In case you want to use a proxy for these connections and possibly violate the RFC you can try perdition, but in this case you will lose logging on the cgpro logs and your availability will depend on the status of the perdition process. Another alternative would be to implement such functionality through iptables/netfilter, though I'm not sure if it is possible.

Why don't you increase the imap channel limit?

Regards,
John


Wayde Nie wrote:
We're running a fairly recent v5.2.12. We're 'off-peak' hours at the
moment and we've got 1150 IMAP connections in 'idling' mode. In our
experience a lot of these (possibly most) are Blackberry's. They keep us
running up close to our IMAP channel limit though-out most of our
daytime.

I wonder if there's something that can be done to migrate IDLE IMAP
connections off to an IDLE queue. If they wake up, or there's something
to say to them, they could be moved back to the active queue, if the
active queue has any room... Not sure if it's the right way to handle
it, but the current situation soaks up all of our channels and
interactive IMAP users start receiving errors when their clients are
unable to connect to a channel...

Anyone else seen this behaviour? Have a way to fix it?

Wayde.

On Mon, 2010-04-12 at 17:41 -0700, W Sanders wrote:
We are seeing 750+ active established IMAP sockets that never disconnect, all from our Blackberry users. Looks like the Blackberry does not disconnect after it is done polling the server, unlike well-behaved software like Thunderbird.




#############################################################
This message is sent to you because you are subscribed to
 the mailing list <CGatePro@mail.stalker.com>.
To unsubscribe, E-mail to: <CGatePro-off@mail.stalker.com>
To switch to the DIGEST mode, E-mail to <CGatePro-digest@mail.stalker.com>
To switch to the INDEX mode, E-mail to <CGatePro-index@mail.stalker.com>
Send administrative queries to  <CGatePro-request@mail.stalker.com>

--
Wayde Nie.
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster