Re: SSLFilter thread safe?
Hi Trustin, Like i already replied myself, synchronizing on IoSession.write did the job. Unfortunately i can not open source the code ;-( (company decision), but like i described it is any rmi-like framework with extended functionality like oneway messages, callbacks, multiple targets in a single invocation, ... The test case i wrote had several threads doing invocations over the same (remote) proxy. Without SSLFilter no problem, with SSLFilter the test case only succeeded when the framework sync'ed on IOSession.write. Performance impact was minimal, so this fix did the job for me. Hope this helps, Johan On 23 May 2007, at 07:54, Trustin Lee wrote: Hi Johan, On 5/20/07, Johan Cloetens <[EMAIL PROTECTED]> wrote: Hi, I am having some trouble with the SSLFilter included in mina. I have developed a rmi-like framework using mina. It supports things like callbacks and oneway messages, so it isn't purely request/response based: messages can flow in over the session either way without any restrictions. I have no problems whatsoever without the SSLFilter. Using the filter though gives my quite often problems like "bad record mac" and alike. Single threaded pure request/response gives no problems. So i suspect there are some restrictions how the SSLFilter can be used? SSLFilter should be thread safe. If not, it's a bug. Which version of MINA are you using? Could you please provide us how you were able to reproduce the problem? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: article about More New I/O APIs for Java
I sent the following email to [EMAIL PROTECTED] James Im wrote: In the MINA mailing list came up a question that I believe the API must answer. We need a way to query the system about the available native API. We need to know if we will get better performance with the asynchronous API or non-blocking API. The objective is to be able to build a platform-independent solution with a common external interface using either the asynchronous IO API, or the non-blocking API. James - I'm not on the MINA mailing list so I didn't see the background to the question. In any case, the asynchronous I/O API provides a platform independent API, the implementation of which makes use of whatever the highest performing I/O facility is on the operating system. There is also a provider interface if you want to plug in your own implementation (although it's unlikely many people will do that). -Alan Bateman. _ Opret en personlig blog og del dine billeder på MSN Spaces: http://spaces.msn.com/
Re: SSLFilter thread safe?
On 5/23/07, Johan Cloetens <[EMAIL PROTECTED]> wrote: Hi Trustin, Like i already replied myself, synchronizing on IoSession.write did the job. I meant it must work without any manual sychronization unless it's related with your business logic or codec. Unfortunately i can not open source the code ;-( (company decision), but like i described it is any rmi-like framework with extended functionality like oneway messages, callbacks, multiple targets in a single invocation, ... The test case i wrote had several threads doing invocations over the same (remote) proxy. Without SSLFilter no problem, with SSLFilter the test case only succeeded when the framework sync'ed on IOSession.write. Performance impact was minimal, so this fix did the job for me. I see. I understand your concern. :) Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: JMX tutorial on Eclipse
could you send me your code? My first guess is that you don't have your JMX
bean set up properly and/or registered.
On 5/22/07, Eero Nevalainen <[EMAIL PROTECTED]> wrote:
I'm using JDK 5. I gave the argument
-Dcom.sun.management.jmxremote
to the "VM arguments" list under "Run as"->"Run"->"Arguments". Without
the option the jconsole doesn't of course show any VMs running.
Mark Webb wrote:
> are you using JDK 5 or 6 in Eclipse? I think for version 5, you must
add a
> command line argument to the JVM.
>
> On 5/22/07, Eero Nevalainen <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> I went through the JMX tutorial and started it on Eclipse. The JConsole
>> wasn't showing the IoServiceManager mbean. Works fine when started
>> normally from a command line. Anyone else experience this?
>>
>> Also another question: Am I risking some horrible, horrible fate by
>> placing this call on my code?
>>
>> Runtime.getRuntime().addShutdownHook(new Thread() {
>> public void run() {
>> acceptor.unbindAll();
>> }
>> });
>>
>> -Eero Nevalainen
>>
>
>
>
--
..Cheers
Mark
[jira] Commented: (DIRMINA-382) Provide a close() method that doesn't close the connection until all messages are written.
[ https://issues.apache.org/jira/browse/DIRMINA-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498196 ] Mladen Turk commented on DIRMINA-382: - Why not add shutdown() instead parameterized close. It would also allow adding timeout (someting like lingering on standard sockets) > Provide a close() method that doesn't close the connection until all messages > are written. > -- > > Key: DIRMINA-382 > URL: https://issues.apache.org/jira/browse/DIRMINA-382 > Project: MINA > Issue Type: New Feature > Components: Core >Reporter: Trustin Lee > Fix For: 2.0.0-M1 > > > Currently, IoSession.close() closes the connection immediately no matter how > many messages are not written yet. Calling close() will discard all pending > writes and close the connection immediately. Although we can add a > IoFutureListener.CLOSE to the last WriteFuture, it will be more convenient to > provide another close method that doesn't close the connection until all > message are written. > Adding a boolean parameter to the close method will be fine. Of course, > original method without a parameter will be retained. > To implement this, the implementation should satisfy the following condition. > 1) IoSession.isClosing() must return true after close() is called no matter > what boolean parameter is specified. > 2) The session should be closed after all messages are written out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: UDP Recycler Question
did you mean to put something in this email On 5/23/07, Brigham Stevens <[EMAIL PROTECTED]> wrote: -- ..Cheers Mark
RE: [jira] Commented: (DIRMINA-382) Provide a close() method that doesn't close the connection until all messages are written.
I'm running version 0.9.3 and the session.close() actually does not seem to end the session immediately. We're using session.close() for idle timeouts, and it works great for well-behaved clients. However, for clients who don't read the server responses and thus for whom mina is queuing up write data, the session.close is not closing the session. I assumed it was because mina was processing the queued events in order and therefore the CloseFuture would not be acted upon until the writes had completed. Again, this is with 0.9.3, so maybe things have changed by 1.1 or maybe my assumptions are wrong about why the session.close() command isn't immediate for badly behaved clients. -Original Message- From: Mladen Turk (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 23, 2007 7:24 AM To: dev@mina.apache.org Subject: [jira] Commented: (DIRMINA-382) Provide a close() method that doesn't close the connection until all messages are written. [ https://issues.apache.org/jira/browse/DIRMINA-382?page=com.atlassian.jir a.plugin.system.issuetabpanels:comment-tabpanel#action_12498196 ] Mladen Turk commented on DIRMINA-382: - Why not add shutdown() instead parameterized close. It would also allow adding timeout (someting like lingering on standard sockets) > Provide a close() method that doesn't close the connection until all messages are written. > -- > > > Key: DIRMINA-382 > URL: https://issues.apache.org/jira/browse/DIRMINA-382 > Project: MINA > Issue Type: New Feature > Components: Core >Reporter: Trustin Lee > Fix For: 2.0.0-M1 > > > Currently, IoSession.close() closes the connection immediately no matter how many messages are not written yet. Calling close() will discard all pending writes and close the connection immediately. Although we can add a IoFutureListener.CLOSE to the last WriteFuture, it will be more convenient to provide another close method that doesn't close the connection until all message are written. > Adding a boolean parameter to the close method will be fine. Of course, original method without a parameter will be retained. > To implement this, the implementation should satisfy the following condition. > 1) IoSession.isClosing() must return true after close() is called no matter what boolean parameter is specified. > 2) The session should be closed after all messages are written out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SocketAcceptor processorCount?
Hi Trustin,
Thanks for getting back to me. I know how busy one can get with e-mail on a
popular project. I appreciate your efforts to get back to everyone, even if it
takes some time. It is one of the things that will continue to grow the Mina
community.
Sorry the reply isn't quoted. Yahoo mail isn't doing that properly for some
reason lately.
> 1) Pass only a processorCount parameter and let SocketAcceptor use the most
> appropriate Executor internally. Even better, maybe not use an executor at
> all and just create a thread dedicated to each processorCount. Why bother
> with the overhead of a pool if the thread is basically dedicated to the IO
> processor?
I/O processor threads exit when there's no more channels to manage,
and start to run a new connection is added to it. Creating a new
thread is an expensive task, so providing an executor will improve the
performance. We started to utilize Executor interface because one of
the users wanted to control how the threads are created in a container
environment.
Ok, makes sense. I figured that was the reason. But perhaps you could add one
more constructor for people who want multiple IO threads but don't need control
over the Executors, like the one I proposed below.
> or
>
> 2) Pass only an Executor and if you want a fixed number of IO processors use
> Executor.newFixedThreadPool(nThreads).
>
> My thought is someone could do something like this:
>
> new SocketAcceptor(10, Executor.newFixedThreadPool(3));
>
> And that's probably really a bad idea.
True. it should be Executors.newFixedThreadPool(11). (10 I/O
processors and one acceptor thread).
You should probably add a note in the SocketAcceptor's constructor javadoc
about including a thread for the acceptor in addition to the IO processors. In
the application I am developing I used the same number for IO processors and
executor threads. When I set the IO processors to 1 the server didn't work and
I didn't understand why. Now it makes perfect sense.
new SocketAcceptor(1, Executor.newFixedThreadPool(1)); can never work, and
that's effecitvely what I had.
> If instead the constructors were changed to:
>
> public SocketAcceptor(){
>this(1);
> }
>
> public SocketAcceptor(int processorCount){
>this(processorCount, Executor.newFixedThreadPool(processorCount));
> }
Looks good so far.
Yep, except it should be:
public SocketAcceptor(int processorCount){
this(processorCount, Executor.newFixedThreadPool(processorCount + 1));
}
because the Acceptor thread is needed. Can you add this constructor to
SocketAcceptor? I bet most people would use this constructor instead of either
of the others.
> private SocketAcceptor(int processorCount, Executor executor){
>// existing code of constructor here.
>// or refactor code into SocketAcceptor(int processorCount) constructor
> }
>
> Things would be more bullet proof and prevent someone from making a mistake
> like I've shown above. Since the Executor (actually ExecutorService) is
> internal to the SocketAcceptor it would be responsible for calling
> ExecutorServiceImpl.shutdown(). This could be done in the doUnbind() method
> of SocketAcceptor.
>
> Failing such modifications, the default constructor for SocketAcceptor uses
> NewThreadExecutor(). Wouldn't it be more efficient to use
> Executor.newFixedThreadPool(1)?
It will be more efficient, but user will not have control over the
life cycle of the executor (thread pool). When should shutdown() of
the thread pool called? I think most users will need to control it.
An internal executor should be shut down when when unbind is called. That
could be handled easily within the doUnbind method of SocketAcceptor. All that
is needed is a flag to determine if doUnbind should shutdown the executor. I
would do something like this:
public SocketAcceptor(){
this(1);
}
// I would wager most people would use this constructor.
public SocketAcceptor(int processorCount){
this(1, Executor.newFixedThreadPool(processorCount + 1), true);
}
// for backwards compatibility - also add note that executor should have
processorCount +1 threads if fixed number of threads.
public SocketAcceptor(int processorCount, Executor executor){
this(1, Executor.newFixedThreadPool(processorCount + 1), false);
}
// for full control - add same note as above about fixed number of executor
threads.
public SocketAcceptor(int processorCount, Executor executor, boolean
shutdownOnUnbind){
this.shutdownOnUnbind = shutdownOnUnbind;
if(this.shutdownOnUnbind && ! (executor instanceof ExecutorService)){
throw new IllegalArgumentException("If shutdownOnUnbind is true the
executor must implement ExecutorService.");
}
// all other existing constructor code here.
}
//.other code...
protected void doUnbind() throws IOException{
// all other existing doUnbind() code here.
if(this.shutdownOnUnbind && executor instanceof ExecutorServic
UDP Session Recyler Question
(sorry for the blank message I put To: field to early and somehow bashed my
keyboard badly)
We were having problems with our mina client & server's UDP sessions.
They were being terminated by the ExpiringMap which is part of the
ExpiringSessionRecycler that is used for UDP sessions.
We didn't want that behavior, and also it seemed like it was even
terminating busy sessions that were streaming UDP packets basically at least
30 times a second.
But looking into it, I realized we needed to create our own SessioRecycler
to avoid this. I found this related issue in DIRMINA:
http://issues.apache.org/jira/browse/DIRMINA-319?page=com.atlassian.jira.plu
gin.system.issuetabpanels:all-tabpanel
My question is prompted from Trustin's comment:
"DatagramConnector doesn't use of IoSessionRecycler at all because [EMAIL
PROTECTED]
DatagramConnector} doesn't create a session with the same remote and local
addresses. This is an API design flaw. We don't need DatagramService either
because of the same reason."
So I have implemented the Simple Session Recycler shown below.
My question is, to ensure my session is maintained, should I be using the
DatagramConnector.connect method that includes the local and remote
address(+port) in the client when it connects? I like not having to specify
on the client.
In practice, I have not found specifying the local address/port necessary,
but reading the DIRMINA comments, I just want to make sure that I am on the
right track. If Mina uses the same DatagramChannel the whole time, I don't
think the clients local address(port) would ever change and that is what I'm
seeing, (My recycler seems to work well) but I guess I don't fully
understand the comment in DIRMINA-319.
I noticed that UDP IoSessionHandler's never receive Idle callbacks. This
would be nice to have, but I guess from the other comments in that Issue you
are aware of this, and maybe we will see Idle handlers being called in 2.0!
Here is my SimpleSessionRecycler that avoids getting disconnected:
(Would something like this make a good default recycler for 2.0? So people
would not have to implement a session recycler just to get things running.)
public class SimpleSessionRecycler implements IoSessionRecycler {
Map map = Collections.synchronizedMap(new HashMap());
public void put(IoSession session) {
SocketAddress local = session.getLocalAddress();
SocketAddress remote = session.getRemoteAddress();
map.put(getKey(local, remote), session);
}
long getKey(SocketAddress local, SocketAddress remote) {
long key = ((long) local.hashCode() << 32) | remote.hashCode();
return key;
}
/**
* Attempts to retrieve a recycled [EMAIL PROTECTED] IoSession}.
*
* @param localAddress
*the local socket address of the [EMAIL PROTECTED] IoSession}
the
*transport wants to recycle.
* @param remoteAddress
*the remote socket address of the [EMAIL PROTECTED] IoSession}
the
*transport wants to recycle.
* @return a recycled [EMAIL PROTECTED] IoSession}, or null if one cannot
be found.
*/
public IoSession recycle(SocketAddress localAddress, SocketAddress
remoteAddress) {
IoSession session = map.get(getKey(localAddress, remoteAddress));
return session;
}
public void remove(IoSession session) {
map.remove(getKey(session.getLocalAddress(),
session.getRemoteAddress()));
}
}
What is the difference between so-called asynchronous I/O and non-blocking I/O
Hi, I found some think they are the same. Do you know the difference? Cheers, Dong -- Dong Liu http://blogs.usask.ca/dong_notes/
Re: What is the difference between so-called asynchronous I/O and non-blocking I/O
Dong Liu wrote: Hi, I found some think they are the same. Do you know the difference? With nio you call select and act accordingly to the returned values, with async you register event handlers, and do that for multiple files/sockets. Its something MINA already does internally. Think I've been concise enough ;) Regards, Mladen.
JMX StatCollector & IoSession Attribute
Hi all, I have an application which reuses IoSessions often. Basically as the client sends data, state is built up within the IoSession via a series of attributes. When the server recognizes that an event has taken place, it processes the session, and clears the attributes for the next round of data collection. To facilitate this, I had written a clearAttrs() method which simply iterated through the attribute keys and called IoSession.removeAttribute() on each key. Unfortunately when I added Mina's JMX statistics collection to my app, I began seeing null pointer exceptions in StatCollector$Worker. This was puzzling until I looked at the source and found that stats are gathered in sessions, using the attribute StatCollector.KEY. Of course, it probably isn't the best application design to go around blasting IoSession attributes willy-nilly. However, I know my code, and nothing else was storing attributes on IoSessions until I started working with JMX. It would be nice to have a mention of this on the Mina+JMX wiki page for future reference. Thanks, -- Ben PGP.sig Description: This is a digitally signed message part
Re: SSL Client does not send any data
Hi, I apologize for nagging but could someone please confirm or not if this is happening to other people? I've tried it on another computer at work and it can be reproduced always. Regards, Horia seven wrote: > > > Trustin Lee wrote: >> >> On 5/9/07, seven <[EMAIL PROTECTED]> wrote: >>> >>> Hello, >>> >>> I have a problem with mina-filter-ssl-1.1.0 release: sometimes for >>> unknown >>> reasons and in an arbitrary way, after a client connects to a SSL >>> enabled >>> server, it does not send anything. On the server side and the client >>> side as >>> well, only CREATED and OPENED events are fired and nothing further >>> happens ( >>> except IDDLE events ) even if the client issued the first >>> session.write(). >>> >>> In order to reproduce this, I wrote a simple client that connects to the >>> echo server found in the examples. >>> org.apache.mina.example.echoserver.Main should be modified with >>> USE_SSL=true, PORT = 8090 and bogus.cert has to be generated as >>> documented >>> in org.apache.mina.example.echoserver.ssl.BogusSSLContextFactory and >>> placed >>> in the classpath of the server and server launchers. >>> >>> Until mina-1.1.0 was released I worked with a snapshot release and did >>> not >>> encounter this problem. So if one uses a >>> mina-filter-ssl-1.1.0-SNAPSHOT.jar >>> instead of mina-filter-ssl-1.1.0.jar the 'silence' problem does not >>> occur. >>> Fortunately I have the snapshot sources from the svn that were used to >>> build >>> mina-filter-ssl-1.1.0-SNAPSHOT.jar. >>> The revision number for the working SSLHandler is 471502 respectively >>> 507461 >>> for SSLFilter. >>> >>> Attached is the client source that reproduces the problem. It has to be >>> placed in org.apache.mina.example.echoserver package. >>> >>> Regards, >>> Horia >>> http://www.nabble.com/file/8269/Client.java Client.java >> >> I made a big change in SSLFilter and SSLHandler to fix a deadlock >> issue when releasing 1.1.0.But I couldn't reproduce your problem >> with the source code you provided. How often can it be reproduced? >> >> Please attach the full thread dump and the log file with DEBUG level >> enabled for MINA. >> >> Trustin >> -- >> what we call human nature is actually human habit >> -- >> http://gleamynode.net/ >> -- >> PGP Key ID: 0x0255ECA6 >> >> > > The problem can be reproduced always. I reproduced this situation with > JDK1.5.0 as well even if with JDK1.5.0 takes much longer to happen: let it > run for 5 minutes or more. With JDK1.6.0 it happens in few seconds. > > Below I attached 4 files: 2 for the server and client with jdk1.5.0_05 and > the other 2 for server and client with jdk1.6.0_01. I've hit Ctlr+Break > when I saw that the client did't send any data. In the JDK1.6.0 related > files you can see how the client and server were started. If a more > verbose ( DEBUG ) level is wanted, could you please tell me how can I > enable DEBUG level for the Simple wrapper of SLF4J? > > http://www.nabble.com/file/8419/jdk1.5.0_5.client.txt > jdk1.5.0_5.client.txt > http://www.nabble.com/file/8420/jdk1.5.0_5.server.txt > jdk1.5.0_5.server.txt > http://www.nabble.com/file/8421/jdk1.6.0_01.client.txt > jdk1.6.0_01.client.txt > http://www.nabble.com/file/8422/jdk1.6.0_01.server.txt > jdk1.6.0_01.server.txt > > Regards, > Horia > > -- View this message in context: http://www.nabble.com/SSL-Client-does-not-send-any-data-tf3714505.html#a10773054 Sent from the mina dev mailing list archive at Nabble.com.
RE: SSL Client does not send any data
Hey, I'm using MINA 1.1 and tracking a problem where byte buffers stay in the outgoing queue and are never flushed. So far the problem is hiding from me. :( Not sure if that is also your case. Any ideas on this issue? Thanks, -- Gato -Original Message- From: seven [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 23, 2007 2:22 PM To: dev@mina.apache.org Subject: Re: SSL Client does not send any data Hi, I apologize for nagging but could someone please confirm or not if this is happening to other people? I've tried it on another computer at work and it can be reproduced always. Regards, Horia seven wrote: > > > Trustin Lee wrote: >> >> On 5/9/07, seven <[EMAIL PROTECTED]> wrote: >>> >>> Hello, >>> >>> I have a problem with mina-filter-ssl-1.1.0 release: sometimes for >>> unknown >>> reasons and in an arbitrary way, after a client connects to a SSL >>> enabled >>> server, it does not send anything. On the server side and the client >>> side as >>> well, only CREATED and OPENED events are fired and nothing further >>> happens ( >>> except IDDLE events ) even if the client issued the first >>> session.write(). >>> >>> In order to reproduce this, I wrote a simple client that connects to the >>> echo server found in the examples. >>> org.apache.mina.example.echoserver.Main should be modified with >>> USE_SSL=true, PORT = 8090 and bogus.cert has to be generated as >>> documented >>> in org.apache.mina.example.echoserver.ssl.BogusSSLContextFactory and >>> placed >>> in the classpath of the server and server launchers. >>> >>> Until mina-1.1.0 was released I worked with a snapshot release and did >>> not >>> encounter this problem. So if one uses a >>> mina-filter-ssl-1.1.0-SNAPSHOT.jar >>> instead of mina-filter-ssl-1.1.0.jar the 'silence' problem does not >>> occur. >>> Fortunately I have the snapshot sources from the svn that were used to >>> build >>> mina-filter-ssl-1.1.0-SNAPSHOT.jar. >>> The revision number for the working SSLHandler is 471502 respectively >>> 507461 >>> for SSLFilter. >>> >>> Attached is the client source that reproduces the problem. It has to be >>> placed in org.apache.mina.example.echoserver package. >>> >>> Regards, >>> Horia >>> http://www.nabble.com/file/8269/Client.java Client.java >> >> I made a big change in SSLFilter and SSLHandler to fix a deadlock >> issue when releasing 1.1.0.But I couldn't reproduce your problem >> with the source code you provided. How often can it be reproduced? >> >> Please attach the full thread dump and the log file with DEBUG level >> enabled for MINA. >> >> Trustin >> -- >> what we call human nature is actually human habit >> -- >> http://gleamynode.net/ >> -- >> PGP Key ID: 0x0255ECA6 >> >> > > The problem can be reproduced always. I reproduced this situation with > JDK1.5.0 as well even if with JDK1.5.0 takes much longer to happen: let it > run for 5 minutes or more. With JDK1.6.0 it happens in few seconds. > > Below I attached 4 files: 2 for the server and client with jdk1.5.0_05 and > the other 2 for server and client with jdk1.6.0_01. I've hit Ctlr+Break > when I saw that the client did't send any data. In the JDK1.6.0 related > files you can see how the client and server were started. If a more > verbose ( DEBUG ) level is wanted, could you please tell me how can I > enable DEBUG level for the Simple wrapper of SLF4J? > > http://www.nabble.com/file/8419/jdk1.5.0_5.client.txt > jdk1.5.0_5.client.txt > http://www.nabble.com/file/8420/jdk1.5.0_5.server.txt > jdk1.5.0_5.server.txt > http://www.nabble.com/file/8421/jdk1.6.0_01.client.txt > jdk1.6.0_01.client.txt > http://www.nabble.com/file/8422/jdk1.6.0_01.server.txt > jdk1.6.0_01.server.txt > > Regards, > Horia > > -- View this message in context: http://www.nabble.com/SSL-Client-does-not-send-any-data-tf3714505.html#a 10773054 Sent from the mina dev mailing list archive at Nabble.com.
Help creating a filter
I'm having some trouble creating a filter. I need a filter that reads the content of the first received message for authentication purposes. I'm trying to do something like the EchoProtocolHandler does for reading the message: ByteBuffer rb = ( ByteBuffer ) message; // Write the received data back to remote peer ByteBuffer wb = ByteBuffer.allocate( rb.remaining() ); wb.put( rb ); wb.flip(); ... Now, this code works fine in a handler class (extends IoHandlerAdapter)... and in my conception, it should work when placed in the messageReceived method of a filter (extends LoggingFilter) aswell. The thing is that it doesn't. I'm having an exception thrown at me because of theByteBuffer rb = ( ByteBuffer ) message; line : org.apache.mina.filter.SSLFilter$SSLFilterMessage cannot be cast to org.apache.mina.common.ByteBuffer at org.apache.mina.example.echoserver.LogbackFilter.messageReceived(LogbackFilter.java:66) Well, to put things short, the line ByteBuffer rb = ( ByteBuffer ) message; doesn't seem to work in a filter. Does anybody know why this exception is being thrown and what I can do to fix/work around it? Thanks in advance, André
Re: What is the difference between so-called asynchronous I/O and non-blocking I/O
So that means asynchronous I/O is what one can observe, and it can be implemented or has already be implemented by NIO. And I think NIO is also one of the approaches to implementing asynchronous messaging or processing. I am not sure if I am right. Please comment. Cheers, Dong On 5/23/07, Mladen Turk <[EMAIL PROTECTED]> wrote: Dong Liu wrote: > Hi, > > I found some think they are the same. Do you know the difference? > With nio you call select and act accordingly to the returned values, with async you register event handlers, and do that for multiple files/sockets. Its something MINA already does internally. Think I've been concise enough ;) Regards, Mladen. -- Dong Liu http://blogs.usask.ca/dong_notes/
Direct Buffers and ExecutorFilter in MINA 1.1.0
Hi folks, Is necessary disable the direct buffers on the 1.1.0 version?? I mean: ByteBuffer.setUseDirectBuffers(false); ByteBuffer.setAllocator(new SimpleByteBufferAllocator()); I was looking in the changes between version and I've not found anything about. Another little question: Is a good idea to add an ExecutorFilter in a SocketConnector (client) taking into account that my protocol codec filter is doing cryptographic operations?? Thanks in advance, Best regards. LUIS ALBERTO PEREZ PAZ [EMAIL PROTECTED] +52 (55) 5227-8842 Fax +52 (55) 5227-8759 BANCO DE MEXIC0
Re: What is the difference between so-called asynchronous I/O and non-blocking I/O
AFAIK they are the same. Asynchronous and non-blocking are identical in this context. They both mean that you don't have to wait for a response to continue (as oposed to synchronous or blocking I/O). You need to work with event handlers to process the responses (as mentioned by Mladen). Check out http://en.wikipedia.org/wiki/Asynchronous_io if you want to know more. Jeroen Brattinga Dong Liu wrote: Hi, I found some think they are the same. Do you know the difference? Cheers, Dong
Re: [jira] Commented: (DIRMINA-382) Provide a close() method that doesn't close the connection until all messages are written.
On 23/05/2007, at 8:54 PM, Mladen Turk (JIRA) wrote: Why not add shutdown() instead parameterized close. It would also allow adding timeout (someting like lingering on standard sockets) Assuming MINA can't go back to close () having this behaviour (I think most people would expect a close () to imply a flush), this sounds good to me. Matthew.
