setIdleTime() problem in 1.1.5?
Hi, We recently upgraded from MINA 1.0 to 1.1.5 and we seem to have problems with IoSession.setIdleTime(). In sessionCreated() we set it like this: session.setIdleTime(IdleStatus.BOTH_IDLE, 3600); Yet some sessions seem to get a sessionIdle() callback within only a few seconds/minutes instead of after 60 minutes as expected. Has anyone else experienced similar problems with 1.1.5? /Niklas
Re: AsyncHttpClient, Connector, disposing and parked threads
On Mon, 28 Jan 2008 12:29:56 -0500 Alex Karasulu [EMAIL PROTECTED] wrote: Hi Julien, Thanks for the update to the mailing list. On Jan 28, 2008 12:25 PM, Julien Vermillard [EMAIL PROTECTED] wrote: Hi, Following an IRC convo, between alex, tazle and me : We had a few complaint recently about remaining unclosed socket and thread after multiple connection using the NioSocketConnector or simply the AsyncHttpClient not releasing correctly file descriptor on linux. The problem for AsyncHttpClient is was because each connection create a NioSocketConnector and forget to .dispose() it. When you connect and close a session a thread will remain in the threadpool for 1 minute (it's the default behaviour), you can still overide it specifying another Executorfilter behaviour. BTW AHC is using 1 SocketConnector per AHC instance, I think it should be changed to share it. I fully agree. I just have to get up to speed enough figure out how this can be done. Any suggestions? Thanks, Alex Perhaps AHC should be invoked 1 time and be used for multiple http connections, so you can have 1 NioSocketAcceptor/selector per AHC and shared across http connections. That would prevent to instanciate a lot of objects and save some memory (connector, handler, codec, etc..). Another issues with AHC is the way you recieve the result of your connection in a big IoBuffer, it should be nice to be able to receive big results like files or http streaming in chunks and no a big memory buffer. Julien
RE: AsyncHttpClient, Connector, disposing and parked threads
Julien Vermillard wrote: Another issues with AHC is the way you recieve the result of your connection in a big IoBuffer, it should be nice to be able to receive big results like files or http streaming in chunks and no a big memory buffer. Something I always wanted to find time to get round to in AsyncWeb :o) Not sure how applicable this will be to the current code base, but some of my initial thoughts on this from way back in the day can be found here: http://jira.safehaus.org/browse/ASYNCWEB-21 Should be applicable to client as well as server I would of thought. Julien Dave
[jira] Work stopped: (DIRMINA-513) get rid of IoSessionLogger
[ https://issues.apache.org/jira/browse/DIRMINA-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on DIRMINA-513 stopped by Maarten Bosteels. get rid of IoSessionLogger --- Key: DIRMINA-513 URL: https://issues.apache.org/jira/browse/DIRMINA-513 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 2.0.0-M1 Reporter: Maarten Bosteels Assignee: Maarten Bosteels Priority: Minor Fix For: 2.0.0-M1 It seems like the next version of SLF4J is going to support MDC for java.util.logging The users who use java.util.logging as their logging framework will have access to MDC so that they can implement a formatter which prints out the MDC content. This means we can get rid of IoSessionLogger completely and rely on MdcInjectionFilter However, probably SLF4J won't provide a MDC-aware Formatter implementation for java.util.logging, so we might need to include it in org.apache.mina.util package as an alternative solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-513) get rid of IoSessionLogger
[ https://issues.apache.org/jira/browse/DIRMINA-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563432#action_12563432 ] Maarten Bosteels commented on DIRMINA-513: -- IoSessionLogger has been removed, but I could not yet add MDC-aware Formatter implementations because the new SLF4J hasn't been released. I also fixed a performance issue in LoggingFilter: message.toString() was invoked for every messageReceived and messageSent event, regardless of the configured log-levels. get rid of IoSessionLogger --- Key: DIRMINA-513 URL: https://issues.apache.org/jira/browse/DIRMINA-513 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 2.0.0-M1 Reporter: Maarten Bosteels Assignee: Maarten Bosteels Priority: Minor Fix For: 2.0.0-M1 It seems like the next version of SLF4J is going to support MDC for java.util.logging The users who use java.util.logging as their logging framework will have access to MDC so that they can implement a formatter which prints out the MDC content. This means we can get rid of IoSessionLogger completely and rely on MdcInjectionFilter However, probably SLF4J won't provide a MDC-aware Formatter implementation for java.util.logging, so we might need to include it in org.apache.mina.util package as an alternative solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: AsyncHttpClient, Connector, disposing and parked threads
On Tue, 29 Jan 2008 08:39:14 + Irving, Dave [EMAIL PROTECTED] wrote: Julien Vermillard wrote: Another issues with AHC is the way you recieve the result of your connection in a big IoBuffer, it should be nice to be able to receive big results like files or http streaming in chunks and no a big memory buffer. Something I always wanted to find time to get round to in AsyncWeb :o) Not sure how applicable this will be to the current code base, but some of my initial thoughts on this from way back in the day can be found here: http://jira.safehaus.org/browse/ASYNCWEB-21 Should be applicable to client as well as server I would of thought. Julien Dave Yeap, I think it's a good idea for both server and client because in the current state sending/receiving large data or stream is pretty dangerous. I think we better to it that soon because the impact on the API will be important. Julien
Re: Cast Problem in Handler
Hi,
MINA provide you by default buffer of bytes and not Strings, you
shoudl take a look at this example :
http://svn.apache.org/viewvc/mina/branches/1.0/example/src/main/java/org/apache/mina/example/reverser/
And specificly to this code :
SocketAcceptorConfig cfg = new SocketAcceptorConfig();
cfg.getFilterChain().addLast(
codec,
new ProtocolCodecFilter(new TextLineCodecFactory(Charset
.forName(UTF-8;
It's adding a codec filter for decoding raw bytes into String
HTH,
Julien
On Tue, 29 Jan 2008 13:12:02 -0400
Brenno Hayden [EMAIL PROTECTED] wrote:
Hi,
I have one problem. When I do a cast in the code below
Public class MyHanlder extends IoHandlerAdapter {
public void messageReceived(IoSession session, Object message) {
String s = (String)message;
Has the following problem
org.apache.mina.util.SessionLog warn
WARNING: [/127.0.0.1:3696] EXCEPTION, please implement
mypackage.MyHandler.exceptionCaught() for proper handling:
java.lang.ClassCastException:
org.apache.mina.common.PooledByteBufferAllocator$PooledByteBuffer
at mypackage.MyHandler.messageReceived(MyHandler.java:52)
ps: I'm using java 5 e framework 1.1.5 for java 5
Brenno Hayden F. Dantas
Cast Problem in Handler
Hi,
I have one problem. When I do a cast in the code below
Public class MyHanlder extends IoHandlerAdapter {
public void messageReceived(IoSession session, Object message) {
String s = (String)message;
Has the following problem
org.apache.mina.util.SessionLog warn
WARNING: [/127.0.0.1:3696] EXCEPTION, please implement
mypackage.MyHandler.exceptionCaught() for proper handling:
java.lang.ClassCastException:
org.apache.mina.common.PooledByteBufferAllocator$PooledByteBuffer
at mypackage.MyHandler.messageReceived(MyHandler.java:52)
ps: I'm using java 5 e framework 1.1.5 for java 5
Brenno Hayden F. Dantas
Re: AsyncHttpClient, Connector, disposing and parked threads
On Jan 29, 2008 2:39 AM, Irving, Dave [EMAIL PROTECTED] wrote: Something I always wanted to find time to get round to in AsyncWeb :o) Not sure how applicable this will be to the current code base, but some of my initial thoughts on this from way back in the day can be found here: http://jira.safehaus.org/browse/ASYNCWEB-21 Alex... Dave's reference to the Safehaus JIRA reminds that perhaps we need to those JIRA issues to the new Apache JIRA you setup for AsyncWeb.
translate the Mina framework to IL to use with C# on Mono .Net
Hi, I would like to translate the Mina framework to IL to use with C# on Mono .Net. Would this be of interest to the Mina community? - Robert
Re: Cast Problem in Handler
Hi Julien,
Thank you, helped a lot! The source-code is fine, now.
thanks
On Jan 29, 2008 1:20 PM, Julien Vermillard [EMAIL PROTECTED] wrote:
Hi,
MINA provide you by default buffer of bytes and not Strings, you
shoudl take a look at this example :
http://svn.apache.org/viewvc/mina/branches/1.0/example/src/main/java/org/apache/mina/example/reverser/
And specificly to this code :
SocketAcceptorConfig cfg = new SocketAcceptorConfig();
cfg.getFilterChain().addLast(
codec,
new ProtocolCodecFilter(new TextLineCodecFactory(Charset
.forName(UTF-8;
It's adding a codec filter for decoding raw bytes into String
HTH,
Julien
On Tue, 29 Jan 2008 13:12:02 -0400
Brenno Hayden [EMAIL PROTECTED] wrote:
Hi,
I have one problem. When I do a cast in the code below
Public class MyHanlder extends IoHandlerAdapter {
public void messageReceived(IoSession session, Object message) {
String s = (String)message;
Has the following problem
org.apache.mina.util.SessionLog warn
WARNING: [/127.0.0.1:3696] EXCEPTION, please implement
mypackage.MyHandler.exceptionCaught() for proper handling:
java.lang.ClassCastException:
org.apache.mina.common.PooledByteBufferAllocator$PooledByteBuffer
at mypackage.MyHandler.messageReceived(MyHandler.java:52)
ps: I'm using java 5 e framework 1.1.5 for java 5
Brenno Hayden F. Dantas
--
Brenno Hayden F. Dantas
Re: AsyncHttpClient, Connector, disposing and parked threads
Yeah we need to get them transfered over. I'll figure out how we can do that. I also need to get some confluence things taken care of as well so we can start collaborating and transfer the site over. All on my TODO list. If others want to help out in this process please let me know I'm overloaded with work so it might take me a while. Alex On Jan 29, 2008 12:57 PM, Timothy Bennett [EMAIL PROTECTED] wrote: On Jan 29, 2008 2:39 AM, Irving, Dave [EMAIL PROTECTED] wrote: Something I always wanted to find time to get round to in AsyncWeb :o) Not sure how applicable this will be to the current code base, but some of my initial thoughts on this from way back in the day can be found here: http://jira.safehaus.org/browse/ASYNCWEB-21 Alex... Dave's reference to the Safehaus JIRA reminds that perhaps we need to those JIRA issues to the new Apache JIRA you setup for AsyncWeb.
Re: Getting UDP packet source
Hi,
keep on code
@Override
public void messageReceived(IoSession session, Object message) {
TransportType transportType = session.getTransportType();
InetSocketAddress address =
(InetSocketAddress)session.getLocalAddress();
System.out.println(address.getAddress());
System.out.println(address.getPort());
if (transportType == TransportType.SOCKET) {
System.out.println(tcp);
} else if (transportType == TransportType.DATAGRAM) {
System.out.println(udp);
}
}
On Jan 29, 2008 5:27 AM, yangzhang [EMAIL PROTECTED] wrote:
Relaying trustin's answer from FreeNode: session.getRemoteAddress(), since
session is actually different for each unique source socket.
yangzhang wrote:
How do I get the source IP address and UDP port of a UDP packet received
in this fashion?
public final class Receiver extends IoHandlerAdapter {
@Override
public void messageReceived(IoSession session, Object obj)
throws Exception {
...
Thanks in advance!
--
View this message in context:
http://www.nabble.com/Getting-UDP-packet-source-tp15148498s16868p15155573.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com
.
--
Brenno Hayden F. Dantas
Re: [OT] was: AsyncHttpClient, Connector, disposing and parked threads
On Jan 29, 2008 2:18 AM, Irving, Dave [EMAIL PROTECTED] wrote: Hey - absolutely great to see AsyncWeb alive and kicking!! Hopefully I'll have enough time to start getting properly involved again later in the year! Kindest regards to all, Good to see you, Dave! Glad you are at least lurking on the list, and hopefully you'll be able to lend whatever you can as your schedule permits. Timothy
Re: translate the Mina framework to IL to use with C# on Mono .Net
I could use that. As a matter of fact, I toyed with the idea of doing it myself, but don't have time. On Jan 29, 2008 10:02 AM, Robert Johnson [EMAIL PROTECTED] wrote: Hi, I would like to translate the Mina framework to IL to use with C# on Mono .Net. Would this be of interest to the Mina community? - Robert -- Cheers, Kevin Williams http://www.bantamtech.com/ http://www.almostserio.us/ http://kevwil.com/
[jira] Created: (DIRMINA-523) Default thread model should be created laziliy
Default thread model should be created laziliy
--
Key: DIRMINA-523
URL: https://issues.apache.org/jira/browse/DIRMINA-523
Project: MINA
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.5
Reporter: Kristjan Habicht
Currently when BaseIoServiceConfig is created then also ExecutorThreadModel is
created. This creates additional 16 threads which will not be shut down even if
ThreadModel.MANUAL is used.
Here is a patch which will fix this problem by creating the ExecutorThreadModel
lazily if the ThreadModel is not set.
Index: BaseIoServiceConfig.java
===
--- BaseIoServiceConfig.java(revision 616503)
+++ BaseIoServiceConfig.java(working copy)
@@ -40,20 +40,14 @@
private IoFilterChainBuilder filterChainBuilder = new
DefaultIoFilterChainBuilder();
/**
- * The default thread model.
- */
-private final ThreadModel defaultThreadModel = ExecutorThreadModel
-.getInstance(AnonymousIoService);
-
-/**
* Current thread model.
*/
-private ThreadModel threadModel = defaultThreadModel;
+private ThreadModel threadModel;
public BaseIoServiceConfig() {
super();
}
-
+
public IoFilterChainBuilder getFilterChainBuilder() {
return filterChainBuilder;
}
@@ -75,15 +69,15 @@
}
public ThreadModel getThreadModel() {
-return threadModel;
+ if (threadModel == null) {
+ // if thread model hasn't been set return the default one
+ return getDefaultThreadModel();
+ } else {
+ return threadModel;
+ }
}
public void setThreadModel(ThreadModel threadModel) {
-if (threadModel == null) {
-// We reuse the previous default model to prevent too much
-// daemon threads are created.
-threadModel = defaultThreadModel;
-}
this.threadModel = threadModel;
}
@@ -110,4 +104,11 @@
return ret;
}
+
+/**
+ * @return The default thread model.
+ */
+private static ThreadModel getDefaultThreadModel() {
+ return ExecutorThreadModel.getInstance(AnonymousIoService);
+}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Asyncweb] New confluence space requested.
Hey guys I might have missed a few people so please add your name to the JIRA issue as comments. I realized Jullien and Mike were not on there. Didn't know if you wanted to be. Alex On Jan 29, 2008 2:57 PM, Alex Karasulu [EMAIL PROTECTED] wrote: Just an FYI, https://issues.apache.org/jira/browse/INFRA-1502 Will notify when this space has been created. Thanks, Alex
[Asyncweb] New confluence space requested.
Just an FYI, https://issues.apache.org/jira/browse/INFRA-1502 Will notify when this space has been created. Thanks, Alex
Re: AsyncHttpClient, Connector, disposing and parked threads
On Jan 29, 2008 12:05 PM, Alex Karasulu [EMAIL PROTECTED] wrote: Yeah we need to get them transfered over. I'll figure out how we can do that. I also need to get some confluence things taken care of as well so we can start collaborating and transfer the site over. All on my TODO list. If others want to help out in this process please let me know I'm overloaded with work so it might take me a while. The confluence site request submitted to infrastructure.[1] [1] https://issues.apache.org/jira/browse/INFRA-1502
Re: setIdleTime() problem in 1.1.5?
Niklas Therning wrote: Hi, We recently upgraded from MINA 1.0 to 1.1.5 and we seem to have problems with IoSession.setIdleTime(). In sessionCreated() we set it like this: session.setIdleTime(IdleStatus.BOTH_IDLE, 3600); Yet some sessions seem to get a sessionIdle() callback within only a few seconds/minutes instead of after 60 minutes as expected. Has anyone else experienced similar problems with 1.1.5? Seems I was mistaken. I interpreted my logs incorrectly. setIdleTime() in MINA 1.1.5 works just as expected as far as I can tell. -- Niklas Therning www.spamdrain.net
[AsyncHttpClient] On bringing the code bases and communities together
Hi, Please excuse the cross post but it's quite necessary. Furthermore people should not feel like they cannot cross post responses so please feel free. It looks like the two versions of the http client based on MINA are starting to diverge. I've noticed the other day that some of the fixes for bugs already solved by one group are being re-implement all over again over again by another. It's a shame to have that happen so perhaps we can take some concrete steps to prevent this divergence from progressing. As a first step I've cleaned up and restructured the Asyncweb code base and posted this email here on the new directory structure in Subversion: *http://tinyurl.com/ypmbd3 *So I'm sending out this cross post in the hopes of bringing the two groups together as one unified community which apparently has the same goal in mind: a fast low-resource consuming asynchronous http client. What ever it takes, I'm sure the MINA PMC is more than willing to accommodate. If you have trusted committers already working on this in the Geronimo community there is no reason why we cannot trust them to continue working on it here at MINA's Asyncweb project. Let's open up discussions on this. Specifically I ask the Geronimo committers working on AHC to let us know what we can do to take concrete next steps. Thanks, Alex
Re: [AsyncWeb] Client redesign
Mike Heath wrote: [...] This topic came up on the IRC channel and David Lloyd (dmlloyd), Tuure Laurinolli (tazle), and I (mike_heath) were discussing better alternatives to the current design. The following is a summary of our conversation. And while Mike was typing up this excellent summary, the discussion continued, so here's the next part. :-) David posted this mockup as a possible future API http://rafb.net/p/P8GLTg85.html David wanted me to be sure to note that the class names in the mockup are just for purposes of explanation may change. So basically there's been a number of suggestions as to what to name these things. Here are the two options: Name from pastebin Option 1 Option 2 - -- AsyncHttpClientHttpClientFactory HttpClient HttpRequestor HttpClientHttpConnector HttpFuture HttpFutureHttpFuture So everyone liked HttpFuture. HttpRequestor is universally reviled (I don't like that one either). Mike suggested option 2, Tuure thought of Option 1. I pointed out that Option 2 might cause problems in that people may confuse IoConnector with HttpConnector, though they represent different concepts. Tuure stated that after typing HttpClientFactory a few times, he started to like Option 2 some more. Of course nothing is decided until everyone has had a chance to weigh in. - DML
Re: [AsyncWeb] Client redesign
Hi guys, I'm fine with anything y'all select for the name. I'm much more interested in figuring out how to get some of these resource issues settled and the two forks of this merged together so we have more people working together on this. Please see my thread on how to bring the Geronimo folks who are developing the other fork within the Geronimo sandbox. It would be a shame to have both groups working on the same issues. Perhaps you want them in on this conversation as well before we diverge on the class names as well. Alex On Jan 29, 2008 5:55 PM, David M. Lloyd [EMAIL PROTECTED] wrote: Mike Heath wrote: [...] This topic came up on the IRC channel and David Lloyd (dmlloyd), Tuure Laurinolli (tazle), and I (mike_heath) were discussing better alternatives to the current design. The following is a summary of our conversation. And while Mike was typing up this excellent summary, the discussion continued, so here's the next part. :-) David posted this mockup as a possible future API http://rafb.net/p/P8GLTg85.html David wanted me to be sure to note that the class names in the mockup are just for purposes of explanation may change. So basically there's been a number of suggestions as to what to name these things. Here are the two options: Name from pastebin Option 1 Option 2 - -- AsyncHttpClientHttpClientFactory HttpClient HttpRequestor HttpClientHttpConnector HttpFuture HttpFutureHttpFuture So everyone liked HttpFuture. HttpRequestor is universally reviled (I don't like that one either). Mike suggested option 2, Tuure thought of Option 1. I pointed out that Option 2 might cause problems in that people may confuse IoConnector with HttpConnector, though they represent different concepts. Tuure stated that after typing HttpClientFactory a few times, he started to like Option 2 some more. Of course nothing is decided until everyone has had a chance to weigh in. - DML
Re: Configuring UDP application for performance
The Configuring Thread Model page should also apply for UDP-based systems. Just make sure you are not using an ExecutorFilter and you can pass in an Executor that only uses one thread. On Jan 29, 2008 5:14 PM, Yang Zhang [EMAIL PROTECTED] wrote: I was profiling my MINA-based application (which runs on CPU- and memory-constrained machines) and determined that MINA uses a surprisingly large number of threads (dozens of DatagramAcceptor/AnonymousIoService threads). I had not configured MINA, so I looked at the Configuring Thread Model documentation, but it wasn't very helpful, in part since it is written for TCP applications. As I understand things, most of MINA's defaults and its documentation assume that the application is a stream-socket-based server where connections can be handled roughly independently. The problem is that I'm writing a UDP-based routing overlay network, meaning that I maintain a single piece of state. A single-threaded reactor would serve best for my application. While there *are* fine-grained opportunities for concurrent handling of packets, MINA has no awareness of the circumstances under which they may be exploited, so concurrency should be left up to the application. As a simplified example, based on a received message type, I may hand off a long-running computation to a separate worker thread, but the norm is to reply immediately. The dual, which is how things work currently, is that usually multiple IO reactor threads contend for a global lock on the state (introducing unnecessary synchronization overhead, memory consumption, etc.), and occasionally a reactor thread does not require the global lock and proceeds with the long-running computation. It would be further beneficial if I could use the same reactor thread to schedule tasks, rather than using a separate ScheduleExecutorService, since these tasks end up executing in serial order anyway with packet handling. I had posted previously about this: http://www.nabble.com/Asynchronous-timeout-sleep-delay-etc.-tt12893472.html Does anyone have advice on how to configure MINA to best suit my needs? And if I can in fact configure everything to run in a single thread, does MINA special-case this to introduce zero synchronization overhead? I'd like to not remove MINA since time is short, but alas, time is short. :) Thanks in advance. -- Yang Zhang http://www.mit.edu/~y_z/ http://www.mit.edu/%7Ey_z/ -- Talent hits a target no one else can hit; Genius hits a target no one else can see.
Re: [AsyncHttpClient] On bringing the code bases and communities together
Alex Karasulu wrote: Hi, Please excuse the cross post but it's quite necessary. Furthermore people should not feel like they cannot cross post responses so please feel free. It looks like the two versions of the http client based on MINA are starting to diverge. I've noticed the other day that some of the fixes for bugs already solved by one group are being re-implement all over again over again by another. It's a shame to have that happen so perhaps we can take some concrete steps to prevent this divergence from progressing. As a first step I've cleaned up and restructured the Asyncweb code base and posted this email here on the new directory structure in Subversion: *http://tinyurl.com/ypmbd3 *So I'm sending out this cross post in the hopes of bringing the two groups together as one unified community which apparently has the same goal in mind: a fast low-resource consuming asynchronous http client. What ever it takes, I'm sure the MINA PMC is more than willing to accommodate. If you have trusted committers already working on this in the Geronimo community there is no reason why we cannot trust them to continue working on it here at MINA's Asyncweb project. Let's open up discussions on this. I totally agree with Alex on this. It looks there are fixes in the G branch that haven't made it to the MINA branch. How can bridge the gap in communication as well as the gap in bug fixing? My opinion is that we need to stop all work on the G sandbox branch and move all work over to MINA. Is there anything impeding that? ...besides a lot of work merging the changes... -Mike
Re: AsyncHttpClient, Connector, disposing and parked threads
Yes...that problem was fixed as well as a host of others. Jeff Alex Karasulu wrote: Someone from Geronimo mentioned that this problem was actually fixed in the Geronimo version a while back. Perhaps something we should look into or inquire about. Jeff can you give us an update on that? Alex On Jan 28, 2008 12:25 PM, Julien Vermillard [EMAIL PROTECTED] wrote: Hi, Following an IRC convo, between alex, tazle and me : We had a few complaint recently about remaining unclosed socket and thread after multiple connection using the NioSocketConnector or simply the AsyncHttpClient not releasing correctly file descriptor on linux. The problem for AsyncHttpClient is was because each connection create a NioSocketConnector and forget to .dispose() it. When you connect and close a session a thread will remain in the threadpool for 1 minute (it's the default behaviour), you can still overide it specifying another Executorfilter behaviour. BTW AHC is using 1 SocketConnector per AHC instance, I think it should be changed to share it. Julien
Re: AsyncHttpClient, Connector, disposing and parked threads
The current Geronimo AHC doesn't seem to have much in common with the current MINA AHC, and seems clearly superior to it in functionality and robustness. However, it also seems to have radically different API, including seemingly totally different underlying HTTP codec. It also doesn't seem to address some of the problems that should be addressed by this now-starting AHC work, like large/long-running responses and requests. Jeff Genender wrote: Yes...that problem was fixed as well as a host of others. Jeff Alex Karasulu wrote: Someone from Geronimo mentioned that this problem was actually fixed in the Geronimo version a while back. Perhaps something we should look into or inquire about. We had a few complaint recently about remaining unclosed socket and thread after multiple connection using the NioSocketConnector or simply the AsyncHttpClient not releasing correctly file descriptor on linux.
Re: [AsyncWeb] Client redesign
David M. Lloyd wrote: So basically there's been a number of suggestions as to what to name these things. Here are the two options: Name from pastebin Option 1 Option 2 - -- AsyncHttpClientHttpClientFactory HttpClient HttpRequestor HttpClientHttpConnector HttpFuture HttpFutureHttpFuture Going with Option 1, I took a look at what the current MINA AHC would look like with this API - the result is at http://www.laurinolli.fi/~tazle/http-client-trivial-implementation.patch It isn't exactly like current AHC (it's not possible to close connections at the moment), but pretty close. The AHC tests run, for example. This implementation gets rid of the resource leaks caused by constantly creating and not disposing NioSocketConnectors, but does not even try to address pipelining or large requests. Of course nothing is decided until everyone has had a chance to weigh in. Indeed - I don't particularly like the code I wrote, but I think it needed to be written in order to see what hoops there were to jump through. I think the HttpHandler and HttpFuture interfaces are bad, especially the way IoHandler events are converted into HttpFuture/HttpHandler events. HttpClient on the other hand seems like an interface we should have. It seems ideal for hiding the complexity of possible pipelining or request pooling.
[jira] Updated: (ASYNCWEB-1) AsyncHttpClient does not dispose its NioSocketConnector
[ https://issues.apache.org/jira/browse/ASYNCWEB-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tuure Laurinolli updated ASYNCWEB-1: Attachment: fix-deadlock.patch Reverts deadlock-inuding change. AsyncHttpClient does not dispose its NioSocketConnector --- Key: ASYNCWEB-1 URL: https://issues.apache.org/jira/browse/ASYNCWEB-1 Project: Asyncweb Issue Type: Bug Reporter: Tuure Laurinolli Attachments: add-dispose-method.patch, fix-deadlock.patch As has been discussed on the MINA mailing list, NioSocketConnector does not dispose its NioSocketConnector when it isn't used anymore. This leads to significant resource leakage (on my Java 1.6 / Linux machine, 12 fds per AsyncHttpClient). The first attempt to fix this was to call dispose() in sessionClosed() of HttpIoHandler, but this causes a deadlock. My first patch reverts that change. It would seem that there is no good way for AsyncHttpClient to close the NioSocketConnector, since closing it from an IoHandler event handling method called on an IoSession created through the connector leads to deadlock. Therefore I added dispose()-method to AsyncHttpClient (second patch), which can be used to dispose the client when the user of the client is done with it (care must be taken not to do this from the AsyncHttpClientCallback, since its methods are called from HttpIoHandler and will lead to the same deadlock that was mentioned). This is an ugly minimal workaround rather than a proper fix, but at least it makes it possible to use AsyncHttpClient while discussion about how to replace it is going on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ASYNCWEB-1) AsyncHttpClient does not dispose its NioSocketConnector
[ https://issues.apache.org/jira/browse/ASYNCWEB-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tuure Laurinolli updated ASYNCWEB-1: Attachment: add-dispose-method.patch Adds dispose() method to allow working around NioSocketConnector leak. AsyncHttpClient does not dispose its NioSocketConnector --- Key: ASYNCWEB-1 URL: https://issues.apache.org/jira/browse/ASYNCWEB-1 Project: Asyncweb Issue Type: Bug Reporter: Tuure Laurinolli Attachments: add-dispose-method.patch, fix-deadlock.patch As has been discussed on the MINA mailing list, NioSocketConnector does not dispose its NioSocketConnector when it isn't used anymore. This leads to significant resource leakage (on my Java 1.6 / Linux machine, 12 fds per AsyncHttpClient). The first attempt to fix this was to call dispose() in sessionClosed() of HttpIoHandler, but this causes a deadlock. My first patch reverts that change. It would seem that there is no good way for AsyncHttpClient to close the NioSocketConnector, since closing it from an IoHandler event handling method called on an IoSession created through the connector leads to deadlock. Therefore I added dispose()-method to AsyncHttpClient (second patch), which can be used to dispose the client when the user of the client is done with it (care must be taken not to do this from the AsyncHttpClientCallback, since its methods are called from HttpIoHandler and will lead to the same deadlock that was mentioned). This is an ugly minimal workaround rather than a proper fix, but at least it makes it possible to use AsyncHttpClient while discussion about how to replace it is going on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ASYNCWEB-1) AsyncHttpClient does not dispose its NioSocketConnector
AsyncHttpClient does not dispose its NioSocketConnector --- Key: ASYNCWEB-1 URL: https://issues.apache.org/jira/browse/ASYNCWEB-1 Project: Asyncweb Issue Type: Bug Reporter: Tuure Laurinolli As has been discussed on the MINA mailing list, NioSocketConnector does not dispose its NioSocketConnector when it isn't used anymore. This leads to significant resource leakage (on my Java 1.6 / Linux machine, 12 fds per AsyncHttpClient). The first attempt to fix this was to call dispose() in sessionClosed() of HttpIoHandler, but this causes a deadlock. My first patch reverts that change. It would seem that there is no good way for AsyncHttpClient to close the NioSocketConnector, since closing it from an IoHandler event handling method called on an IoSession created through the connector leads to deadlock. Therefore I added dispose()-method to AsyncHttpClient (second patch), which can be used to dispose the client when the user of the client is done with it (care must be taken not to do this from the AsyncHttpClientCallback, since its methods are called from HttpIoHandler and will lead to the same deadlock that was mentioned). This is an ugly minimal workaround rather than a proper fix, but at least it makes it possible to use AsyncHttpClient while discussion about how to replace it is going on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Configuring UDP application for performance
Mark wrote: The Configuring Thread Model page should also apply for UDP-based systems. Just make sure you are not using an ExecutorFilter and you can pass in an Executor that only uses one thread. Hi, Mark, I suppose I should have been more clear on the questions I still had after reading that page. 1. DatagramAcceptor doesn't take a max number of IO threads, unlike SocketAcceptor. 2. DatagramAcceptor takes an executor - I have never been able to find any mention in the docs on what exactly gets submitted to this executor (all I know is that it's not related to IO threads, which is parameterized by the above int) - but experimentally, I found I cannot pass in a single-threaded executor, since it seems that the call to bind() for all but the first DatagramAcceptor will block. And I did not add any filters. Thanks for answers. -- Yang Zhang http://www.mit.edu/~y_z/
Re: [AsyncHttpClient] On bringing the code bases and communities together
On Jan 29, 2008, at 7:28 PM, Mike Heath wrote: Alex Karasulu wrote: Hi, Please excuse the cross post but it's quite necessary. Furthermore people should not feel like they cannot cross post responses so please feel free. It looks like the two versions of the http client based on MINA are starting to diverge. I've noticed the other day that some of the fixes for bugs already solved by one group are being re-implement all over again over again by another. It's a shame to have that happen so perhaps we can take some concrete steps to prevent this divergence from progressing. As a first step I've cleaned up and restructured the Asyncweb code base and posted this email here on the new directory structure in Subversion: *http://tinyurl.com/ypmbd3 *So I'm sending out this cross post in the hopes of bringing the two groups together as one unified community which apparently has the same goal in mind: a fast low-resource consuming asynchronous http client. What ever it takes, I'm sure the MINA PMC is more than willing to accommodate. If you have trusted committers already working on this in the Geronimo community there is no reason why we cannot trust them to continue working on it here at MINA's Asyncweb project. Let's open up discussions on this. I totally agree with Alex on this. It looks there are fixes in the G branch that haven't made it to the MINA branch. How can bridge the gap in communication as well as the gap in bug fixing? My opinion is that we need to stop all work on the G sandbox branch and move all work over to MINA. Is there anything impeding that? ...besides a lot of work merging the changes... Thanks Alex and Mike. So, as we discussed the last time, the community members that have been active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. You already know Jeff. Have you reached out to Sangjin and Rick? I'd urge them both to become involved in the Mina community, as their time and interest permit. Personally, I'm certainly in favor of seeing a united effort in creating an async http client. Mina would seem to be a natural home for this support (since Mina 2.x is moving up the stack and implementing protocols). I think our community would be quite happy to receive this capability by consumng Mina technology. Given the current state of our two projects, I think it's somewhat doubtful that the Geronimo project will end up releasing the AsyncHTTPClient code in our sandbox. I can understand, however, if Rick and Sangjin see value in the current codebase -- being based on a released version of Mina (1.1.2) and perhaps at a different point in terms of stability and function. I suspect that this might be part of the reason why they haven't become involved in the 2.x development work occurring at Mina. So, one possible solution that occurs to me is to transfer the current 1.1.x code in Geronimo sandbox to the Mina project. This might allow Rick and Sangjin to complete their work on the current codebase and also ease their transition towards merging code and fixes into the Mina 2.x codebase. Alternatively, we can leave the code in Geronimo sandbox while Sangjin and Rick transition their focus to the Mina 2.x support. Will leave it to the Mina project, Rick, and Sangjin to say what makes the most sense. --kevan
Re: [AsyncHttpClient] On bringing the code bases and communities together
Kevan, Thanks for taking the time to respond. More inline ... On Jan 30, 2008 1:08 AM, Kevan Miller [EMAIL PROTECTED] wrote: ... So, as we discussed the last time, the community members that have been active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. You already know Jeff. Have you reached out to Sangjin and Rick? I'd urge them both to become involved in the Mina community, as their time and interest permit. Right very good point. So Sangjin and Rick are you interested in working on this with the rest of the asyncweb crew at MINA? I can understand, however, if Rick and Sangjin see value in the current codebase NP that's something to consider and evaluate. And regardless of the code in general we can share knowledge and expertise. I'm sure experiences will rub off and this is the most important part of it. The code here is small compared to the collaborative potential. So, one possible solution that occurs to me is to transfer the current 1.1.x code in Geronimo sandbox to the Mina project. This might allow Rick and Sangjin to complete their work on the current codebase and also ease their transition towards merging code and fixes into the Mina 2.xcodebase. Alternatively, we can leave the code in Geronimo sandbox while Sangjin and Rick transition their focus to the Mina 2.x support. Will leave it to the Mina project, Rick, and Sangjin to say what makes the most sense. I think all options are open for us. Thanks for your help towards fostering greater community. Alex
Re: [AsyncHttpClient] On bringing the code bases and communities together
On Jan 30, 2008 3:44 PM, Alex Karasulu [EMAIL PROTECTED] wrote: Kevan, Thanks for taking the time to respond. More inline ... On Jan 30, 2008 1:08 AM, Kevan Miller [EMAIL PROTECTED] wrote: ... So, as we discussed the last time, the community members that have been active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. You already know Jeff. Have you reached out to Sangjin and Rick? I'd urge them both to become involved in the Mina community, as their time and interest permit. Right very good point. So Sangjin and Rick are you interested in working on this with the rest of the asyncweb crew at MINA? In the previous mailing list communication, Sangjin showed his interest IIRC. Probably Rick is too? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: [Asyncweb] New confluence space requested.
BTW, does this mean that we should revive CWiki space for FtpServer? Niklas G already moved all pages to MINA space. I hope it's easy to move the pages back and set up subproject web sites. Trustin On Jan 30, 2008 5:18 AM, Alex Karasulu [EMAIL PROTECTED] wrote: Hey guys I might have missed a few people so please add your name to the JIRA issue as comments. I realized Jullien and Mike were not on there. Didn't know if you wanted to be. Alex On Jan 29, 2008 2:57 PM, Alex Karasulu [EMAIL PROTECTED] wrote: Just an FYI, https://issues.apache.org/jira/browse/INFRA-1502 Will notify when this space has been created. Thanks, Alex -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: [Asyncweb] New confluence space requested.
On Jan 30, 2008 2:10 AM, Trustin Lee [EMAIL PROTECTED] wrote: BTW, does this mean that we should revive CWiki space for FtpServer? Niklas G already moved all pages to MINA space. I hope it's easy to move the pages back and set up subproject web sites. We can sure if that's what they want to do. It might be best to keep separate spaces then refer to their generated static pages from the main site. I don't know the best approach here. Are we using the Confluence export plugin for MINA? Alex
Re: ExecutorFilter
Is that true? I used that all the time. Which means: If I use 2 io processor threads + an ExecutorFilter at the end of IoFilter which ends up with single thread to process the business logic? On Jan 29, 2008 1:35 AM, Martin Alderson [EMAIL PROTECTED] wrote: Hi all, I've just spent a while trying to figure out the threading behaviour of MINA in the ApacheDS replication service. Eventually I found that it was using ThreadModel and that this is now not recommended. After investigation into adding an ExecutorFilter to the end of the IoFilter chain I found that it was only using one thread even though I had specified a ThreadPoolExecutor. I see that MINA 2 has an UnorderedExecutorFilter which allows multiple threads to process the incoming messages simultaneously, but do we need to have an ExecutorFilter at all? Couldn't we just use a single threaded executor with the UnorderedExecutorFilter like Executors.newSingleThreadExecutor()? Personally I think we should just replace ExecutorFilter with UnorderedExecutorFilter. The current behaviour seems very misleading. If this can't be done then perhaps we could update the documentation (specifically http://mina.apache.org/configuring-thread-model.html) to make it clear that ExecutorFilter will not make use of a ThreadPoolExecutor? Please correct me if I'm wrong with any of this - this is the first time I've even seen the Executor class :) Thanks, Martin
