I don't think its a good idea to use CS on a Windows based computer.

William

On Thu, Apr 28, 2011 at 10:55 AM, Kok_BG <kok_bg@...> wrote:

>
>
> I had the same issue today.
> This never happens with SS, recently i installed the classic to use the
> multicore hardware.
>
> Only reboot the server fixes the problem, and this occurs several times yet
> (after installing the CS).
>
> Any idea / help ?
>
> Thanks
>
>
> --- In firebird-support@yahoogroups.com, "s3057043" <s3057043@...> wrote:
> >
> > Hello Group,
> >
> > I have a customer who is encountering an unusual problem with Firebird
> 2.1.3 Classic Server on Windows 2008 R2.
> >
> > At some time this morning, our application froze on the server. Further
> investigation into this showed that it was the connection to the Firebird
> database that was causing the problem. We attempted to use several different
> applications (both internal and third party) to connect to the database with
> but without success. Even iSQL could not connect. iSQL froze for a number of
> minutes and the task had to be killed and the server restarted.
> >
> > There were a number of "INET/inet_error: read errno = 10054" and
> "SERVER/process_packet: broken port, server exiting" errors in Firebird.log
> around the time of the failure. These errors occur at other times as well,
> but are far more frequent after the failure before the restart. This may or
> may not be related.
> >
> > We took a tasklist on the server prior to restart, and there were about
> 800 fb_inet_server.exe processes. The tasklist indicated the memory usage
> for about 525 of these processes was below 4MB (300 were below 2MB). I
> didn't think to check whether the number of fb_inet_server.exe processes
> increased with every frozen connection but based on the load for that
> server, I only expected there to be around 250 attachments at this time. I
> am therefore suspicious that each of the connection attempts (eg iSQL above)
> was indeed spawning an fb_inet_server.exe instance but that something went
> wrong along the way.
> >
> > We confirmed (using telnet to port 3050) from one of the application
> servers that even when the database server was not completing the connection
> requests, the network connectivity to the Firebird port was working.
> >
> > My questions are:
> > Does anyone know what conditions might cause that a database connection
> may lock up during the connection in a way that would create an
> fb_inet_server.exe processes?
> > Are these errors in Firebird.log particularly concerning or just part of
> the "real world" networking environments?
> > Is there something else I should be looking into?
> >
> > Thanks in advance
> > Adam
> >
>
>
>


[Non-text portions of this message have been removed]