Hi Isuru,
Thanks for your feedback, yes what you have pointed out is correct. However
IMO locks are only there for synchronizing logic against multiple threads.
There are not used for validating logic:
try {
acquireLock();
validateInputs();
executeLogic();
finally {
releaseLock();
}
Hi Imesh,
On Sun, Feb 1, 2015 at 9:08 AM, Imesh Gunaratne wrote:
> Hi Isuru,
>
> Let me re-clarify the above point again, IMO when a block of code is
> trying to acquire a lock, the lock acquiring process should not fail due to
> any reason. The best way to do this is to create lock objects on d
Hi Isuru,
Let me re-clarify the above point again, IMO when a block of code is trying
to acquire a lock, the lock acquiring process should not fail due to any
reason. The best way to do this is to create lock objects on demand. Lock
object removal process works as it was before, when removing serv
Hi Isuru,
With the latest codebase we can see how it has affected, now due to some
reason lock objects are not getting created. As a result the lock acquire
calls fail.
IMO we need to create lock objects on demand and remove them when relevant
topology objects get removed from the system.
Thanks
Hi Imesh,
On Sun, Feb 1, 2015 at 12:06 AM, Imesh Gunaratne wrote:
> Hi Devs,
>
> I see an issue with topology hierarchy locking behaviour. The problem is
> that topology lock objects are created at the time services and clusters
> are created. IMO this is error prone, now with the latest codebas
Hi Devs,
I see an issue with topology hierarchy locking behaviour. The problem is
that topology lock objects are created at the time services and clusters
are created. IMO this is error prone, now with the latest codebase I can
see error logs saying "topology lock not found". Ideally locks should
