Hi David

Quick mail just to let you know that we've resolved the connection
problem.

It was actually more an xinetd/inetd issue, where the daemon was
limiting the number of connections that could be made to a port in a
minute. As expected once this limit was increased connections were no
longer lost. This solution was required for the classic server, however
I also installed the super server which doesn't use xinetd/inetd and
runs as a daemon itself. Again as expected with this setup no
connections were lost. May be we should include these findings in some
documents somewhere or is it the case that they already exist and we
didn't bother reading them :)

Regards
Mandip

David Jencks wrote:

> Actually all the code up to executeQuery did not require a db connection,
> so it only tried to get the db connection when that statement was reached.
>
> I just committed a change that gets a db connection when a
> ManagedConnection is created: this will be when not enough are pooled to
> satisfy a request for a Connection.
>
> I think your investigations pretty clearly show that for some reason you
> aren't able to connect to the server. I'd start by adding a log statement
> so you can see the IOException. Hopefully this will give a clue- this
> should be logged anyway-- I'll add it to cvs.
>
> Are all the connections for the same user, password, and other properties?
>
> Thanks
> david jencks
>
> On 2002.03.21 13:02:35 -0500 Mandip S. Sangha wrote:
>
>>Hi David
>>
>>The code being executed for every query is:
>>
>> Class.forName (driverClass).newInstance();
>> connection = DriverManager.getConnection (url,properties);
>> statement = connection.createStatement();
>>(1)
>>(2)
>>resultSet = statement.executeQuery(sqlString);
>>
>> resultSet.close();
>> resultSet = null;
>>
>> statement.close();
>> statement = null;
>>
>> connection.close();
>> connection = null;
>>
>>I've got a sys.out at point (1) that checks:
>>a) Whether the connection is null.
>>b) Whether the connection is closed.
>>BOTH RETURN FALSE even when the error in question is thrown!
>>
>>When the error is thrown the code fails at point (2), as far as I can
>>see(from the above checks) the connection and statement are fine up to
>>this point
>>
>>Therefore, am I correct in assuming that the error cannot be thrown
>>because we "can't get a connection" or the "connection died and the
>>driver didn't notice".
>>
>>If not please can you tell me how to check the connection really is
>>valid and is open.
>>
>>Otherwise that leaves the possibility of "the server dying", if I've
>>understood correctly what you mean by this then this is not an issue
>>since there has never been an instance where the error has actually
>>crashed/stopped/shutdown the database server. Also the database server
>>that I connect to is running locally eliminating any problems that could
>>be caused by sending things over the wire.
>>
>>This leads me back to the error:
>>
>>[GDS_Impl,DEBUG] Got socket
>>[GDS_Impl,DEBUG] user.name: mandip
>>[GDS_Impl,DEBUG] op_connect
>>[GDS_Impl,DEBUG] sent
>>[GDS_Impl,DEBUG] op_accept
>>[FBManagedConnectionFactory,ERROR] GDS Exception in getDbHandle
>>org.firebirdsql.gds.GDSException: unable to complete network request to
>>host
>> at org.firebirdsql.jgds.GDS_Impl.connect(GDS_Impl.java:1304)
>>
>>Looking at the connect method in the GDS_Impl class we see:
>>
>> :
>> :
>> db.out.writeInt(3); // ptype_batch_send
>> db.out.writeInt(2);
>> db.out.flush();
>> if (log.isDebugEnabled()) {log.debug("sent");}
>>(1)
>>if (log.isDebugEnabled()) {log.debug("op_accept ");}
>>(2)
>>if (readOperation(db) == op_accept) {
>> db.in.readInt(); // Protocol version number
>> db.in.readInt(); // Architecture for protocol
>> db.in.readInt(); // Minimum type
>> if (log.isDebugEnabled()) {log.debug("received");}
>> }
>>(3)
>>else {
>> disconnect(db);
>> if (log.isDebugEnabled()) {log.debug("not received");}
>> throw new GDSException(isc_connect_reject);
>> }
>> } catch (IOException ex) {
>> throw new GDSException(isc_network_error);
>> }
>>
>>Everthing executes fine up to point (1) as reflected by the log message,
>>but after this things become unclear, can we determine at exactly what
>>point the exception is thrown?
>>
>>Again your comments/suggestions would be greatly appreciated. :-)
>>
>>Regards
>>Mandip
>>
>>
>>
>>
>>
>>David Jencks wrote:
>>
>>
>>>Either you can't get a connection due to misconfiguration or the server
>>>dying or a connection died and the driver didn't notice. Due to
>>>
>>adapting
>>
>>>firebird to xa semantics the driver doesn't actually make a connection
>>>until it knows what transaction you are working in.
>>>
>>>Do some of your tests succeed?
>>>Does some test before the one that fails in this way do something that
>>>might break the connection?
>>>If you are using the built in pooling, try turning it off and see what
>>>happens: if you aren't, you might try turning it on;-)
>>>
>>>david jencks
>>>
>>
>>
>>
>>To unsubscribe from this group, send an email to:
>>Firebird-Java-unsubscribe@yahoogroups.com
>>
>>
>>
>>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>>
>>
>>
>>
>>
>>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>