#WARNING-ILLEGAL-ASYNC-ACCESS

1 messages · Page 1 of 1 (latest)

cinder condor
#

This error is coming from depenizen, because a placeholder wants to be checked async. The denizen side says that if this happens I should try to contact the devs to fix this... Sooo what am i doing to get this error?

As an example, i have deluxemenus installed (newest Version, for paper, papi and denizen + depenizen aswell) and in my stats Menu i Have multiple lines of

&8[&61&8] &f%denizen_<server.flag[stats.time_1].before[/].as[player].name>%&8: &a%denizen_<server.flag[stats.time_1].after[/].before_last[/].div[60].round_down>% Stunden"

as a result the placeholders get all the "WARNING-ILLEGAL-ASYNC-ACCESS" message. So who does i need to (blame) for?

  • Denizen who says if its async blame who ever does this, for being used in this placeholder.
  • Placeholderapi, for doing it async
  • Deluxemenus, for using it
  • Myself...

.... I dont know and i dont realy care so how can i solve this?

vivid nova
#

Easy fix: uninstall denizen, who uses that thing?

cinder condor
#

🥸

vivid nova
#

Deluxemenus might evaluate the placeholders async

cinder condor
#

Can this be changed or so? I think you could be right because if i just parse a line directly in papi its working.

vivid nova
#

No, I dont think so

#

Do you have update enabled for the menu?

cinder condor
#

no i dont have

vivid nova
#

Do you mind sharing the menu?

cinder condor
#

I dont think this will help you i have this problem on multiple menus but here would be a test menu for this:

menu_title: 'Statistiken'
size: 27
items:
'time':
material: clock
slot: 13
priority: 10
display_name: '&7&lZeit'
lore:
- ''
- '&bDu hast &b&l%statz_time_played_formatted%'
- '&bbei uns gespielt&8.'
- ''
- '&7Top 10 Spieler&8:'
- ''
- '&8[&61&8] &f%denizen_<server.flag[stats.time_1].before[/].as[player].name>%&8: &a%denizen_<server.flag[stats.time_1].after[/].before_last[/].div[60].round_down>% Stunden'
- '&8[&62&8] &f%denizen_<server.flag[stats.time_2].before[/].as[player].name>%&8: &a%denizen_<server.flag[stats.time_2].after[/].before_last[/].div[60].round_down>% Stunden'

vivid nova
#

Okay

#

You could ask denizen people why placeholders cant be accessed async

cinder condor
vivid nova
#

Im not in that server

cinder condor
vivid nova
#

Uh, bullshit

#

If the placeholder just read data from a database or whatever, it is better to access it async

#

What does this placeholder even do?

cinder condor
#

It just give out a denizen flag. In a flag is data saved from another script by myself

cursive holly
vivid nova
#

Nothing we can or will do about this

cinder condor
#

ok thx, than i will confront him once more with it. xD

slim orchid
#

Nothing can be async in Bukkit unless explicitly enabled and documented as such

#

A valid Denizen placeholder example would be %denizen_<player.location.below.material.name>% to get the name of the material under the player's feet (like stone)

#

this goes through several Bukkit API methods, a few of which can be async but several of which must be sync (such as getChunk, getBlock, etc. These are hardlocked by bukkit to be sync only, Spigot will even enforce as much with an error message)

#

If PAPI wants to support async placeholders, those necessarily must be explicitly separated from sync, and the sync option strongly should be default

#

Potentially you could enable an intercompatible async read that will freeze the async thread to wait on a sync call and response within PAPI if you wanted to make async reads easy

#

You cannot just presume any/all placeholders are async safe

#

Any placeholder that touches Bukkit, which I assume is a lot of them? will not be async safe

#

Any placeholder not developed by a relative expert (relative by plugindev standards, noting that the bar-to-entry is low) is not going to be async safe

#

I imagine a lot of the placeholders that don't use Bukkit, are still going to be making calls like HashMap#get to look things up - ie not async safe calls

#

or just otherwise reading state data that's accessible to external writer threads

#

async-safe code is, necessarily, an active and intentional choice that has to be carefully implemented throughout all layers of the relevant stack

#

It cannot be assumed, especially not within the Bukkit ecosystem, especially not with the frequency of inexperienced devs being involved in the stack, especially not when there's a mixed variety of devs with no code validation all potentially involved in the stack

#

Async issues in programming are infamous for working "perfectly fine" 99.99% of the time, nothing seems wrong, and then one day something hard explodes out of nowhere.

#

