Blazkowiczзабыл никДа - согласен, неинуитивно? Или все-таки неправильно?

Оба.
неинуитивно (хотя может я уже под вечер не соображаю) - что делает calculateEndPeriodDate() я могу понять только из имени. Что делает код, сходу не понятно. Надо разбираться.
возможно неправильно - end date вычисляется от текущего момента, а не от start date. Почему так? Какая в этом особая задумка?


Да именно в этом и задумка - ведь нам нужен интервал от текущего времени ровно до следующей минуты\секунды чтобы зашедулить клоузтаск. А считать от startDate - неправильно, потому что при инициализации создается trendBar у которого startDate может быть, допустим, в середине минуты. Ну неинтуитивно -да..

Посмотри реализацию Calendar.getTime().
Спасибо!

Blazkowiczзабыл никДа, но я делал описку, что упростил проверки на нулл в storage, так как считаю что он не шарится между системами(вроде как доверенный код), и гарантировано правильно инициализирован, но вообще учту, спасибо.
А null может и не снаружи попасть. Сам где-нибудь образуется из-за баги с многопоточностью. :)

Так там все по идее иммьютабл и наполняется после инициализации - наверное не очевидно просто...

Blazkowiczзабыл никВ этом и была идея - сделать ссылку с мапой экзекьюторов доступной для всех через инжекшен( на каждый Symbol по экзекьютору) - и сабмитить оба типа тасков их именно в один и тот же экзекьютор(брать по ключу symbol), извиняюсь может путано пишу.
Да, я понял идею. Просто когда у тебя в ScheduledThreadPoolExecutor нарисовалась очередь из квот, как ты воткнешь CloseTask в нужную позицию?

Да, теперь когда вы указали на косяк с таймстампами в квоте - становится очевидно что этот вариант неправильный, а так по идее это разруливалось через натурал ордеринг) Типа если клоуз таск стартовал - то квот с таймстампами < now нет.. Ну в общем тут комплекс.

schwaschwaпропущено...

Ложная тревога.


Пропустил trendBar.getPeriodType(). Все будет нормально.
Но проблемы с видимостью содержимого List<TrendBar>, когда делаем запрос getTrendBars, все равно будут.
Тк там простой LinkedList.
Да и ConcurrentModificationException там можно будет словить.

Пожалуй что да, вы бы использовали CopyOnWriteArrayList? Но я еще об этом подумаю, ибо я помню что думал об этом, и пришел к выводу что все будет ок, задание делал давно - надо вспоминать, хотя вот сейчас посмотрел - вроде вы правы, если тут косяк - то вот его то я точно должен был не допускать, даже странно...
Спасибо!

BlazkowiczgetStartDate().equals(from) - правда? 1ms реально на что-то влияет?
Double price; - хорошо что сумму считать не попросили.
Так потому и дабл, раз не попросили - так бы был децимал:)

BlazkowiczgetStartDate().equals(from) - правда? 1ms реально на что-то влияет?

Ну вот тут хз - разве не влияет?

забыл никschwaпропущено...

Да и ConcurrentModificationException там можно будет словить.

Пожалуй что да, вы бы использовали CopyOnWriteArrayList? Но я еще об этом подумаю, ибо я помню что думал об этом, и пришел к выводу что все будет ок, задание делал давно - надо вспоминать, хотя вот сейчас посмотрел - вроде вы правы, если тут косяк - то вот его то я точно должен был не допускать, даже странно...
Спасибо!

Все же вы правы:)

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

Blazkowiczзабыл ник,

getStartDate().equals(from) || getStartDate().after(from) == !getStartDate().before(from)

Да, так лучше) Хотя, возможно, для кого-то менее интуитивно, опять же к вопросу о балансе)

Blazkowiczзабыл никВ общем получается что ошибка с таймстампом была самой эпичной - не будь ее, сделал бы без шедулера, как Blazkowicz предложил, ну и LinkedList - но я думаю будь это единственной ошибкой - закрыли бы глаза. Ну и часть кода неинтуитивна - вот и найди тут баланс между простотой и очевидностью.
Я что-то не догнал про LinkedList. Поясните, плз.

