Leonardo Rochael Almeida writes:
 > On Mon, 2002-02-25 at 05:44, Dieter Maurer wrote:
 > > We use Zope 2.5 together with ZEO 1.0b5 and there seems to be
 > > a problem with the communication between Zope and ZEO.
 > > 
 > >   Several times a day, Zope reports that it has been disconnected form
 > >   storage (a warning), that it tries to reconnect but fails
 > >   due to "error 131, 'Connection reset by peer'".
 > If your ZEO Client (ZC) is behind a masquerading firewall or other NAT
 > (with your ZEO Server (ZS) on the other side, obviously) you might be
 > getting a timeout from your firewall. If the ZC doesn't communicate with
 > the ZS for some time, the masquerading firewall might lose track of the
 > connection and when the ZC finally sends some data, the firewall sends
 > back an ICMP packet to the effect: 'Connection reset by peer' because it
 > doesn't know what the ZC is talking about.
Thank you for your suggestions!

There is indeed a firewall between ZC and ZS, although it does no
masquerading or NAT. But, the problem usually happens when load
is light. Therefore, your assumption may be true that the problem
happens when "ZC doens't communicate with the ZS for some time".

 > >   ZEO on the other hand reports that it had opened the connection
 > >   and keeps it open until Zope stops.
 > The ZS will never know about the closed connection because (I believe)
 > it only sends data closely after the ZC sends data (so the firewall
 > knows the connection and won't complain).
 > If this is the case, you might want to increase the timeout on your
 > firewall or find a way to make the ZC talk to the ZS regularly so as to
 > keep the connection alive (it would be ideal if the ZEO protocol had a
 > keep-alive or PING or noop command that could be regularly sent down the
 > wire).
I think, it has a "noop".


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to