The warning in Denizen was added after a user reported exactly such a hard explosion. After months of everything being fine, using async placeholders unknowingly, suddenly one day with their server loaded down and a lot going on, everything just stopped working because something somewhere tried to muck with the same object from the main thread at the same time as a placeholder was touching it on an async thread, and the whole datastate of the server was corrupted.

#

I'm not some random crazy person, I'm a developer with over a decade of experience, and I'm telling you that you can't just casually ignore async safety nor the API rules of the platform you're working in. I say this based on both the theory of why it matters, and actual practical examples of it mattering.

cinder condor
#

Any Update or Statement here to what mcmonkeys says? Would like to here about itfingerguns

cinder condor
#

@vivid nova sry for ping but can please someone answer to this post, is there anybody looking into it or so?

vivid nova
#

I guess he's right, but there's nothing that I can personally do

earnest cradle
#

we'd like to better support users who use papi; it's obviously a pretty essential plugin

vivid nova
#

I don't think that a way to specify whether an expansion can be used async will be added anytime soon. It also depends on the placeholder, e.g. %server_online% can be used async but other placeholders may not

cinder condor
#

wouldnt it then be better to force all placeholders to be sync and not async? Until there is a way to specify it better? (default should be sync in my opinion)

slim orchid
# vivid nova I don't think that a way to specify whether an expansion can be used async will ...

it is technically currently true that server_online is thread safe currently based on a glance through implementation code (it eventually goes down to a NMS list formed of CopyOnWriteArrayList which is thread safe), however per docs it is explicitly recommended against - that placeholder is backed by Bukkit.getOnlinePlayers().size(), and for getOnlinePlayers:
https://hub.spigotmc.org/javadocs/spigot/org/bukkit/Bukkit.html#getOnlinePlayers()
Iteration behavior is undefined outside of self-contained main-thread uses. Normal and immediate iterator use without consequences that affect the collection are fully supported. The effects following (non-exhaustive) teleportation, death, and kicking are undefined. Any use of this collection from asynchronous threads is unsafe.
the docs as you can see very explicit remind the user to not use this method async
I wouldn't be surprised if the 1.8 or whatever old-version impl of that method was backed by very-not-async-safe code internally. I won't be surprised if future versions of Minecraft have that implemented in not-async-safe ways.
if that happens, and you used that method async, and it breaks, the fault is your own for ignoring the docs on that method / the general Bukkit API rule that nothing is async safe unless it says it is.

This relates to what I said earlier - the Bukkit API is broadly not intended for async usage, and when it does work async that's more often incidental than intended. You can't just presume it's fine.

slim orchid
#

Presuming async safety is, as was seen above by presuming server_online is safe, not a great idea here

#

PAPI should ideally match Bukkit's own rules on this - nothing is async safe unless it clearly identifies itself as async safe

cinder condor
#

@celest flame @somber kelp @chrome ridge @vivid nova

Sry for ping but no answer since 3 days again. Please look into this. Thank you guys for your work a lot 🙂

somber kelp
#

dont ping me

#

please

cinder condor
#

And who should i ping? xD Who can say something to this? 🙂

round shard
#

Is there anyone specific that should be contacted? or perhaps an issue on the PAPI GitHub? PAPI is very widely used and very useful, and we'd love to resolve this so that we can better support users who use it

earnest cradle
#

definitively stating that this is not going to be changed or that the development in this aspect isn't cared for after being elaborated on why it should be would be more helpful than leaving it unanswered for eighteen days now; if someone is interested in doing it eventually that would be more useful than blatantly assuming PAPI has no intention to correct the problem here

vivid nova
#

This is not something that will be ignored in future updates, but I can't promise you when will be implemented.

#

It is a pretty big change and we need to think about the best way to implement it

earnest cradle
cinder condor
#

as long as someone says that this here is on the todo list, i am all fine 🙂

tame hemlock
#

something new on this?

glacial aurora
#

I have raised the issue to the PAPI developers. Not sure what will happen from there. My best guess would be that something will be done with PAPI3. But I have no clue when that will be released.

#

As for the DeluxeMenus side, I can't promise anything there either.

Menu creation in DeluxeMenus is all done async. Same thing goes for menu updating. Changing it to the main thread might result in massive performance issues. I do not have any data or tests to back that up however. It is just speculation at the moment.

It is however, very common for people to complain about menus taking long to open when they use a bunch of placeholders because what people forget is that placeholders are not always just a simple text return. Some expansions do heavy processing when placeholders are parsed. I've seen expansions querying and filtering data on placeholder request with no caching before. While this is technically that expansions fault. Because menu creation is done async however, this leads to just that menu taking long to open. Changing it all to the main thread would result in the entire server waiting for that menu to create and open.