Comments (9)
Migrating on the main thread is a great way to get shut down by the watchdog while transferring larger data sets. Perhaps instead the current provider should be set to a dummy economy that always returns FAILURE? That way not only do you not risk the server killing itself due to the main thread lockup, players can still play using non-economic features while the economy is being migrated.
from treasury.
We propably want to do all the migration on the main thread, If we do it async some plugin may use the old economy provider while switching.
If a plugin is already fetching async we should probably block untill we finish (dont know how).
What do you think of EconomyProviderMigrationStartEvent
and EconomyProviderMigrationFinishEvent
from treasury.
We propably want to do all the migration on the main thread, If we do it async some plugin may use the old economy provider while switching. If a plugin is already fetching async we should probably block untill we finish (dont know how). What do you think of
EconomyProviderMigrationStartEvent
andEconomyProviderMigrationFinishEvent
I think it should be done on the main thread, and if possible, block the async threads too.
What plans do you have for the new events? I don't see an issue in creating them but I don't know what they are used for :)
from treasury.
What plans do you have for the new events? I don't see an issue in creating them but I don't know what they are used for :)
I don't know, maybe some plugin find it useful
I think it should be done on the main thread, and if possible, block the async threads too.
Blocking on async threads, if an operation is being made, it may start with currency A and end with B, dont know how many problems that can cause. Maybe post this on the spigot thread an see ideas
from treasury.
It's best if we rip out that code in the meantime so we have something that compiles and people can link to
from treasury.
Migrating on the main thread is a great way to get shut down by the watchdog while transferring larger data sets. Perhaps instead the current provider should be set to a dummy economy that always returns FAILURE? That way not only do you not risk the server killing itself due to the main thread lockup, players can still play using non-economic features while the economy is being migrated.
I like this idea. Maybe even add a isMigratingEconomyProvider
so that we can check? But how would we handle operations that already started?
from treasury.
Maybe even add a isMigratingEconomyProvider so that we can check?
I assume if you wanted to check you could check the implementing class. I guess you could include it as part of the API, but it seems like a very particular use thing that I'm not sure belongs. Your average plugin shouldn't care, they'll just see that the transaction fails and that's that. It's such a rare case too, I sincerely doubt you'd be converting more than maybe once a year if you happen to have particularly bad luck with economy providers.
But how would we handle operations that already started?
Probably would need some sort of EconomyProvider#awaitPendingQueries
, but this also overall seems like one of those overkill situations - even the slowest of response times is unlikely to exceed a second, so what are the odds that someone started a transaction that will coincide with your once-per-year economy migration? Additionally, bad actors who just grab and hang onto the first available EconomyProvider instead of reobtaining it as necessary can still create new queries using the old economy instance unless the provider actually verifies that it's still registered every single time it's used.
Speaking of I need to go back and change my RegisteredServiceProvider usage for Vault integrations to listen to the ServiceRegisterEvent
and ServiceUnregisterEvent
instead of plugin enable/disable, whoops.
from treasury.
Maybe even add a isMigratingEconomyProvider so that we can check?
I assume if you wanted to check you could check the implementing class. I guess you could include it as part of the API, but it seems like a very particular use thing that I'm not sure belongs. Your average plugin shouldn't care, they'll just see that the transaction fails and that's that. It's such a rare case too, I sincerely doubt you'd be converting more than maybe once a year if you happen to have particularly bad luck with economy providers.
But how would we handle operations that already started?
Probably would need some sort of
EconomyProvider#awaitPendingQueries
, but this also overall seems like one of those overkill situations - even the slowest of response times is unlikely to exceed a second, so what are the odds that someone started a transaction that will coincide with your once-per-year economy migration? Additionally, bad actors who just grab and hang onto the first available EconomyProvider instead of reobtaining it as necessary can still create new queries using the old economy instance unless the provider actually verifies that it's still registered every single time it's used.Speaking of I need to go back and change my RegisteredServiceProvider usage for Vault integrations to listen to the
ServiceRegisterEvent
andServiceUnregisterEvent
instead of plugin enable/disable, whoops.
Since the migrator withdraws the money from the previous provider, I think it is fine if we do it completely async and don't worry about any transactions that occur during the migration process as the user can just migrate again to get the new balances in.
Also - migrating economies whilst users are on - doesn't sound like a good idea to me anyways 😄
from treasury.
Note: This issue is being addressed in #37.
from treasury.
Related Issues (20)
- Expanding #246
- General Javadoc Improvements
- `Response`: add method to fail with a given exception HOT 6
- `Account`: Change the return type of `retrievePermissionsMap` HOT 7
- Review API methods which do not return a Future+Response type. HOT 13
- `EconomyTransaction`: Rename some variables, getters and setters HOT 6
- `Currency`: Should we map display names against locales? HOT 3
- Responses vs Exceptions - differentiate and debate HOT 20
- `Account`: Rename `setPermission`, `hasPermission` to use a plural HOT 3
- Review methods which return TriStates but do not utilise all three possible states HOT 25
- `Account`: add another `setPermissions` method which accepts a `Map<perm, state>` HOT 2
- Change currency identifier to NamespacedKey HOT 6
- EconomyTransactionResult HOT 6
- Add abstract TreasuryException#getMessage(Locale) method
- Publish to Hangar HOT 5
- Last thoughts on Treasury v2's API? YOUR OPINION is wanted! HOT 10
- Write API Documentation in Wiki HOT 17
- Strip colours out of logging HOT 1
- Breaking Change Proposals ('Treasury v3')
- New Author HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from treasury.