After the code block I quoted, there is this line:
event->rvnt_id = stuff->p_event_rid;
Which makes a already reused event to be reassigned another id.
Later, engine calls the callback and remote respond both events with the
same id.
Adriano
Em 09/04/2017 16:33, Adriano dos Santos Fe
Vlad,
I think have found the problem in server.
Look at this:
ISC_STATUS rem_port::que_events(P_EVENT * stuff, PACKET* sendL)
{
...
Rvnt* event;
for (event = rdb->rdb_events; event; event = event->rvnt_next)
{
if (!event->rvnt_iface)
Mark and Vlad,
So far, I can see that when the problem start to happen, server stopped
to receive op_que_events from client.
Adriano
--
Check out the vibrant tech community on one of the world's most
engaging tech sites
On 9-4-2017 16:07, Vlad Khorsun wrote:
> 09.04.2017 13:00, Mark Rotteveel wrote:
>> On 2-4-2017 15:23, Vlad Khorsun wrote:
>>> 02.04.2017 14:59, Mark Rotteveel wrote:
> ...
Any thoughts or ideas on this, or is it better if I just create a bug
report?
>>>
>>> Ideally, reproducible test
09.04.2017 13:00, Mark Rotteveel wrote:
> On 2-4-2017 15:23, Vlad Khorsun wrote:
>> 02.04.2017 14:59, Mark Rotteveel wrote:
...
>>> Any thoughts or ideas on this, or is it better if I just create a bug
>>> report?
>>
>> Ideally, reproducible test case needed. As simple, as possible. Also, we
>>
On 2-4-2017 15:23, Vlad Khorsun wrote:
> 02.04.2017 14:59, Mark Rotteveel wrote:
>> To come back to this again, there seems to be a concurrency bug in
>> events posted by Firebird to the client. It looks like it overwrites
>> local event ids (shared buffer, race condition?).
>>
>> This is triggered
