"Моджанг какого х" N2 или убогий UserCache

Вообще давно хотел написать небольшую ремарку на эту тему, но всё никак руки не доходили.
Также решил именовать темы такого типа именно так как в заголовке, ибо очень подходит.

Итак начнём.
В связи с переходом майнкрафта на uuid серверу для многих вещей нужна была возможность конвертировать имя в юайди и наоборот. Но постоянно бомбить сервера моджангов не торт, поэтому в сервер был добавлен кэш.
Но как всегда даже тут моджанги облажались.

Так как кэш двухсторонний то нужно две мапы, вроде пока всё просто. Но ведь нехорошо хранить кэш вечно, поэтому был сделан ограничитель чтобы хранить только 10к записей. К тому же их них выбиралась только самые новые, что в принципе правильно. Хорошая идея, звучит просто, где же тут можно облажаться? Но моджанг умудрились....

Итак если говорить проще моджанг имплементация всего этого выглядит так
HashMap<String, UserCacheEntry>
HashMap<UUID, UserCacheEntry>
LinkedList<UserCacheEntry>
приплыли...

фактически чтобы следить за самыми часто используемыми записями моджанг использует LinkedList, то бишь каждая конверсия вынимает из связного списка обновляемый элемент и кладёт его в начало. Только вот операция удалеия элемента из связного списка имеет сложность - O(n), то бишь линейную, больше элементов - дольше удалять. Таким образом всё преимущество от использования хэшмапов просто уходит на нет, с тем же самым успехом можно было бы тупо пробегать по списку и сравнивать имя либо юид. Вот так в казалось бы простой вещи можно так сильно облажаться?
Ну и ещё, всё это не синхронизовано и потому попытка конверта не из основного потока имеет шанс уронить сервер... В кране кстати решили послежднюю проблему использую LinkedBlockedQueue вместо LinkedList, что впрочем не особо спасает ситуацию, просто делает шанс сломать сервер очень маленьким. Кстати LinkedBlockedQueue имеет лимит после которого оно будет висеть в блокировке вечно, к счастью по дефолту он Integer.MAX_VALUE, ну по краней мере в OracleJVM, вот будет подстава если это не так где-то ещё.
Ну и напоследок, в ванильке по дефолту после каждого обновления этот кэш ещё и сохраняется в файл, так что надеюсь вы не забыли отключить это деле в конфиге крана.

 

save-user-cache-on-stop-only: false

 

Напиши это Моджангам, да услышат они твои замечания

 

Думаю только жалоба в баг-трекер поможет. Напиши там темку, а мы всем срубаккитом будем спамить подтвердим это в теме.

 

Там уже есть. Только никакого толк, всем насрать, ибо тесты всегда идут на чистой ванили, а при количестве игроков 10-20 никакой разницы в производительности.

 

Кинь ссылку пожалуйста, накатаю что-нибудь
P.S Есть вариант связаться с диннербоном в IRC и договорится о переписывании части кода...

 

И как это решает проблему? Или как обычно читаем только последнее предложение?

 

Я спрошу ещё раз. Как права на доступ к файлу помешают серверу каждый раз при каждом запросе увеличивать размер листа в памяти, а по достижению большого количества игроков просто начать тормозить?

 

Нет.

 

Ой дурак..

 

Можанги используют сановские/оракловские хешмапы, о чем можно говорить далее?)

 

Прошлая тема была про тикающие сундуки?)

 

Хотя бы спиготам напиши, они для этого и создавались - быть оптимизированнее, раз моджангам плевать

 

Ой, насмешил.

 

Писал, но однако не приняли.

 

Ну когда их майнплекс рухнет, тогда может и задергаются.

 

Не рухнет, сервера разворачиваются из изначального состояния и схлопываются после окончания миниигры.
И полуофициальный сервер spigot это не mineplex, а ecocitycraft, но у них вообще своя система кэша основанная на MongoDB кажется.

 

Разве не true должно быть?

 

Оно по дефолту false, но должно быть true, иначё всё становится совсем печально.

 

Для майнкрафта разве выгодно использовать MongoDB?