Salut,
gustav trede wrote:
> salut,
>
>
> What is best for handler in the future, base class or interface.
>
> if we decide to do the isactive in comethandler, im experimenting with
> that atm,
> its gives "free" isactive check compared to the current very costly one,
> all implementations need to have something like:
>
> private volatile boolean isactive = true;
>
> public boolean isActive() {
> return isactive;
> }
>
> public void setActive(boolean isactive) {
> this.isactive = isactive;
> }
>
> the problem is that people must remember to have a threadsafe boolean,
> ie volatile.
I would think we can add an interface that extends the current
CometHandler instead of a base class. But I do agree it will makes the
things complicated.
>
> also when using executors, that imo should be the default in todays
> world of multicore, threadsafe code is needed too in comethandler,
> and doing that by synchronizing on object instance level is not nice,
> that makes worker threads pile up after each other ,
> waiting for the earlier event to complete, possible multiple io
> messages etc..
>
> an entire threadpool can be blocked due to 1 slow client....
>
> thats where my comethandler logic is needed, to only let the first
> workerthread stay and do the work, with a private event queue
> datastructure for that handler,
> other worker threads simply add their event to that queue and return,
> not blocking for IO etc..
Can you share some code about what you have in mind? The user will just
have to extends your base class (a la CometHandler) and no
syncronization issue/thinking will be required?
>
> And having all comethandlers to implement, copy paste that everytime is
> not so good... its no OO way of coding and gives alot of room for errors.
:-)
>
> a base class for comethandler can solve these problems.
>
> what are your opinions ?
I agree with most of your recommendation. Just commit the code so we an
take a look.
Thanks for your contribution!
-- Jeanfrancois
>
>
> regards
> gustav trede