Salut,
changing the title ;-)
gustav trede wrote:
> 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 ?.
Right
> or is it only the comethandler interface that is extra sensitive due to
> its natural to be used alot ?
Both.
>
> 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 .
Agree
>
> people who use the current interface will get the current isactive code
> path, that scales bad.
Any numbers to prove that :-) I know it is not the best implementation :-)
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
Make sense. So with that, the onEvent no longer needs to be synchronized?
A+
-- jeanfrancois
>
>
> 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.
>