[storm] Can't get the disconnection tests to run

[James Henstridge]

On Mon, Nov 9, 2009 at 11:14 PM, Jason Baker <jbaker at zeomega.com> wrote:
> Hey guys,
> I've been trying to split out a branch that contains the oracle backend
> that's up-to-date from trunk.  For whatever reason, I can't get the
> disconnection tests to work.  I've been running the tests two ways:
>  1. Using an Oracle TNS name (which looks up the hostname/port in a file).
>  In other words, a URI like this:
>     oracle://username:password@tns_name?tns=True
>  2. Specifying the port, hostname, and service identifier in the URI.  The
> URI looks like this:
>     oracle://username:password@hostname:port/SID
> Using both methods, I can get both the database tests and store tests to
> work.  However, I can't get the disconnection tests to pass.
> If I use #1, then the test just fails; a DisconnectError doesn't get raised.
>  It doesn't even appear that is_disconnect_error is ever getting called.  If
> I use #2, the test just hangs.  After doing some debugging, I've determined
> that it is getting hung up at this line of code in the proxy:
>     rlist, wlist, xlist = select.select(readers, [], [], TIMEOUT)
> ...which is strange because as far as I know, this shouldn't block.
> It makes sense that #1 would fail as the proxy server likely doesn't have
> anything to connect to.  However, I can't figure out why it's getting hung
> up.  Any ideas as far as where to begin?  Could something be configured
> incorrectly?  Does this sound like a non-storm issue (in other words, an
> Oracle issue)?

Sorry for taking a while to get back to you about this.

The tests in question should definitely be run with a URI containing a
hostname and optionally a port rather than any symbolic name.  Those
tests work on the assumption that (a) they can pull a hostname/port
out of the given URI and create a TCP connection to it, (b) they can
substitute in a new hostname/port into the URL and the database client
library will connect to that port and (c) the database client can
successfully communicate with the database when we're forwarding data
back and forward manually.

So the TNS name based URI definitely won't work unless you have some
way to map it to the correct hostname/port (you'd need to override
DatabaseDisconnectionTest.get_uri() in that case).

Next thing: are you sure that you are seeing a hang on that select
call?  That call should never last longer than 0.1 seconds, but I'd
expect that thread to spend most of its time in select calls (separate
ones).

James.