fix instance restarting fight. #6507
Conversation
|
@javierguerragiraldez This is a fatal error. Is there any preliminary released time? |
|
@javierguerragiraldez, @bungle, @gszr, first of all, I would like to thank you for your effort in this project and specifically this fix, but as I can see the only code review is blocking us to release it. Would you consider to raise it up, in order to release the fix as soon as possible, since it's really a blocking issue and I believe a lot of teams are struggling through it? |
|
@javierguerragiraldez as this is a fix, could we be basing on |
When a Lua coroutine (thread) finds that another thread is starting an instance, it waits until the other either succeeds or fails. In case of failure, the original thread fails the request, and the second one tries again. This retry was wrongly being stored in the old intance info table which is removed by the failing thread, and never stored back in the general table by the retrying thread. This fix ensures that on the failing case the second thread doesn't hold the old info, but creates a new one.
javierguerragiraldez
force-pushed
the
fix/go-instance-restart
branch
from
f8073c4 to
4620c42
Compare
|
@javierguerragiraldez Hi,Could you merge it to v2.1.5? I am using kong v2.1.4.Thank you! |
|
@javierguerragiraldez Hi, when I modified kong/db/dao/plugins/go.lua as you modified, got the following err: |
|
Hi @lampnick, from your log it seems the pluginserver is crashing while starting a plugin instance. There might be a problem with your Go code. If necessary, please open a new issue to focus on that. |
|
|
@gszr , any chance to release 2.2.1 at any time soon? |
|
@gszr , estimated release date for 2.2.1, please? |
|
@YegorMedvedev 2.2.1 will be out in the coming days. |
|
@YegorMedvedev The 2.2.1 release is now out! Apologies for the delay on my end to give an update and happy Konging! |
|
@gszr , thanks mate! So far it works as expected ;) Happy Konging you too! |
When a Lua coroutine (thread) finds that another thread is starting an
instance, it waits until the other either succeeds or fails. In case of
failure, the original thread fails the request, and the second one
tries again. This retry was wrongly being stored in the old intance
info table which is removed by the failing thread, and never stored
back in the general table by the retrying thread. This fix ensures
that on the failing case the second thread doesn't hold the old info,
but creates a new one.
Issues resolved
Fix #6432 #6500