>gsndelphicoder wrote:
>
> >... I looked at the server log through IBConsole and it
> >was riddled with the following message:
> >
> >GEMTRAK (Server) Tue Jan 10 09:11:40 2006
> > SERVER/process_packet: broken port, server exiting
> >
> >Can anyone tell me what might be causing this error and if it is
> >likely the root of my slowness issues?

It indicates a server crash. Both the frequent crashing AND the poor
performance are MOST likely to be symptoms of unfavourable application code
and inappropriate indexing.

At 02:40 PM 11/01/2006 -0200, Ivan Cruz wrote:

> >
> >
>That error is related to the most likely cause: a network problem.
>Try changing cables and switch ports. Since everybody is
>experiencing slowness, start looking on server side of your
>network.

Not obviously hardware faults in this case. A broken port can mean a
network configuration fault, e.g. that the server's port (default port
3050) has been hijacked by another application (InterBase?) or that the
tcp/ip service has been compromised (faulty DHCP configuration?)

However, in such cases, it's fairly uncommon to get a useful (i.e.
server-generated or guardian-generated) message in the log. You'd normally
just see the network error. So it's useful that you are getting these
messages from the Guardian.

Since you say the log is "riddled" with this very message, it's likely that
your application code is causing the server to crash. The first place to
triage this problem will be calls to bad UDFs, either those written by
yourself or those written by third parties. When a UDF throws an unhandled
exception, it will crash the server. If you are using third-party UDF
libraries, examine your declarations of UDFs for situations where CSTRING
arguments are being passed and FREE_IT is not being invoked. I've seen
third-party UDF libraries where the provided SQL declarations omit this...

However, from your nickname, one supposes that you are writing applications
in Delphi. Therein lies a major trap. The default settings of many data
access component sets, notably those supplied by Borland (VCL/BDE, DBX and
IBX) will kill servers. It's essential to understand what's going on at
the server when you use these defaults, viz. transactions running in
so-called "Autocommit" mode and SELECT statements running interminably in a
read-write transaction...in short, memory resources will become exhausted
and the database itself will become overloaded with garbage that can't be
cleaned up. Depending on the volume of operations, the crash will take
from hours to days to occur, but occur it will.

Another trap for Delphi developers using Enterprise editions is that your
default "install-everything" for Delphi includes installing whatever
version of InterBase was shipped on the CD. This includes installing an
incompatible client (gds32.dll) in the system path of your development
server, hijacking port 3050 and starting up InterBase automatically at
boot-up. Delphi developers have been known to propagate this problem by
deploying the wrong client library into production, as well...

Add to that the possibility that multiple local application instances may
be accessing the database through the IPServer protocol ("Windows local
protocol", which Borland's components graciously make the default) and are
stamping all over the server's memory, and you have an ongoing support
nightmare.

If you graduated from a desktop database like Paradox or Access, it's
possible you think table components are an ideal way to access all database
engines. NOT. Table components are for desktop database
engines. Networked database engines require SQL and, invariably, serious
attention to any indexes that the database carried as cargo from the
desktop database.

So the Delphi side of things can be a can of worms for performance and
stability. If you are only beginning to appreciate the issues surrounding
the multi-generational architecture and a transactional DB engine, then the
application code is quite likely to be in need of serious review.

./heLen