Hi!
I'll do some test in the line of what you are suggesting.

I know for a fact that only java via interserver on linux dies.

Connections are dying when idle for a few minutes.

Connections doesn't break under use so there is nothing to log.
I am trying to use them and they are not valid anymore so I have to start new
ones.

Consistency: Same no matter if db is local or remote.

What do you think about my ideas that there is a libc/jdk issue or maybe there
can even
be something wrong with our switching hubs connecting the server/client???

Thanks!
//OLAS



David Jencks wrote:

> 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/
> >
> >
> >
> >
>
>
> 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/