RE: Some questions (slf4j , how to reduce thread count, accessing session IP address)

[Gaston Dombiak <ga...@jivesoftware.com>]

When using the ExecutorFilter (with default settings) you will have 16
core threads in the thread pool. Your options are 1) pass an Executor
when building/setting the ExecutorFilter, 2) configure the thread pool
that the filter is using or 3) use your own thread model.

I would recommend customizing the SEDA architecture (i.e. number of
queues, and processing threads) based on your expected load.

PS: I'm using branch 1.1 and logic may be different in other branches.

Regards,

  -- Gato

-----Original Message-----
From: Mark Webb [mailto:elihusmails@gmail.com] 
Sent: Friday, December 29, 2006 6:46 AM
To: dev@mina.apache.org
Subject: Re: Some questions (slf4j , how to reduce thread count,
accessing session IP address)

As far as #1 goes, http://www.slf4j.org/download.html.
The rest, I can look in to, but am sure some smarter person on this list
will beat me to the answer.


On 12/29/06, Mehmet D. AKIN <md...@gmail.com> wrote:
>
> Hi, I have three questions (Using mina 1.1 pre release snapshot)
>
> 1. I failed to find a single slf4j jar file in sl4j1.1 distribution to
> satisfy mina's dependencies. I had to include both slf4j-api and
> slf4j-nop jars to run tests. Is there a single slf4j jar to run mina?
>
> 2. As far as I see, MINA automatically creates 16 threads as more than
> one client tries to access to server. Is there a way to reduce this
> thread count.. to like 1 or 2 ? I could do this in an old version but
> API seems to be changed.
>
> 3. I want to access the connected clients IP address from session
> info. again I could do this, but not anymore :) What I want to do is
> to allow "only local connections" so I will check the address on
> connection request. There is a blacklist filter for such purposes but,
> I guess a whitelist filter approach is needed in this situation (allow
> this, deny all others).
>
> I browsed the documentations but either I couldnt see the answers or
> API's are changed since the documentation is written.
>
> regards
>
> Mehmet
>



-- 
..Cheers
Mark