Artemis 2562 Reduces context-switches on iocb pool

[franz1981]

No description provided.

[clebertsuconic]

it should really be the queueSize here for correctness... at this point queueSize should be == available though, in which case you could assert.

[clebertsuconic]

At least testsuite is passing here, it compiles using docker and tests are ok.

[franz1981]

You're right but the risk is that If the pooled iocb won't go into the pool we will free it, making the kernel to segsv on the first access...I would prefer a leak then a segmentation fault, but I agree that some warns should be printed Il lun 25 nov 2019, 20:58 clebertsuconic <notifications@github.com> ha scritto:

…

***@***.**** commented on this pull request. ------------------------------ In src/main/c/org_apache_activemq_artemis_nativo_jlibaio_LibaioContext.c <#6 (comment)> : > @@ -502,7 +502,7 @@ static inline void iocb_destroy_bounded(struct io_control * theControl, int uppe * @PARAM theControl */ static inline void iocb_destroy(struct io_control * theControl) { - iocb_destroy_bounded(theControl, theControl->queueSize); it should really be the queueSize here for correctness... at this point queueSize should be == available though, in which case you could assert. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEENM6YQ3M7BF323UHVC4TQVQU5BANCNFSM4JRNKCGQ> .

[michaelandrepearce]

You prefer a leak really??? If you get segfault will be alot easier to trace back. Both would be finally terminal better to have a quick death and know the cause, than a slow and silent one.

[franz1981]

@michaelandrepearce

If you get segfault will be alot easier to trace back

Not sure about that if it would happen on kernel-side: you need to

1. have debug symbols on kernel to know what's happened
2. be sure you're not on a VM and you have rights to create a SOS report

I won't go in both the rabbit holes if possible :)
The original code was making the assumption that any used iocb must be released at some point, but that's not what happen in a real world while using NFS (hard-mounted) and getting a broker timeout due to long kernel-side disk operation.
I prefer, instead, logging that something bad has happened (error or warn level) and won't let the kernel crash silently, that's my 2 cents, but I'm opened to other opinions, bud :)

[franz1981]

@michaelandrepearce

Both would be finally terminal better to have a quick death and know the cause, than a slow and silent one.

The point is that if the kernel hasn't yet released the iocb it means that the I/O op is stucked somewhere and we can't really assume anything about its state if not that would be better to immediately crash the broker, because storage is no longer reliable: that would be fast, timely and informed.
I would prefer to not force release a probably used iocb and warn/error the Java side; possibly by capturing it as a criticalIO/error (usually it would shutdown the broker).

[franz1981]

@michaelandrepearce any chance you can try it? I'm thinking to provide a pure spin poll version for users that have low latency disks (assuming the disk isn't yet maxed you , just thinking loud) :)