ВЕ @stopshelf
Showing posts older than #229 · Back to latest
... чтобы ноды не залебывались от нагрузки ...
-Xmx (максимальный размер кучи) парсеру, чтобы он (а) не притеснял другие приложения и (б) сам не скукожился от OutOfMemory: Java Heap Space?А есть ли сервис, которому я мог бы просто переправить ссылку на фотоальбом с мероприятия, и он бы сам за меня его отсмотрел (по образцу моей фотки), а мне бы скинул только те фотки, на которых я есть?
И раз в 99% случаев такие ссылки публикуют в Telegram-каналах мероприятий, то в идеале бы как-то делать это, не покидая мессенджер.
Forwarded from Spring АйО
Executors не подходят):var threadPool = new ThreadPoolExecutor(
corePoolSize, // 3
maxPoolSize, // 30
keepAliveTime, // 60
TimeUnit.SECONDS,
new LinkedBlockingQueue<>(maxQueueLength), // 100
Executors.defaultThreadFactory(),
new DiscardPolicy()); // could also be a logging implementation
List<Future> futures = new ArrayList<>();
futures.add(threadPool.submit(task));
for (Future future : futures) {
try {
future.get();
}
catch (Exception e) {
log.error("Failed to get task result from future", e);
}
}future.get()?future.get(). Да, это решит проблему, но не даст понять, почему она появилась.CompletableFuture.allOf(c1, c2, c3).join(). Наверняка так можно (не проверял), но выглядит избыточно сложно, должно же работать и так.future.get() вот в такое условие: if (future.isDone()) {
future.get();
}isDone() == false), то мы просто дождёмся её завершения при вызове get(). Но нет. Когда мы имеем дело с ThreadPoolExecutor, то при вызове submit() он в качестве имплементации Future возвращает экземпляр FutureTask, у которого метод isDone() выглядит так: public boolean isDone() {
return state != NEW;
}FutureTask.get() устроен так: public V get() throws InterruptedException, ExecutionException {
int s = state;
if (s <= COMPLETING)
s = awaitDone(false, 0L);
return report(s);
}NEW (на самом деле только для NEW и COMPLETING).COMPLETING, мы наверняка увидели бы соответствующий ей поток в дампе, а раз его нет, значит, она в NEW.NEW, если все задачи вроде как были переданы пулу на исполнение? Видимо, он её не взял. А почему не взял? Правильно — из-за переполнения очереди, ведь она ограничена (new LinkedBlockingQueue<>(maxQueueLength)). А почему тогда это не привело к ошибкам и прерыванию всего процесса? Верно, из-за с виду безобидной new DiscardPolicy(), которая просто дропает не влезшие задачки (и логирует их, как было в нашем случае).NEW;future.get() впадает в бесконечное ожидание;NEW в виде вызова future.isDone().get() её не подождёт. В этом случае решение должно быть другим.Подумай, что будет гуглить разработчик, столкнувшийся с такой же проблемой/вопросом, как ты описываешь в докладе, и выпадет ли ему твой доклад при текущем его названии?
TimeUuid — длинный целочисленный идентификатор, включающий в себя как timestamp события, так и его ID (это делается, чтобы исключить коллизии между событиями, произошедшими в один момент времени, а также чтобы сохранить для ключа все свойства обычного целочисленного ID). Как следствие, одному timestamp-у может соответствовать множество значений TimeUuid, и, чтобы это учесть, при реализации поиска событий мой предшественник-разработчик прибег к небольшой хитрости: стал задавать нижнюю границу поиска (минимальную дату) в виде TimeUuid с неким минимальным ID события, а верхнюю границу (максимальную дату) — с максимально возможным ID 🗜Long, то и значения этих границ выбраны соответственно: 0 и Long.MAX_VALUE. То есть задумка в том, что каким бы ни был фактический ID искомого события, он по-любому будет в диапазоне от 0 до Long.MAX_VALUE. Казалось бы, что может пойти не так? 🧐maxTimeuuid и minTimeuuid, в комментариях к которым написано:* The min and max possible lsb for a UUID.
* Note that his is not 0 and all 1's because Cassandra TimeUUIDType
* compares the lsb parts as a signed byte array comparison. So the min
* value is 8 times -128 and the max is 8 times +127.
Long.MAX_VALUE вкорячиваем туда что-то вроде 0xFF-FFFF-FFFFFF, то получаем не максимально возможный идентификатор события, а какое-то (отнюдь не максимальное) отрицательное число. Соответственно, ID хранимых в БД событий начинают не особо предсказуемым образом делиться на те, что проходят проверку на сравнение с этим числом, и те, что нет. В нашем случае не проходили лишь пара десятков из почти 4000, поэтому отловить проблему было не просто 🕵️♂️0 и Long.MAX_VALUE в пользу тех самых функций из языка CQL, и условие поиска стало выглядеть примерно так:WHERE key = '...'
AND timestamp_uuid >= mintimeuuid('2025-06-01T00:00:00.000')
AND timestamp_uuid <= maxtimeuuid('2025-06-01T00:00:00.000')
вкл прелюдия;
конст ВЫСОТА := 10;
пер скрытое_поле: массив(ВЫСОТА, массив(ШИРИНА, лог));
про отобразить_поле() нч
для строка := 1..ВЫСОТА нч
для столбец := 1..ШИРИНА нч
если поле(строка - 1)(столбец - 1)
то печать(«%»);
иначе то печать(«_»);
кц
печать(«\н»);
кц
кц
&НаКлиенте
Функция РассчитатьПроцентНаценки(ЦенаЗакупки, ЦенаПродажи)
ПроцентНаценки = 0;
Если ЦенаЗакупки <> 0 Тогда
ПроцентНаценки = (ЦенаПродажи - ЦенаЗакупки) * 100 / ЦенаЗакупки;
КонецЕсли;
Возврат ПроцентНаценки;
КонецФункции
