| Subject | Re: [IBO] Problem with TIB_Events |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-06-10T01:06:13Z |
At 11:42 PM 9/06/2004 +0000, you wrote:
connection, since the server needs to open a separate network "channel"
between a matching pair of ports on the client and the server.
Currently you're getting the AV in the nptdll.dll library, which is a set
of routines Windows uses to analyse the available ports. Because your Win
Local connection is operating in shared interprocess communication space,
the client and server parts of this IPC space are overwriting one another
with these calls.
The first thing to try is using cpTCP_IP and the localhost server. From
memory (notoriously faulty!!) this ought to work - the network layer can
"cook" a pair of ports within the TCP/IP local loopback structure to
simulate the event channel and allow the event mechanism to work with a
local client.
Now, it's possible you'll still get a problem with Fb 1.5.0, although the
AV will show up in a different place - events will work but you might get
an AV when the client disconnects, and crash the server. That's because Fb
1.5 server has (by default) abandoned the Dummy Packet method of polling
clients, relying instead on the network's own KeepAlive
protocol. (DummyPacketInterval causes more problems than it solves on
networks!) If that's the case, you could hold your breath for Fb 1.5.1,
which has a reimplementation of the server's timing for checking for lost
connections.
I have to admit I haven't tested events on a local machine for a year or
two and not at all with Fb 1.5. (My setup here is all client/server). I
don't have time to do it at present, either.
I do think it's likely to be relevant to IBO's DML Caching if it turns out
that Fb 1.5 doesn't support events for a local client, so please let us
know how things go with events using local loopback.
XP itself also reputedly has a bug with TCP/IP connection timeouts that
probably won't manifest itself locally (but who can tell?) I'm on Win2K
here so I can only pass on hearsay. Theoretically, if there is a too-long
lapse between the client signaling that it is listening and the database
returning the event notifications (which occurs on commits) XP might have
dropped the event channel.
Helen
>Hey! I just ordered your book!OK. cpLocal is no good for events. The event mechanism needs a network
>
>Anyway, the protocol is cpLocal.
connection, since the server needs to open a separate network "channel"
between a matching pair of ports on the client and the server.
Currently you're getting the AV in the nptdll.dll library, which is a set
of routines Windows uses to analyse the available ports. Because your Win
Local connection is operating in shared interprocess communication space,
the client and server parts of this IPC space are overwriting one another
with these calls.
The first thing to try is using cpTCP_IP and the localhost server. From
memory (notoriously faulty!!) this ought to work - the network layer can
"cook" a pair of ports within the TCP/IP local loopback structure to
simulate the event channel and allow the event mechanism to work with a
local client.
Now, it's possible you'll still get a problem with Fb 1.5.0, although the
AV will show up in a different place - events will work but you might get
an AV when the client disconnects, and crash the server. That's because Fb
1.5 server has (by default) abandoned the Dummy Packet method of polling
clients, relying instead on the network's own KeepAlive
protocol. (DummyPacketInterval causes more problems than it solves on
networks!) If that's the case, you could hold your breath for Fb 1.5.1,
which has a reimplementation of the server's timing for checking for lost
connections.
I have to admit I haven't tested events on a local machine for a year or
two and not at all with Fb 1.5. (My setup here is all client/server). I
don't have time to do it at present, either.
I do think it's likely to be relevant to IBO's DML Caching if it turns out
that Fb 1.5 doesn't support events for a local client, so please let us
know how things go with events using local loopback.
XP itself also reputedly has a bug with TCP/IP connection timeouts that
probably won't manifest itself locally (but who can tell?) I'm on Win2K
here so I can only pass on hearsay. Theoretically, if there is a too-long
lapse between the client signaling that it is listening and the database
returning the event notifications (which occurs on commits) XP might have
dropped the event channel.
Helen