ЛинкедЛист - непотокобезопасная коллекция, а там идет ремув, апдейт из разных потоков - могут быть проблемы с visibility, на x86 - врядли, но теоретически неправильно. Ну и при переборе через итератор - может возникнуть исключение ConcurrentModifying.. в отличие от CopyOnWrit'a

Blazkowiczзабыл никДа именно в этом и задумка - ведь нам нужен интервал от текущего времени ровно до следующей минуты\секунды чтобы зашедулить клоузтаск. А считать от startDate - неправильно, потому что при инициализации создается trendBar у которого startDate может быть, допустим, в середине минуты. Ну неинтуитивно -да..

Я всё равно не понял задумки.
Есть startDate и endDate. Оба вычисляются в зависимости от текущего времени. Т.е. длина не фиксирована и может быть любой?

startDate - когда трендбар реально начал мониториться( при начальной инициализации может быть в середине минуты, дня и тп - в зависимости от типа трендбара). closeDate - еобходимо чтобы было 00.00.00. Теоретически поток может вычислить startDate и уснуть - тогда если считать closeDate от начальной - то может возникнуть лаг

забыл никBlazkowiczпропущено...

Я всё равно не понял задумки.
Есть startDate и endDate. Оба вычисляются в зависимости от текущего времени. Т.е. длина не фиксирована и может быть любой?

startDate - когда трендбар реально начал мониториться( при начальной инициализации может быть в середине минуты, дня и тп - в зависимости от типа трендбара). closeDate - еобходимо чтобы было 00.00.00. Теоретически поток может вычислить startDate и уснуть - тогда если считать closeDate от начальной - то может возникнуть лаг

Хотя нет, я походу сам себя обхитрил. Вообще все неправильно имхо, в моем варианте трендбар может охватить два периода, а если считать от startDate такого не будет, но вот что с этим делать? Если startDate допустим 00:59:980, потом поток засыпает, считает closeDate через 20 миллисекунд, но ведь уже должен быть новый трендбар! Хм... надо подумать

Blazkowiczзабыл никЛинкедЛист - непотокобезопасная коллекция, а там идет ремув, апдейт из разных потоков - могут быть проблемы с visibility

В упор не вижу где это.
Есть добавление add(trendBar) в persist
Есть new LinkedList(oldList) - но он не итератор, ConcurrentModifying не выкинет, вроде.

забыл никНу и при переборе через итератор - может возникнуть исключение ConcurrentModifying.. в отличие от CopyOnWrit'a
И где он у нас этот итератор?

Да, вот я и вспомнил почему я не сделал copyOnWrite - но теперь, подумав, думаю все же зря, new LinkedList(oldList) и add(trendBar) - идут в разных потоках, теоретически второй поток может не увидеть последнего добавленного трендбара, да и вообще может не увидеть ничего на экзотических архитектурах. А итератора и правда нету(видимого), но вот вопрос а не используется ли он в конструкторе new LinkedList(oldList) - и я не уверен что все-таки не выкинет.

Blazkowiczзабыл никstartDate - когда трендбар реально начал мониториться( при начальной инициализации может быть в середине минуты, дня и тп - в зависимости от типа трендбара). closeDate - еобходимо чтобы было 00.00.00. Теоретически поток может вычислить startDate и уснуть - тогда если считать closeDate от начальной - то может возникнуть лаг
Ладно. Потом попробую воткнуть почему между
this.startDate = new Date(); и Calendar currentCalendar = Calendar.getInstance(); может быть лаг

, а между
Calendar currentCalendar = Calendar.getInstance();
и
if(getTimeUnit().equals(unit)){
уже не может быть лага.
Да, я уже сомневаюсь в имплементации, и даже пока не знаю как можно сделать правильно, подумаю на выходных:)