You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Frederic Soulier <fr...@wallaby.uklinux.net> on 2006/04/28 12:28:33 UTC
Some heads up to start with MINA
Hi
I've just found out about MINA yesterday (following links about Netty)
and I'd like to use it in some sort of prototype for the time being.
I have yet to go through all the documentation and APIs but I'd like to
describe briefly what I intend to do to double check if it can be
achieved efficiently and elegantly with MINA.
Basically thousands of clients (PC clients and/or mobile phone clients)
could connect to the server. When a client connects there's an initial
custom handshake with the server to request the server RSA public key.
The client will receive the server RSA public key, generates an AES key,
encrypt the AES key using the RSA public key of the server then send it
to the server. From then on all communications client <-> server are
encrypted using the AES key. All the encryption is done using
BouncyCastle.
I also need to be able to handle our comms protocol over plain sockets
and Http.
So I already have a custom server that does all that but I'd like to
re-prototype the core of my server using MINA for maintainabilty reasons
and to check what sort of perf can be achieved.
Can all this be done with ProtocolHandler and the likes?
Thx very much.
--
Frederic Soulier <fr...@wallaby.uklinux.net>
OpenPGP key available on http://www.keyserver.net
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Filtering Http headers
Posted by peter royal <pr...@apache.org>.
On May 4, 2006, at 1:53 AM, Frederic Soulier wrote:
> I need to process (discard) Http headers to get to the binary
> payload (the interesting part).
> Has anyone dealt with something like that before within the MINA
> framework? What would be the best way to tackle that?
>
> My first idea was to keep using the same CumulativeProtocolDecoder
> I'm using now and add processing to filter out the Http header.
You might be able to use code from Asyncweb, a HTTP server built upon
MINA, http://asyncweb.safehaus.org/ .. It already has stuff for
parsing the HTTP headers. Of course, if you just want to skip them
and not process them, doing it yourself would probably be easier.
I'd probably implement it as an IoFilter that watched messages for
the indicator that the headers were done, not passing on messages to
further filters until that condition was met. You could then store
state in the IoSession to know that the condition has been met, so
the filter then just passes data though.
> Also right now we're listening on 1 port to accept client
> connections which could be clients using sockets to connect and/or
> Http.
> But someone suggested maybe to listen to 2 ports, one would take
> client connection for plain socket and one for Http. I'm not sure
> it will bring any benefits.
1 port is probably easier on your clients, but 2 is certainly easier
for you.. With 1, you have to do extra work to determine if the
connection is speaking HTTP or the other protocol, right? Its
probably a wash as to which is better, up to you :)
-pete
--
proyal@apache.org - http://fotap.org/~osi
Filtering Http headers
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
Hi
I need to process (discard) Http headers to get to the binary payload
(the interesting part).
Has anyone dealt with something like that before within the MINA
framework? What would be the best way to tackle that?
My first idea was to keep using the same CumulativeProtocolDecoder
I'm using now and add processing to filter out the Http header.
Also right now we're listening on 1 port to accept client connections
which could be clients using sockets to connect and/or Http.
But someone suggested maybe to listen to 2 ports, one would take
client connection for plain socket and one for Http. I'm not sure it
will bring any benefits.
Thx for any tips.
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Some feedback on MINA
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On Thu, 2006-05-04 at 16:41 +0900, Trustin Lee wrote:
> +1. I'll put it soon
>
> On 5/4/06, Alex Karasulu <ao...@bellsouth.net> wrote:
> >
> > Frederic Soulier wrote:
> > > Hi
> > >
> > > In 3 days, starting from scratch (knowing nothing about MINA) and with
> > > help from this list, I've re-implemented something that took us 2
> > > months + to develop!
> > > I've thrown 4000 concurrent connections at it without problem. The
> > > only pbm I faced was to increase the limit for open files on my linux
> > > box (default was 1024).
> > > Thanks guys for an excellent framework and many thanks to Peter Royal
> > > for his help.
> > Wow this is some excellent feedback. We should put this into the
> > testimonials section.
Just to give more feedback (and sorry for highjacking the thread) about
load testing I've done so far.
- Server code is running a P4 3.4GHz with 2GB Ram, Linux no-SMP (so no
Hyperthreading).
- Client thread are generated from a dual-core Athlon64 4400 with 2GB
Ram.
Last test I ran was:
- 4000 client threads
- each client sending 2 messages for handshaking and exchanging
AES key (each client thread has a different AES key).
Server maintains AES key for each client in a per-client session
- then each client sends 10,000 messages of size 16 <= size <=600
bytes containing a random payload and its encrypted version.
Server decrypts, compares and sends its own version of random
payload and its encrypted version for the client to decrypt,
compare.
Each client thread sleeps 100ms between request/response sequence.
Basically, 40,008,000 messages sent by client threads to the server
and the same number sent by the server to clients.
Overall, 11,259,232,335 bytes read and 11,261,190,784 bytes written
by the server.
On the server side, everything happens in memory. No access to db
yet or other time consuming tasks.
There's a bit of work on each request to decrypt and on each response
to encrypt using the AES key of the client being processed.
MINA did not miss a beat and didn't skip a byte :)
Next test will probably be with 2 client PCs each running 4000 threads
(so 8000 connections to the server) and sending 100 million messages
each. I may increase the size of the payload to maybe up to 5KB.
And try with TCP_NODELAY. Just for fun ;)
--
Frederic Soulier <fr...@wallaby.uklinux.net>
OpenPGP key available on http://www.keyserver.net
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Some feedback on MINA
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On Thu, 2006-05-04 at 16:41 +0900, Trustin Lee wrote:
> +1. I'll put it soon
>
> On 5/4/06, Alex Karasulu <ao...@bellsouth.net> wrote:
> >
> > Frederic Soulier wrote:
> > > Hi
> > >
> > > In 3 days, starting from scratch (knowing nothing about MINA) and with
> > > help from this list, I've re-implemented something that took us 2
> > > months + to develop!
> > > I've thrown 4000 concurrent connections at it without problem. The
> > > only pbm I faced was to increase the limit for open files on my linux
> > > box (default was 1024).
> > > Thanks guys for an excellent framework and many thanks to Peter Royal
> > > for his help.
> > Wow this is some excellent feedback. We should put this into the
> > testimonials section.
Just to give more feedback (and sorry for highjacking the thread) about
load testing I've done so far.
- Server code is running a P4 3.4GHz with 2GB Ram, Linux no-SMP (so no
Hyperthreading).
- Client thread are generated from a dual-core Athlon64 4400 with 2GB
Ram.
Last test I ran was:
- 4000 client threads
- each client sending 2 messages for handshaking and exchanging
AES key (each client thread has a different AES key).
Server maintains AES key for each client in a per-client session
- then each client sends 10,000 messages of size 16 <= size <=600
bytes containing a random payload and its encrypted version.
Server decrypts, compares and sends its own version of random
payload and its encrypted version for the client to decrypt,
compare.
Each client thread sleeps 100ms between request/response sequence.
Basically, 40,008,000 messages sent by client threads to the server
and the same number sent by the server to clients.
Overall, 11,259,232,335 bytes read and 11,261,190,784 bytes written
by the server.
On the server side, everything happens in memory. No access to db
yet or other time consuming tasks.
There's a bit of work on each request to decrypt and on each response
to encrypt using the AES key of the client being processed.
MINA did not miss a beat and didn't skip a byte :)
Next test will probably be with 2 client PCs each running 4000 threads
(so 8000 connections to the server) and sending 100 million messages
each. I may increase the size of the payload to maybe up to 5KB.
And try with TCP_NODELAY. Just for fun ;)
--
Frederic Soulier <fr...@wallaby.uklinux.net>
OpenPGP key available on http://www.keyserver.net
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Some feedback on MINA
Posted by Trustin Lee <tr...@gmail.com>.
+1. I'll put it soon
On 5/4/06, Alex Karasulu <ao...@bellsouth.net> wrote:
>
> Frederic Soulier wrote:
> > Hi
> >
> > In 3 days, starting from scratch (knowing nothing about MINA) and with
> > help from this list, I've re-implemented something that took us 2
> > months + to develop!
> > I've thrown 4000 concurrent connections at it without problem. The
> > only pbm I faced was to increase the limit for open files on my linux
> > box (default was 1024).
> > Thanks guys for an excellent framework and many thanks to Peter Royal
> > for his help.
> Wow this is some excellent feedback. We should put this into the
> testimonials section.
>
> Alex
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Some feedback on MINA
Posted by Alex Karasulu <ao...@bellsouth.net>.
Frederic Soulier wrote:
> Hi
>
> In 3 days, starting from scratch (knowing nothing about MINA) and with
> help from this list, I've re-implemented something that took us 2
> months + to develop!
> I've thrown 4000 concurrent connections at it without problem. The
> only pbm I faced was to increase the limit for open files on my linux
> box (default was 1024).
> Thanks guys for an excellent framework and many thanks to Peter Royal
> for his help.
Wow this is some excellent feedback. We should put this into the
testimonials section.
Alex
Some feedback on MINA
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
Hi
In 3 days, starting from scratch (knowing nothing about MINA) and
with help from this list, I've re-implemented something that took us
2 months + to develop!
I've thrown 4000 concurrent connections at it without problem. The
only pbm I faced was to increase the limit for open files on my linux
box (default was 1024).
Thanks guys for an excellent framework and many thanks to Peter Royal
for his help.
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Some heads up to start with MINA
Posted by peter royal <pr...@apache.org>.
On May 2, 2006, at 4:12 AM, Frederic Soulier wrote:
> And the decoders you have for each message are not necessarily
> MINA's decoders, right?
They do implement MINA's Decoder interface for convenience.
> If I follow you correctly:
> - A CumulativeProtocolDecoder just keep requesting more data
> until it has at least a full message in buffer (or more).
> - This decoder class has a table indicating:
> msg type 1 use my own decoder class AAA
> msg type 2 use my own decoder class BBB
> ...
> msg type x use my own decoder class ZZZ
> - In the doDecode method (we know we have a full message of some
> sort) we check the type of the message and we have a decoder for
> that type (we hope so otherwise it's an invalid type of message) we
> call the appropriate decoder to decode the message and return a
> message object that ultimately will passed back to the IoHandler
> messageReceived method.
exactly!
> If that's how it works I suspect I have to be careful with the
> decoder table and decoders as as far as I understand each IoSession
> has it's own instance of the filters so I don't really want to have
> a Decoder in the filter chain that needs to instantiate all these
> secondary decoders which should be the same for all clients
> connecting really.
>
> Is an IoSession per connection?
An IoSession is per-connection, but IoFilters aren't necessarily. You
can add the ProtocolDecoderFilter to the template filter chain for
your connection, and the same instance will be re-used. Make your
ProtocolCodecFactory return the the same ProtocolDecoder each time,
and you can avoid having unnecessary instantiation.
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Some heads up to start with MINA
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On 1 May 2006, at 20:32, peter royal wrote:
> On May 1, 2006, at 3:01 PM, Frederic Soulier wrote:
>> On 1 May 2006, at 19:43, peter royal wrote:
>>> I think so :) .. This is more akin to what I've implemented in my
>>> project. I'm using the ProtocolCodecFilter when a Decoder that
>>> reads the message type and length, and once it is all there,
>>> forwards the buffer to another decoder.
>>
>> Ok so a primary decoder just keep saying NEED_DATA until a
>> complete message is ready.
>> When you write "forwards the buffer to another decoder" do you
>> mean a MINA decoder?
>> Aren't the decoder in the chain called automatically?
>
> I'm not using the Demux stuff. My decoder extends
> CumulativeProtocolDecoder, and the work is done in the doDecode
> implementation.
>
> My decoder works like this:
>
> * For each message type, there is a decoder that can decode the
> message. It knows nothing about there being a type/length code in
> the ata
> * There exists a "MyProtocolDecoder" (which is a
> CumulativeProtocolDecoder) that has each of the above decoders
> registered with it with a numeric code.
> * When MyProtocolDecoder has a message's worth of data, it reads
> the type code, looks up the decoder, uses ByteBuffer.limit() to set
> the view to only the messgae, and passes that to the decoder that
> was looked up.
And the decoders you have for each message are not necessarily MINA's
decoders, right?
If I follow you correctly:
- A CumulativeProtocolDecoder just keep requesting more data
until it has at least a full message in buffer (or more).
- This decoder class has a table indicating:
msg type 1 use my own decoder class AAA
msg type 2 use my own decoder class BBB
...
msg type x use my own decoder class ZZZ
- In the doDecode method (we know we have a full message of some
sort) we check the type of the message and we have a decoder for that
type (we hope so otherwise it's an invalid type of message) we call
the appropriate decoder to decode the message and return a message
object that ultimately will passed back to the IoHandler
messageReceived method.
If that's how it works I suspect I have to be careful with the
decoder table and decoders as as far as I understand each IoSession
has it's own instance of the filters so I don't really want to have a
Decoder in the filter chain that needs to instantiate all these
secondary decoders which should be the same for all clients
connecting really.
Is an IoSession per connection?
Thx.
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Some heads up to start with MINA
Posted by peter royal <pe...@pobox.com>.
On May 1, 2006, at 3:01 PM, Frederic Soulier wrote:
> On 1 May 2006, at 19:43, peter royal wrote:
>> I think so :) .. This is more akin to what I've implemented in my
>> project. I'm using the ProtocolCodecFilter when a Decoder that
>> reads the message type and length, and once it is all there,
>> forwards the buffer to another decoder.
>
> Ok so a primary decoder just keep saying NEED_DATA until a complete
> message is ready.
> When you write "forwards the buffer to another decoder" do you mean
> a MINA decoder?
> Aren't the decoder in the chain called automatically?
I'm not using the Demux stuff. My decoder extends
CumulativeProtocolDecoder, and the work is done in the doDecode
implementation.
My decoder works like this:
* For each message type, there is a decoder that can decode the
message. It knows nothing about there being a type/length code in the
ata
* There exists a "MyProtocolDecoder" (which is a
CumulativeProtocolDecoder) that has each of the above decoders
registered with it with a numeric code.
* When MyProtocolDecoder has a message's worth of data, it reads
the type code, looks up the decoder, uses ByteBuffer.limit() to set
the view to only the messgae, and passes that to the decoder that was
looked up.
> I think I used the wrong term here (i.e. long running). I meant to
> ask if the IoHandler messageReceived method is going to be a point
> of contention.
Unless you add some sort of synchronization, it should be thread-safe
and allow multiple concurrent invocations.
-pete
--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi
Re: Some heads up to start with MINA
Posted by peter royal <pr...@apache.org>.
On May 1, 2006, at 3:12 PM, Samuel Doyle wrote:
> This is interesting. In my implementation I just have
> one decoder. So if I needed I could add multiple
> decoders and in my first decoder when I
> ProtocolDecoderOutput.write() my decoded packet it
> will be sent to next decoder and not my
> IoHandlerAdapter. Is this correct?
No. The DemuxingProtocolCodecFactory just calls multiple decoders in
serial until it finds one that can decode the data.
If you want to chain decoders, that is, have the output from decoder
A be the input for decoder B, you will need to make your own variant
of the ProtocolCodecFilter, since the one in MINA does not allow it
to be used multiple times in a chain, nor does it attempt to decode
non-bytebuffer input.
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Some heads up to start with MINA
Posted by Samuel Doyle <sd...@yahoo.com>.
This is interesting. In my implementation I just have
one decoder. So if I needed I could add multiple
decoders and in my first decoder when I
ProtocolDecoderOutput.write() my decoded packet it
will be sent to next decoder and not my
IoHandlerAdapter. Is this correct?
Thanks, S.D.
--- Frederic Soulier <fr...@wallaby.uklinux.net>
wrote:
>
> On 1 May 2006, at 19:43, peter royal wrote:
> > I think so :) .. This is more akin to what I've
> implemented in my
> > project. I'm using the ProtocolCodecFilter when a
> Decoder that
> > reads the message type and length, and once it is
> all there,
> > forwards the buffer to another decoder.
>
> Ok so a primary decoder just keep saying NEED_DATA
> until a complete
> message is ready.
> When you write "forwards the buffer to another
> decoder" do you mean a
> MINA decoder?
> Aren't the decoder in the chain called
> automatically?
>
>
>
> >> Also ultimately the messages will be processed by
> >> public void messageReceived(IoSession session,
> Object message)
> >> in my IoHandler
> >> Is it ok to have long running transactions in
> there?
> >
> > That's up to you and what your application is
> doing. If you're
> > using JTA and can suspend/resume a transaction,
> that might be ideal
> > (you could do this in an IoFilter).
> >
> > Just make sure that transaction state is not
> stored in a
> > ThreadLocal, because subsequent requests for the
> same connection
> > are not guaranteed to occur on a particular
> thread. (A JTA suspend/
> > resume will accomplish this)
>
> I think I used the wrong term here (i.e. long
> running). I meant to
> ask if the IoHandler messageReceived method is going
> to be a point of
> contention.
>
>
>
> >> [Logging issue]
> >> Finally I keep getting the warning from Log4j
> (log4j:WARN No
> >> appenders could be found for logger) and I'm
> baffled as to why it
> >> does that.
> >
> > dunno, I use jdk14 logging :)
>
> Ah damn :)
>
> Thx.
>
> --
> Frederic P. Soulier
> OpenPGP key available on http://pgpkeys.mit.edu/
> 1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203
> 1DD2 BA67 00ED
>
>
Re: Some heads up to start with MINA
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On 1 May 2006, at 19:43, peter royal wrote:
> I think so :) .. This is more akin to what I've implemented in my
> project. I'm using the ProtocolCodecFilter when a Decoder that
> reads the message type and length, and once it is all there,
> forwards the buffer to another decoder.
Ok so a primary decoder just keep saying NEED_DATA until a complete
message is ready.
When you write "forwards the buffer to another decoder" do you mean a
MINA decoder?
Aren't the decoder in the chain called automatically?
>> Also ultimately the messages will be processed by
>> public void messageReceived(IoSession session, Object message)
>> in my IoHandler
>> Is it ok to have long running transactions in there?
>
> That's up to you and what your application is doing. If you're
> using JTA and can suspend/resume a transaction, that might be ideal
> (you could do this in an IoFilter).
>
> Just make sure that transaction state is not stored in a
> ThreadLocal, because subsequent requests for the same connection
> are not guaranteed to occur on a particular thread. (A JTA suspend/
> resume will accomplish this)
I think I used the wrong term here (i.e. long running). I meant to
ask if the IoHandler messageReceived method is going to be a point of
contention.
>> [Logging issue]
>> Finally I keep getting the warning from Log4j (log4j:WARN No
>> appenders could be found for logger) and I'm baffled as to why it
>> does that.
>
> dunno, I use jdk14 logging :)
Ah damn :)
Thx.
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Some heads up to start with MINA
Posted by peter royal <pr...@apache.org>.
On May 1, 2006, at 1:59 PM, Frederic Soulier wrote:
> I really dug into MINA (0.9.3) today and I managed to implement 1
> message (and funnily enough it works!) using the SumUp examples as
> my starting point.
excellent!
> Would it be better to have only 1 decoder and a case structure in
> decode that would instantiate the right message based on the type.
I think so :) .. This is more akin to what I've implemented in my
project. I'm using the ProtocolCodecFilter when a Decoder that reads
the message type and length, and once it is all there, forwards the
buffer to another decoder.
> Also ultimately the messages will be processed by
> public void messageReceived(IoSession session, Object message)
> in my IoHandler
> Is it ok to have long running transactions in there?
That's up to you and what your application is doing. If you're using
JTA and can suspend/resume a transaction, that might be ideal (you
could do this in an IoFilter).
Just make sure that transaction state is not stored in a ThreadLocal,
because subsequent requests for the same connection are not
guaranteed to occur on a particular thread. (A JTA suspend/resume
will accomplish this)
> Do I need to add a ThreadPoolFilter to the chain or is one
> automatically setup?
> Looking at the src BaseIoServiceConfig file it seems a
> PooledThreadModel (with max size = 16) is the default if the user
> doesn't defined one, right?
correct.
> [Logging issue]
> Finally I keep getting the warning from Log4j (log4j:WARN No
> appenders could be found for logger) and I'm baffled as to why it
> does that.
dunno, I use jdk14 logging :)
> Some comments:
> - I really like what I've seen so far and most of my problems
> come from not knowing exactly how to use the framework
> - The getting started stuff on the web site and the fact I'm
> using the unstable version confuses things :)
Glad to hear you're having success!
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Some heads up to start with MINA
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On 1 May 2006, at 14:59, peter royal wrote:
> On Apr 28, 2006, at 6:28 AM, Frederic Soulier wrote:
>> So I already have a custom server that does all that but I'd like to
>> re-prototype the core of my server using MINA for maintainabilty
>> reasons
>> and to check what sort of perf can be achieved.
>>
>> Can all this be done with ProtocolHandler and the likes?
>
> You'll probably be creating your own IoFilter's, rather than using
> the ones that MINA ships with, but what you describe is totally
> possible in MINA.
> -pete
Thx Pete.
I really dug into MINA (0.9.3) today and I managed to implement 1
message (and funnily enough it works!) using the SumUp examples as my
starting point.
The final system must be able to handle 30+ different messages of the
form:
short - msg type
int - internal system handle
int - length of msg body
byte[] - msg body encrypted
I can easily know whether I need more data or not as a pre-requisite
for a decodable message is to have the msg header=short+int+int
Once I get that I know whether I have the full msg payload (encrypted
body) by checking if I have at least this number of bytes in the buffer.
Now I guess I could have have 30+ decoders registered (using
DemuxingProtocolCodecFactory) and for each message I'd have something
like that:
1st decoder tests if message is decodable
if yes then 1st decoder decodes body
if no then 2nd decoder tests if message is decodable
if yes then 2nd decoder decodes body
if no then 3rd decoder tests if message is decodable
etc... etc...
But I have the *impression* it's not efficient.
Would it be better to have only 1 decoder and a case structure in
decode that would instantiate the right message based on the type.
Also ultimately the messages will be processed by
public void messageReceived(IoSession session, Object message)
in my IoHandler
Is it ok to have long running transactions in there?
[Threading]
This is the code I use to setup the IoAcceptor
IoAcceptor acceptor = new SocketAcceptor();
IoAcceptorConfig config = new SocketAcceptorConfig();
DefaultIoFilterChainBuilder chain = config.getFilterChain();
chain.addLast("ioLogger", new LoggingFilter());
acceptor.bind(new InetSocketAddress(PORT),
new ServerSessionHandler(this),
config);
Do I need to add a ThreadPoolFilter to the chain or is one
automatically setup?
Looking at the src BaseIoServiceConfig file it seems a
PooledThreadModel (with max size = 16) is the default if the user
doesn't defined one, right?
[Logging issue]
Finally I keep getting the warning from Log4j (log4j:WARN No
appenders could be found for logger) and I'm baffled as to why it
does that.
I have nlog4j-1.2.24.jar, slf4j-log4j12.jar and log4j.properties (or
log4j.xml) in my classpath at runtime.
I get the message when MINA's LoggingFilter tries to log in something
from my IoHandler where I've added it to the filter chain.
public void sessionCreated(IoSession session) throws Exception
{
ProtocolCodecFactory codec = new MessagesProtocolCodecFactory();
session.getFilterChain().addFirst("protocolFilter", new
ProtocolCodecFilter(codec));
session.getFilterChain().addLast("sessionLogger", new
LoggingFilter());
}
Some comments:
- I really like what I've seen so far and most of my problems
come from not knowing exactly how to use the framework
- The getting started stuff on the web site and the fact I'm
using the unstable version confuses things :)
Thx for any help.
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Some heads up to start with MINA
Posted by peter royal <pr...@apache.org>.
On Apr 28, 2006, at 6:28 AM, Frederic Soulier wrote:
> So I already have a custom server that does all that but I'd like to
> re-prototype the core of my server using MINA for maintainabilty
> reasons
> and to check what sort of perf can be achieved.
>
> Can all this be done with ProtocolHandler and the likes?
You'll probably be creating your own IoFilter's, rather than using
the ones that MINA ships with, but what you describe is totally
possible in MINA.
-pete
--
proyal@apache.org - http://fotap.org/~osi