| Subject | Re: [IBO] Events: app freezes when registering events |
|---|---|
| Author | Helen Borrie |
| Post date | 2006-12-13T11:50:35Z |
At 10:11 PM 13/12/2006, you wrote:
environment to change suddenly. It will be something recent, e.g.
someone installed something that uses (or blocks) port 3051 (if that
was configured as RemoteAuxPort at the time)
This is a good time to be asking about this as I'm just working on
the release notes for Firebird 1.5.4. This problem has been
addressed by backporting the fix for it from Fb 2.0. Here's a "more
or less" of the text that will appear in the v.1.5.4 release notes:
"In previous versions of Superserver, if the server could not
establish a socket for events, e.g. a firewall prevented the event
port from being opened at the server side, the server would hang when
a client attempted to register for an event. Connected clients would
stop responding and new connections would be blocked.
Now, under these conditions, the client will hang until the socket
call times out (by default, 10 seconds) and then the server will
respond to the isc_que_events() call by throwing the exception
isc_net_event_connect_err, "Failed to establish a secondary
connection for event processing" and will continue to serve user
requests normally."
Can I just suggest that, if you are going to use a static
RemoteAuxPort parameter, you choose a high-numbered port? e.g. 13000
is easy to remember if you need to troubleshoot. (Don't use 13050 if
you have someone using IBExpert Live on your network!)
The problem with using the lower-numbered ports is the seriously high
likelihood of conflicting with their usage by another application.
Helen
>I realise this is not strictly IBO releated...OK, it looks as if *something* is causing the event traffic
>
>They are running Windows 2000 server. My app connects to port 3050
>and 3051 for events (I've changed firebird.conf). The strange thing
>is the application was working fine, then on Sunday it froze at 2pm.
>Only a server reboot would allow my app to run again.
>
>On Monday, the same thing happened at 1pm.
>
>On Tuesday, the same thing happened at 12 noon.
>
>...strange pattern, runs for 23 hours then pop!
>
>When the app freezes whilst registering the events, the server appears
>fine, CPU usage is normal etc. They have looked in the server event
>logs (there's nothing in the firebird log) and found an error just
>prior to the client freeze, something about Windows being unable to
>upload the registry file. I'm looking into this.
environment to change suddenly. It will be something recent, e.g.
someone installed something that uses (or blocks) port 3051 (if that
was configured as RemoteAuxPort at the time)
This is a good time to be asking about this as I'm just working on
the release notes for Firebird 1.5.4. This problem has been
addressed by backporting the fix for it from Fb 2.0. Here's a "more
or less" of the text that will appear in the v.1.5.4 release notes:
"In previous versions of Superserver, if the server could not
establish a socket for events, e.g. a firewall prevented the event
port from being opened at the server side, the server would hang when
a client attempted to register for an event. Connected clients would
stop responding and new connections would be blocked.
Now, under these conditions, the client will hang until the socket
call times out (by default, 10 seconds) and then the server will
respond to the isc_que_events() call by throwing the exception
isc_net_event_connect_err, "Failed to establish a secondary
connection for event processing" and will continue to serve user
requests normally."
Can I just suggest that, if you are going to use a static
RemoteAuxPort parameter, you choose a high-numbered port? e.g. 13000
is easy to remember if you need to troubleshoot. (Don't use 13050 if
you have someone using IBExpert Live on your network!)
The problem with using the lower-numbered ports is the seriously high
likelihood of conflicting with their usage by another application.
Helen