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.
Regards,
Vlad
------------------------------------------------------------------------------
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
