Hi,
what you are seeing is radically different from anything I have experienced
with any version of interclient.

As I mentioned, my connections break after several hours, not minutes. The
pool I use seems to have no problem discarding broken connections and
replacing them immediately with new working ones.

Can you tell us...

Are the connections breaking under use or when they are unused for several
minutes?

Can you write a simple non pooling program that gets a connection and holds
onto it, and tests to see if it works after various periods of time? (such
as having a gui with a button, and you do the timing).

If you are using the connections when they break, can you log all the sql
sent from interserver to interbase? Is there some consistency in what is
happening when they break?

(maybe someone knows another way to log sql, I put

errorLog(sqlString);//uncomment to log all sql statements executed


as the first line of IB_Statement.cpp methods preparenoinput and
preparenoinputnooutput)

does this happen consistently on several machines with interbase,
interserver, interclient and your client program all on the same machine?

Thanks
David Jencks

On 2001.04.15 16:27:05 -0400 Ola Samuelson wrote:
> Hi!
>
> > hours (overnight, 8 hours or so) of disuse the connections break, so
>
> In my case it's a matter of a few minutes and after that the connections
> are lost which means new ones has to be created. But creating
> new ones while old ones are "dying" takes "forever". I goes real fast to
> create
> like
> 10 connections the first time.
>
> I have a connection pool which tries to revive the connections but
> even with this the connections that I am reviving(restarting)
> are slow. Also, Interserver processes related to dead connections
> are not returning memory.
> So after a while I have like a few megs avail even with no heavy load.
> I have 512M in the system and after starting all processes the first
> time some 35megs are occupied.
>
> So the server is spiraling down :-(
>
> It does not matter if they are constantly used or not.(If i remember
> correctly)
>
> I only use get meta data when starting the connection pool to get number
> of allowed connections.
>
> I have not got a clue what's going on.
> 1. Connections are dying after a few minutes
> 2." connection.isclosed()" does not really tell me if it is closed or
> not. I
> worked a bit better when I did dummy reads to check
> the state of the connection. But this cost to much time.
> 3. I am using a pool which many have tried and are extremely happy with.
> AND I
> have tried others as well. So my guess it's not that.
> 4. Even with a pool full of what is supposed to be available connections
> - at
> time of use the connection is found dead and
> a new one needs to be created. Creation of new ones at this point in time
> takes
> 30 secs sometimes.
> 5. there has been some spurious exceptions indicating inability of IC to
> resolve database url
>
> Could it be a glibc/jdk/interclient combination problem?
> I think I have tried them all by now.
>
> Right now I am on:
> glibc 2.1.3-22(original was 2.1.3-21)
> JDK 1.2.2_007(tried all 1.2's from blackdown and suns 1.3.0_02)
> Apache Jserv 1.1.2 (got from CVS)
> Apache JSSI 1.1.2
> Intel PIII SMP machine based on RH6.1 with all updates
>
> Same behavior even with the db locally so I guess it's not a network
> problem.
> I have tried setting various tcp parameters with sysctl and it did seem
> to
> improve things
> a bit since it kills connections in fin_wait state sooner. And the
> interserver
> processes
> related to dead connections are reported to be in state fin_wait or
> time_wait.
>
> Detail: NIC is Intel EEPRO 100 with Donald Beckers driver from february I
> think.
>
> I did compile interserver from cvs a few weeks ago and used it in
> conjuction
> with
> interclient.jar supplied by Joe Shevland(interbase2000.org).
>
> No difference .........
>
> Like I said I have tried the db locally no change but the current one
> is behind a firewall with filtering and portforwarding allowing 3050/tcp
> to pass between the machines. The server is running IB 6.01CS on linux
> smp 2.2.18 kernel. It all worked better when we ran IB 5.6 - on the
> server
> but we need the 6.01 features so...... Any server side configs that
> enables
> a remote interserver to work better?
>
> I find it confirmed after going through and following IC newsgroups and
> mailinglists for more than 18 months that there are at least three
> problems
> with all downloadable versions of interclient/interserver:
> 1. Dying connections - seen a lot of mail about that one
> 2. Interserver eating memory
> 3. Inablility to use more than ~20 connections under Linux.
> True or false?
>
> Sorry for my ramblings - ask away if I am being unclear!
>
> Ideas or questions?
> Many thanks in advance.
> //OLAS
>
> PS.
> One thing I have noticed: I get a "SIGPIPE" error thrown by
> the servlet engine if I transfer more than a few K's from over the
> connection.
> And this ONLY happens when accessed with Netscape over the web.
> Not with IE. I don't know if it's related in any way.
>
>
>
>
>
>
> >
> > although I encourage you to try my changes I doubt they will completely
> fix
> > the problem. I haven't put up a compiled version, I was waiting for
> > someone to try it out on windows, and got involved in some other stuff.
> > You can check out the 2.0 source and find the ant build script in the
> > firebird directory. Let me know if you have any problems.
> >
> > Can you be more specific about what is happening? How long before the
> > connections break? Are you using them all the time or are there long
> > periods of doing nothing? The problems I know about happen after long
> > periods of disuse. The problems I fixed were primarily that the
> > DatabaseMetaData.getTables(...) call immediately crashed interserver.
> If
> > you are using metadata methods it is very possible that my fix will
> help.
> >
> > Thanks
> > David Jencks
> >
> > On 2001.04.13 16:46:28 -0400 Ola Samuelson wrote:
> > > Hi!
> > > Sure will try everything ..............
> > >
> > > Where did you say I can find the updated interclient?
> > > TIA
> > > //OLAS
> > >
> > > ft@... wrote:
> > >
> > > > I think there was a confirmed bug relating to this on Firebird
> > > > Sourceforge site (Interbase shuts connection down without informing
> > > > Interserver). However, the Firebird Interclient 2.00 has been
> updated
> > > > extensively by David Jencks and can be compiled for Linux. There is
> a
> > > > new Ant build.xml that makes it easy to build the jar and the
> > > > Interserver executable. This version needs user feedback before
> > > > general release so why not try it.
> > > >
> > > > Fred
> > > >
> > > > --- In IB-Java@y..., Ola Samuelson <ola@d...> wrote:
> > > > > HI!
> > > > > Tried them all ..............JDK's, operating systems,
> interclient
> > > > kits.
> > > > >
> > > > > This happens:
> > > > > Connections are dying or getting stale after just a few minutes.
> > > > > Netstat says WAIT on connection between java/interserver.
> > > > >
> > > >
> > > >
> > > > To unsubscribe from this group, send an email to:
> > > > IB-Java-unsubscribe@egroups.com
> > > >
> > > >
> > > >
> > > > Your use of Yahoo! Groups is subject to
> > > http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > IB-Java-unsubscribe@egroups.com
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > >
> >
> >
> > To unsubscribe from this group, send an email to:
> > IB-Java-unsubscribe@egroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Java-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>