Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locking issues after update from 1.5.0 to >=1.6.0 (bug?) #34

Closed
pmioduszewski opened this issue Jun 3, 2021 · 12 comments
Closed

Locking issues after update from 1.5.0 to >=1.6.0 (bug?) #34

pmioduszewski opened this issue Jun 3, 2021 · 12 comments
Assignees
Labels
bug Something isn't working

Comments

@pmioduszewski
Copy link

pmioduszewski commented Jun 3, 2021

Hi,

After updating acebase from 1.5.0 to 1.6.0 and higher I'm experiencing issues with "locking".

I didn't change my code and have no idea how to deal with those locking issues right now.

On 1.5.0 everything working really fast almost instantly, but on 1.6.0+ same functions take even 1 minute for lightweight tasks with read lock on path ... in the console.

[localtest] Reading node "/user/1365174619/account" from address 2,60
[localtest] Reading node "/user/1365174619/account" from address 2,60
[localtest] Reading node "/user/1365174619/products/active" from address 1,789
[localtest] Reading node "/user/1365174619/account" from address 2,60
read lock on path "/" by tid 1 (Node.getInfo "/") is taking a long time to complete [1]
read lock on path "/" by tid 1 (Node.getInfo "/") is taking a long time to complete [2]
read lock on path "/" by tid 1 (Node.getInfo "/") is taking a long time to complete [3]
lock :: read lock on path "/" by tid 1 (Node.getInfo "/") took too long
[localtest] Node "/user/1365174619" being updated: adding 0 keys (), updating 0 keys (), removing 1 keys ("account")
[localtest] Node "/user/1365174619" saved at address 31,646 - 1 addresses, 24 bytes written in 1 chunk(s)

Are there any examples of "do this / don't do that" to avoid locking issues?

Node: 15.14.0

@appy-one
Copy link
Owner

appy-one commented Jun 4, 2021

I ran into the same issue this week, I will be publishing an update today that should fix it

@appy-one appy-one self-assigned this Jun 4, 2021
@appy-one appy-one added the bug Something isn't working label Jun 4, 2021
@appy-one
Copy link
Owner

appy-one commented Jun 4, 2021

I have just published version 1.6.3, can you confirm this fixes your locking issue?

@appy-one appy-one reopened this Jun 4, 2021
@pmioduszewski
Copy link
Author

I have just published version 1.6.3, can you confirm this fixes your locking issue?

image

Now everything works fast but still getting locking issues in the console. 🤔

@appy-one
Copy link
Owner

appy-one commented Jun 4, 2021

Can you enable verbose logging in AceBase's settings and post the details? eg use: new AceBase('dbname', { logLevel: 'verbose' })

@appy-one
Copy link
Owner

appy-one commented Jun 4, 2021

Please let me know how to reproduce this. Can you submit code?

@pmioduszewski
Copy link
Author

This is strange, this lock issue appears in a random way now. I'm trying to find out minimal code to reproduce.

@appy-one
Copy link
Owner

appy-one commented Jun 6, 2021

Another something that might help me investigating.. Is your code running in a cluster (eg using cluster.fork())?

@appy-one
Copy link
Owner

appy-one commented Jun 8, 2021

Also, do you have indexes on the data? Please give me some more info, this needs to be fixed asap!

@pmioduszewski
Copy link
Author

Also, do you have indexes on the data? Please give me some more info, this needs to be fixed asap!

Sorry, I've been really busy lately.

I've just sent you an email :)

@appy-one
Copy link
Owner

appy-one commented Jun 9, 2021

Thanks for the code, I managed to reproduce!
ref.count() appears to be the troublemaker here, I'll see what's going on there..

appy-one added a commit that referenced this issue Jun 9, 2021
- Reversed announcement/lock flow - now locks first, then announces if
  it wasn't not cached in the meantime. This prevents an announced
  lookup not resolving because it doesn't get the lock, while another
  (that WOULD get the lock) waits for the announcement to resolve..
- Getting child count locked the child and caused the parent lock not
  to be released.
@appy-one
Copy link
Owner

appy-one commented Jun 9, 2021

I just published v1.6.4 which should fix this. Let me know if it works!

@pmioduszewski
Copy link
Author

now it works like a charm! gj 😁👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants