Hi guys,
  I've written quite a few integration tests around our zookeeper
functionality.  However I find I'm having a really hard time testing edge
cases that are caused by ConnectionLossException and
SessionExpiredException.  Is there any good way to simulate these events in
an embedded zookeeper runtime and then ensure a new client is created?

Thanks,
Todd

I recently used iptables on Linux to test these edge cases:

You just drop all traffic to the zookeeper server ip/port:
"iptables -D OUTPUT -p tcp -dport 2181 -j DROP"
then you wait a couple of seconds (longer than the session expiration
value, depends on your configuration) and then remove this iptables
rule again. The ZK Client library will reconnect and will receive
SessionExpired.

Not sure your embedded zookeeper is used via tcp, but you could always
test with a standalone zookeeper server.

Thijs

On Thu, Jun 16, 2011 at 12:37 PM, Todd Nine <[EMAIL PROTECTED]> wrote:
> Hi guys,
>  I've written quite a few integration tests around our zookeeper
> functionality.  However I find I'm having a really hard time testing edge
> cases that are caused by ConnectionLossException and
> SessionExpiredException.  Is there any good way to simulate these events in
> an embedded zookeeper runtime and then ensure a new client is created?
>
> Thanks,
> Todd
>

--
Thijs Terlouw,
Shenzhen, China
http://www.startinchina.com

The other method which is used in the ZK test cases is to make a second
connection with the same session id and then close that session.  This
causes the first connection to get a session expiration.

On Thu, Jun 16, 2011 at 7:59 AM, Thijs Terlouw <[EMAIL PROTECTED]>wrote:

> I recently used iptables on Linux to test these edge cases:
>
> You just drop all traffic to the zookeeper server ip/port:
> "iptables -D OUTPUT -p tcp -dport 2181 -j DROP"
> then you wait a couple of seconds (longer than the session expiration
> value, depends on your configuration) and then remove this iptables
> rule again. The ZK Client library will reconnect and will receive
> SessionExpired.
>
> Not sure your embedded zookeeper is used via tcp, but you could always
> test with a standalone zookeeper server.
>
> Thijs
>
> On Thu, Jun 16, 2011 at 12:37 PM, Todd Nine <[EMAIL PROTECTED]> wrote:
> > Hi guys,
> >  I've written quite a few integration tests around our zookeeper
> > functionality.  However I find I'm having a really hard time testing edge
> > cases that are caused by ConnectionLossException and
> > SessionExpiredException.  Is there any good way to simulate these events
> in
> > an embedded zookeeper runtime and then ensure a new client is created?
> >
> > Thanks,
> > Todd
> >
>
>
>
> --
> Thijs Terlouw,
> Shenzhen, China
> http://www.startinchina.com
>

See https://issues.apache.org/jira/browse/ZOOKEEPER-829

On Thu, Jun 16, 2011 at 1:16 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> The other method which is used in the ZK test cases is to make a second
> connection with the same session id and then close that session.  This
> causes the first connection to get a session expiration.
>
> On Thu, Jun 16, 2011 at 7:59 AM, Thijs Terlouw <[EMAIL PROTECTED]
> >wrote:
>
> > I recently used iptables on Linux to test these edge cases:
> >
> > You just drop all traffic to the zookeeper server ip/port:
> > "iptables -D OUTPUT -p tcp -dport 2181 -j DROP"
> > then you wait a couple of seconds (longer than the session expiration
> > value, depends on your configuration) and then remove this iptables
> > rule again. The ZK Client library will reconnect and will receive
> > SessionExpired.
> >
> > Not sure your embedded zookeeper is used via tcp, but you could always
> > test with a standalone zookeeper server.
> >
> > Thijs
> >
> > On Thu, Jun 16, 2011 at 12:37 PM, Todd Nine <[EMAIL PROTECTED]>
> wrote:
> > > Hi guys,
> > >  I've written quite a few integration tests around our zookeeper
> > > functionality.  However I find I'm having a really hard time testing
> edge
> > > cases that are caused by ConnectionLossException and
> > > SessionExpiredException.  Is there any good way to simulate these
> events
> > in
> > > an embedded zookeeper runtime and then ensure a new client is created?
> > >
> > > Thanks,
> > > Todd
> > >
> >
> >
> >
> > --
> > Thijs Terlouw,
> > Shenzhen, China
> > http://www.startinchina.com
> >
>

On Thu, Jun 16, 2011 at 6:51 AM, Jared Cantwell
<[EMAIL PROTECTED]> wrote:
> See https://issues.apache.org/jira/browse/ZOOKEEPER-829
>

Would be great if someone could finish this one. because...

> On Thu, Jun 16, 2011 at 1:16 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>
>> The other method which is used in the ZK test cases is to make a second
>> connection with the same session id and then close that session.  This
>> causes the first connection to get a session expiration.

I started seeing problems with this approach in 3.3.x release - due to
the addition of "session moved" handling. iirc there's a timing issue
where

1) A connects
2) A' connects
3) A gets disconnected due to session moved handling
4) A reconnects (automatically)
5) A' gets disconnected

I saw this on some tests, typically it was fine, but on some slow
machines (esp vms) the timing was such that this occurred and caused
the test to fail.

Patrick

re: https://issues.apache.org/jira/browse/ZOOKEEPER-829

I can see about submitting an updated patch.  I think we have one floating
around that we might not have submitted.  We definitely don't have any time
to see this through right now though.  However, we do use this approach in
our testing, so it is a valid approach.

~Jared

On Thu, Jun 16, 2011 at 11:24 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:

> On Thu, Jun 16, 2011 at 6:51 AM, Jared Cantwell
> <[EMAIL PROTECTED]> wrote:
> > See https://issues.apache.org/jira/browse/ZOOKEEPER-829
> >
>
> Would be great if someone could finish this one. because...
>
> > On Thu, Jun 16, 2011 at 1:16 AM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> >
> >> The other method which is used in the ZK test cases is to make a second
> >> connection with the same session id and then close that session.  This
> >> causes the first connection to get a session expiration.
>
> I started seeing problems with this approach in 3.3.x release - due to
> the addition of "session moved" handling. iirc there's a timing issue
> where
>
> 1) A connects
> 2) A' connects
> 3) A gets disconnected due to session moved handling
> 4) A reconnects (automatically)
> 5) A' gets disconnected
>
> I saw this on some tests, typically it was fine, but on some slow
> machines (esp vms) the timing was such that this occurred and caused
> the test to fail.
>
> Patrick
>