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

Late CSN notifications in history. #64

Open
andrewkm opened this issue Oct 16, 2022 · 4 comments
Open

Late CSN notifications in history. #64

andrewkm opened this issue Oct 16, 2022 · 4 comments

Comments

@andrewkm
Copy link

andrewkm commented Oct 16, 2022

We've been getting quite a few people reporting late CSN notifications lately.
I've no idea how to describe this bug properly, the findings start here:
https://ecocitycraft.com/forum/threads/chestshop-lost-money.218724/#post-1140815

Perhaps we just have far too many transactions going through?

Config as such:
https://pastebin.com/43zYr1Q7

Paper 1.19.2 - Build #215
Using both latest ChestShop and ChestShopNotifier as of this post, compiled straight from master branches.

@Phoenix616
Copy link
Member

Are you sure that they are late and not completely missing? (At least it seems from your forum thread that they are reporting that they never got the notification at all)

If you can then I would also appreciate it if you would check the database entries to see whether this is a data storage or a display issue.

@andrewkm
Copy link
Author

I've verified that they are correctly being added to CSN's DB.
One user states "What seems to happen is after a day or two (For me anyway) csn catches up and places those sales at the top of the list with the correct time on it (Meaning there are sales with the time of over 1day about some sales with 30mins)"

Perhaps it's a problem with the sheer amount of shop activity we have during peak hours:
https://www.youtube.com/watch?v=qWvXWmbBw20

It's a little... nuts.

Phoenix616 added a commit that referenced this issue Oct 16, 2022
This makes sure that only one BatchRunner is started at a time as well
 as that transaction data is actually committed in a timely manner
@Phoenix616
Copy link
Member

Not sure exactly if this was the cause of your issue but I took a look at the code that added the information into the database and I found some potential cases where data could potentially get lost (and an inefficiency with how database threads were opened) so please update to the latest commit and see if the issue still occurs on your server.

@andrewkm
Copy link
Author

Appreciate your reply and commits. Will build and apply the latest changes during our next maintenance period and report back. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants