On 2-4-2017 16:48, Vlad Khorsun wrote:
> 02.04.2017 17:15, Mark Rotteveel wrote:
>> On 2-4-2017 15:23, Vlad Khorsun wrote:
>>> Ideally, reproducible test case needed. As simple, as possible. Also, we
>>> could log every packet related to events on server side.
>>>
>>>> Other example: both A and B are acknowledged with id of event B:
>>>
>>> Provide, please, op_que_events contents to confirm this.
>>
>> In this example event A (which should have id 212) is posted with the id
>> of B (213)
>>
>> [V10AsynchronousChannel]Queue event: WireEventHandle:{
>> name:TEST_EVENT_A, localId:212, eventId:0, internalCount:245,
>> previousInternalCount:245 }
>> [V10AsynchronousChannel]Queue event data:
>> 000000300000000000000012010C544553545F4556454E545F41F500000020200000000000000000000000D4
>> [AbstractWireOperations]readStatusVector arg:isc_arg_gds int: 0
>> [AbstractWireOperations]readStatusVector arg:isc_arg_gds int: 0
>> [V10AsynchronousChannel]java.nio.HeapByteBuffer[pos=0 lim=44 cap=2048]:
>> 000000340000000000000012010C544553545F4556454E545F427C00000000000000000000000000000000D3
>> [V10AsynchronousChannel]Received event id 211, eventCount 124
>> [V10AsynchronousChannel]Queue event: WireEventHandle:{
>> name:TEST_EVENT_B, localId:213, eventId:0, internalCount:124,
>> previousInternalCount:124 }
>> [V10AsynchronousChannel]Queue event data:
>> 000000300000000000000012010C544553545F4556454E545F427C00000020200000000000000000000000D5
>> [AbstractWireOperations]readStatusVector arg:isc_arg_gds int: 0
>> [AbstractWireOperations]readStatusVector arg:isc_arg_gds int: 0
>> [AbstractWireOperations]readStatusVector arg:isc_arg_gds int: 0
>> [V10AsynchronousChannel]java.nio.HeapByteBuffer[pos=0 lim=44 cap=2048]:
>> 000000340000000000000012010C544553545F4556454E545F41F700000000000000000000000000000000D5
>> [FBManagedConnection]End called: Xid[1299800912]
>> [AbstractWireOperations]readStatusVector arg:isc_arg_gds int: 0
>> [V10AsynchronousChannel]Received event id 213, eventCount 247
>> [V10AsynchronousChannel]Queue event: WireEventHandle:{
>> name:TEST_EVENT_B, localId:214, eventId:0, internalCount:247,
>> previousInternalCount:247 }
>> [V10AsynchronousChannel]Queue event data:
>> 000000300000000000000012010C544553545F4556454E545F42F700000020200000000000000000000000D6
>> [AbstractWireOperations]readStatusVector arg:isc_arg_gds int: 0
>> [AbstractWireOperations]readStatusVector arg:isc_arg_gds int: 0
>> [AbstractWireOperations]readStatusVector arg:isc_arg_gds int: 0
>> [V10AsynchronousChannel]java.nio.HeapByteBuffer[pos=0 lim=44 cap=2048]:
>> 000000340000000000000012010C544553545F4556454E545F427D00000000000000000000000000000000D5
>> [V10AsynchronousChannel]Received event id 213, eventCount 125
>
> So, we have following packets exchange
>
> 1. op_que_event TEST_EVENT_A, cnt = 0xF5 (245), id = 0xD4 (212)
> 2. op_event TEST_EVENT_B, cnt = 0x7C (124), id = 0xD3 (211)
> 3. op_que_event TEST_EVENT_B, cnt = 0x7C (124), id = 0xD5 (213)
> 4. op_event TEST_EVENT_A, cnt = 0xF7 (247), id = 0xD5 (213)
> 5. op_que_event TEST_EVENT_B, cnt = 0xF7 (247), id = 0xD6 (214)
> 6. op_event TEST_EVENT_B, cnt = 0x7D (125), id = 0xD5 (213)
>
> Packet 4 should contain id 212, agree. Looks like a server bug.
>
> But how could you explain packet 5 which contains wrong count (247) ?
> op_que_event packet is created by client, it should not be affected by
> any server bug.
That is because the current implementation in Jaybird only looks at the
id, so when in step 4 it receives id 213 with count 247, it assumes that
247 is the new count for TEST_EVENT_B. It then re-queues that event with
the updated count.
This BTW is also what I believe the native implementation does: only
looking at the id.
--
Mark Rotteveel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
