Hello, Salut,
Regarding complex logic in comethandler baseclass / interface for isactive
and per handler queue of events in a non blocking way for IO:
If stuff is to get into glassfish V3 im not allowed to break any public API
right ?.
or is it only the comethandler interface that is extra sensitive due to its
natural to be used alot ?
It seems i must do as arcand proposed and do a sub interface to comethandler
, but i will add a base class for that interface ,
to make life easier for users, so no need to copy paste or reinvent the
wheel for complex event queue logic or remember to volatile boolean for
isactive .
people who use the current interface will get the current isactive code
path, that scales bad. and slow clients can more easily stop alot of threads
with IO.
If using executors along with the old interface we have 2 options to ensure
basic threadsafety,
users remember to synchronize their onEvent method (this is how its done
today ! )
i decided to add a lock for notify0 onEvent call in
Defaultnotificationhandler when the old interface is detected
whats your opinion ?
--
your servant
gustav trede
coding is art - not only something that bring food on the table,
everybody should be able to feel proud about their code,
that they have performed their best considering the given conditions.