DriverTest.testConnect() is failing (on MacOS X) about pgjdbc-ng HOT 9 CLOSED

The failing test is actually testing "failover", the ability to pass in multiple addresses and have it try them until it connects to one. The first address should timeout and the second address should connect.

I'm running effectively the same setup. All tests are passing on my machine. What build of Java do you have?

It looks like, for this one test, your server address (besides invalidhost.not.here) is set somehow null. Can you please verify that is not the case (i.e. debug the specific test and see what the url you pass to getConnection is).

from pgjdbc-ng.

This is what the generated URL looks like:

jdbc:postgresql://invalidhost.not.here,localhost:5432/test

All other tests pass except for this one. I am running Java 1.7.0_45. The machine I am testing on is a MacBook Pro with 2.53GHz Core i5 (circa 2010), 8GB memory.

from pgjdbc-ng.

I was on Java 7 build 21, just updated to 45. I cannot seem to reproduce this. Do you have an interesting network setup? (e.g. maybe no "localhost" entry in /etc/hosts)

from pgjdbc-ng.

Another thing... Your stack trace implies a null address but the URL you posted clearly shows two non-null addresses. Please put a breakpoint on the first line of ProtocolFactoryImpl.connect and see if address is null. If address is not null, get its toString() and report back.

from pgjdbc-ng.

Here is what I have found debugging. The failure occurs during the connect attempt to host "invalidhost.not.here".

Going from button to top. At this point:

NioClientSocketPipelineSink.connect(NioClientSocketChannel, ChannelFuture, SocketAddress) line: 106 
NioClientSocketPipelineSink.eventSunk(ChannelPipeline, ChannelEvent) line: 69   
DefaultChannelPipeline.sendDownstream(ChannelEvent) line: 570   
Channels.connect(Channel, SocketAddress) line: 634  
NioClientSocketChannel(AbstractChannel).connect(SocketAddress) line: 207    
ClientBootstrap.connect(SocketAddress, SocketAddress) line: 229 
ClientBootstrap.connect(SocketAddress) line: 182    
ProtocolFactoryImpl.connect(SSLMode, SocketAddress, BasicContext) line: 92  

there is the line:

if (channel.channel.connect(remoteAddress)) { ...

remoteAddress.toString() shows "invalidhost.not.here:5432". This line throws java.nio.channels.UnresolvedAddressException ... with the source of the exception shown here:

java.nio.channels.UnresolvedAddressException
at sun.nio.ch.Net.checkAddress(Net.java:127)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:640)
at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink.connect(NioClientSocketPipelineSink.java:106)

To me, this all looks about as I would expect. The exception is caught on line 123:

} catch (Throwable t) {
    cf.setFailure(t);
    fireExceptionCaught(channel, t);
    channel.worker.close(channel, succeededFuture(channel));
}

which basically sets the failure into the ChannelFuture but then continues without error ... returning back to the line of code that invoked it here:

ChannelFuture connectFuture = clientBootstrap._connect(address)_.syncUninterruptibly();

As you can see, the ChannelFuture is returned by the connect() call (which now has the exception set on it), and then syncUninterruptibly() is called on it. That code looks like:

public ChannelFuture syncUninterruptibly() {
    awaitUninterruptibly();
    rethrowIfFailed0();
    return this;
}

The rethrowIfFailed0() call inspects the cause inside of the future and seeing that java.nio.channels.UnresolvedAddressException is a RuntimeException simply (re)throws it. This runtime exception is never caught by anything and therefore throws all the way out to the junit test harness.

Your code is only handling IOException and it's subclasses, and maybe you are getting a different exception, like UnknownHostException, but in my environment I am not getting UnknownHostException but rather UnresolvedAddressException which is not a subclass of IOException. I can't say there is anything strange about my network environment, other than both WiFi and ethernet are connected at the same time. Either way, I think your code should explicitly catch UnresolvedAddressException because it seems likely to be encountered in various environments in which your users are running.

Note the "null" part of the java.nio.channels.UnresolvedAddressException: null stack trace is not because address is null, but because UnresolvedAddressException is constructed with no message. So the message is null but not the address that was trying to be resolved.

from pgjdbc-ng.

For me, changing ProtocolFactoryImpl line 171 from:

catch (ChannelException e)

to

catch (ChannelException | UnresolvedAddressException e)

solves the problem.

from pgjdbc-ng.

Please test the fix in c3610ce

I chose to allow it to handle any Exception which, hopefully, will handle all random connection errors.

from pgjdbc-ng.

Thanks for the fix, I'll verify it at the office on Monday.

from pgjdbc-ng.

Confirmed.

from pgjdbc-ng.