15.04.2017 11:08, Mark Rotteveel wrote:
> On 14-4-2017 09:47, Vlad Khorsun wrote:
>> 12.04.2017 23:00, Mark Rotteveel wrote:
>>> In other words: fix confirmed :) Thanks!
>>
>> Thank you for confirmation. Fix is backported into v3. Could you create
>> a ticket to document a bug later ?
>
>
On 14-4-2017 09:47, Vlad Khorsun wrote:
> 12.04.2017 23:00, Mark Rotteveel wrote:
>> In other words: fix confirmed :) Thanks!
>
>Thank you for confirmation. Fix is backported into v3. Could you create
> a ticket to document a bug later ?
Done: http://tracker.firebirdsql.org/browse/CORE-5521
On 2017-04-14 09:47, Vlad Khorsun wrote:
> 12.04.2017 23:00, Mark Rotteveel wrote:
>> In other words: fix confirmed :) Thanks!
>
>Thank you for confirmation. Fix is backported into v3. Could you
> create
> a ticket to document a bug later ?
I will do so tomorrow.
>When evaluating v2.5
12.04.2017 23:00, Mark Rotteveel wrote:
> On 11-4-2017 12:25, Vlad Khorsun wrote:
>> 11.04.2017 12:27, Mark Rotteveel wrote:
>>> On 2017-04-11 09:15, Vlad Khorsun wrote:
>>
PS Mark, snapshot build of v4 contains a fix and could be tested
>>>
>>> Thanks,
>>>
>>> I will try to test it tonight
On 11-4-2017 12:25, Vlad Khorsun wrote:
> 11.04.2017 12:27, Mark Rotteveel wrote:
>> On 2017-04-11 09:15, Vlad Khorsun wrote:
>
>>> PS Mark, snapshot build of v4 contains a fix and could be tested
>>
>> Thanks,
>>
>> I will try to test it tonight if I have time, otherwise tomorrow
>> evening. Is
11.04.2017 12:27, Mark Rotteveel wrote:
> On 2017-04-11 09:15, Vlad Khorsun wrote:
>> PS Mark, snapshot build of v4 contains a fix and could be tested
>
> Thanks,
>
> I will try to test it tonight if I have time, otherwise tomorrow
> evening. Is this something that can easily be backported to
On 2017-04-11 09:15, Vlad Khorsun wrote:
> 11.04.2017 2:33, Adriano dos Santos Fernandes wrote:
>> Here is a better description of the problem and a possible fix that
>> Vlad
>> can use and discard, as he surely better understand this part.
>>
>> Sorry for some imprecision in my previous
11.04.2017 2:33, Adriano dos Santos Fernandes wrote:
> Here is a better description of the problem and a possible fix that Vlad
> can use and discard, as he surely better understand this part.
>
> Sorry for some imprecision in my previous description.
>
> Jaybird synchronized the op_queue_events
Here is a better description of the problem and a possible fix that Vlad
can use and discard, as he surely better understand this part.
Sorry for some imprecision in my previous description.
Jaybird synchronized the op_queue_events send/response.
Remote queue_events synchronizes with the *sync*
On 10/04/2017 06:17, Mark Rotteveel wrote:
>
>> This code runs concurrently and find the same empty slot for
>> simultaneous events being registered.
> In the specific example, Jaybird uses a single connection to register
> for events, and it takes a lock on the database handle, so there
>
On 9-4-2017 21:33, Adriano dos Santos Fernandes wrote:
> 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 =
09.04.2017 22:33, Adriano dos Santos Fernandes wrote:
> 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 =
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
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
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
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
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:
>>
>>
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
On 2-4-2017 15:23, Vlad Khorsun wrote:
>> [V10AsynchronousChannel]Queue event: WireEventHandle:{
>> name:TEST_EVENT_A, localId:694, eventId:0, internalCount:897,
>> previousInternalCount:897 }
>> [AbstractWireOperations]readStatusVector arg:isc_arg_gds int: 0
>>
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 by running the entire Jaybird test suite.
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 by running the entire Jaybird test suite. Running the
specific test,
Anyone?
On 15-1-2017 11:56, Mark Rotteveel wrote:
> I have a test in Jaybird that post multiple events
> (https://github.com/FirebirdSQL/jaybird/blob/master/src/test/org/firebirdsql/event/TestFBEventManager.java#L173)
>
> Essentially it inserts on multiple threads (100 inserts per thread, 5
>
I have a test in Jaybird that post multiple events
(https://github.com/FirebirdSQL/jaybird/blob/master/src/test/org/firebirdsql/event/TestFBEventManager.java#L173)
Essentially it inserts on multiple threads (100 inserts per thread, 5
threads, a commit after each insert) which causes a trigger
25 matches
Mail list logo
