Brendan,
It's scary how closely your situation mirrors what we encountered a few
months back... and i'm afraid I don't have a very positive answer for you.
Though the specific errors you are receiving are slightly different, I have
a feeling it's a similar problem... unfortunately, I can't remember the
exact error messages we were encountering.
Anyway, for us everything worked flawlessly until we did a little (and i
mean LITTLE) stress testing... connections would just start dying... without
being marked as such. We tried everything... on the phone wih Sybase tech
support for countless hours... they kept insisting that it was a problem
with our OS (linux) TCP/IP layer... lame explanation obviously... we tried a
packet sniffer to see if that would turn up anything... even got in touch
with Tim Bunce and Mike Peppler I believe... anyway, at the last minute, and
I do mean last minute, we ended up switching to mysql... fortunately, this
wasn't too difficult since we'd written a class to abstract away from the
DB... everything has been smooth sailing ever since... and we've saved a ton
in Sybase license fees.
The moral? I don't know... but just be ready for a battle.
Good luck.
JPS
> -----Original Message-----
> From: Brendan McAdams [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2001 5:22 PM
> To: [EMAIL PROTECTED]
> Subject: HELP: DBI Issues
>
>
> Hoping someone can help me; I'm working on rolling out a mod_perl
> rewritten release (to push some major performance increases on our
> application).
>
> It works *beautifully* - our performance increase is up to 300% over
> traditional CGI.
>
> Unfortunately one of our sysadmins discovered a problem when he was
> stress testing the system: If he clicks a link to one of the apps
> components several times in succession, sybase's connections start
> dying.
>
> We have tried this with and without apache::dbi running.
>
> As far as I can figure, what is happening is that when the client closes
> its end (when it requests the new report, aborting the previous one),
> mod_perl is terminating, but leaving the half processed result set
> hanging in sybase. Subsequent requests to Sybase start choking,
> although after several minutes (5-10) we see Sybase and mod_perl
> usually straighten themselves out; this is unfortunately unacceptable.
>
>
> I need to figure out a way to handle the possibility of a client abort,
> and gracefully close the result set (these are fairly large result sets
> being returned from a stored procedure) without choking sybase. This is
> a critical release and I need to get this resolved as quickly as
> possible.
>
> An example of sybase errors:
> [Fri Apr 6 17:02:50 2001] null: WARNING: Returning REPORT
> SPECIFICATION.
> [Fri Apr 6 17:02:50 2001] null: no statement executing at
> /usr/local/apache/lib/perl/Apache/MuniCenter/MuniTable.pm line 342.
> [Fri Apr 6 17:02:50 2001] null: DBD::Sybase::st fetchrow failed:
> OpenClient message: LAYER = (4) ORIGIN = (1) SEVERITY = (5) NUMBER =
> (28)
> [Fri Apr 6 17:02:50 2001] null: Message String: ct_fetch(): protocol
> specific layer: external error: There is a tds protocol error. An
> illegal token was received.
> [Fri Apr 6 17:02:51 2001] null: DBD::Sybase::st execute failed:
> OpenClient message: LAYER = (4) ORIGIN = (1) SEVERITY = (5) NUMBER =
> (28)
> [Fri Apr 6 17:02:51 2001] null: Message String: ct_results(): protocol
> specific layer: external error: There is a tds protocol error. An
> illegal token was received.
> [Fri Apr 6 17:02:51 2001] null: WARNING: Returning REPORT DETAILS.
> [Fri Apr 6 17:02:51 2001] null: no statement executing at
> /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBI.pm line 1093.
> [Fri Apr 6 17:02:51 2001] null: ct_cmd_alloc failed at
> /usr/local/apache/lib/perl/Apache/MuniCenter/MuniTable.pm line 329.
> [Fri Apr 6 17:02:51 2001] null: DBD::Sybase::st execute failed:
> OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER =
> (50)
> [Fri Apr 6 17:02:51 2001] null: Message String: ct_cmd_alloc(): user
> api layer: external error: The connection has been marked dead.
>
> Thanks,
>
> Brendan
>
> -----
> Brendan W. McAdams | [EMAIL PROTECTED]
> Senior Applications Developer | (212) 208-9116
> TheMuniCenter, LLC | www.themunicenter.com
>
> "Always listen to experts. They'll tell you what can't be done, and why.
> Then do it."
> - Robert A. Heinlein
Shop online without a credit card
http://www.rocketcash.com
RocketCash, a NetZero subsidiary
