Re: Asynchronous Http Client donation
Simon Aquilina wrote: Hi, I am sorry if this reply is not exactly what you may be expecting back. I am sure around here there are many experts that will have many more interesting replies then this one. However could you please explain to me (and possible others) what Asynch[ronous] Http Client is, and what are its advantages? If I know exactly what it is then I can imagine ways on how to use it :) Sure...I would be happy to explain it. With the movement of web containers to NIO (Ex. Jetty, Tomcat, and AsyncWeb), they are able to handle a lot more throughput and simultaneous connections. For some web applications, the servlets may need to retrieve data from a third party web service or scrape 3rd party HTML to embed in a page, or need to grab content as a proxy, like images or ads or pdf from another server. In these sorts of scenarios, the NIO/Comet in the web server would normally have a thread that is blocking when using a blocking client API (like Commons HttpClient or Sun's HttpURLConnect) to retrieve this data. This could significantly throttle the throughput of the NIO containers. By having an Async Http Client API, the thread could be parked and put into use for something else while the original call is waiting for a connection or a response from the third party server. Jeff Thanks and Regards, Sim085 From: Jeff Genender [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: dev@mina.apache.org Subject: Asynchronous Http Client donation Date: Fri, 17 Aug 2007 20:19:07 -0600 Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/
Re: Asynchronous Http Client donation
Mark wrote: I will have some free time in the next week or so. I can take the lead on incorporating this into the baseline, if someone wants to give me a good recommendation as to where to place the code. My initial thought is to create a new top level project inside of the trunk. Maybe mina-asynch-httpclient ? +1 from a non-binding person ;-) Jeff On 8/17/07, Jeff Genender [EMAIL PROTECTED] wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff
Re: Asynchronous Http Client donation
Let me know when you have moved the code over so I can start submitting patches to it since I am developing against the Geronimo sandbox now. Thanks, Jeff Mark wrote: I created a mina-httpclient component on the trunk. Just working things out, along with an example and I will check things in. On 8/21/07, Mike Heath [EMAIL PROTECTED] wrote: This sounds awesome! I would like to see this as the client part of AsyncWeb for two reasons. First it seams to be a natural fit. Second it might give us a little more incentive to finally get AsycWeb moved over to MINA. -Mike Jeff Genender wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff
Re: Asynchronous Http Client donation
Mark, Have a look look at: src/test/java/org/apache/ahc/AsyncHttpClientTest.java The doConnection() is pretty much an example. Basically, you set up an implementation of the AHCCallback to notify you of a response, set up a HttpRequestMessage for your URI, and then make the call to ahc.connect() and ahc.sendRequest(request). However, I am probably going to get rid of the direct access to the HttpRequestMessage and have folks just set/get on the AsyncHttpClient object, which will act as a proxy to the HttpRequestMessage. This will simplify things. I will also probably get rid of the sendRequest() and have everything happen in the connect() method as a single async call - again to simplify its use. There are a few TODOs I am currently working on. 1) I am working on the HTTP/1.1 chunking (hopefully be done today). 2) Need to handle the HTTP/1.1 100 Continue (should be easy to do). 3) Auto-handle 301 Redirect. 4) Handle proxies. 5) A good timeout implementation. Not sure whether to use the sessionIdle() or use a concurrent timer. Since its a single request/response, sessionIdle() may work fine. 6) Possibly allow handling of streams for very large packets (right now it pulls the entire response into memory - which works for 99% of the use cases). But it would be nice to allow people to get their data moved in chunks. I probably need some input on implementing this efficiently...but I think this is the lowest priority item. 7) Finer grained control over the threading model. Basically allow people to tweak the thread pool or pass in their own to use. What currently works: A) HTTPS/SSL/HTTP submission and response B) Cookie handling C) Header handling D) Parameter handling (web parameters) E) All HTTP request types (GET, POST, etc) D) Text and Binary responses As for the donation's being up to Apache spec...I am already an Apache guy (CLA already on file) and it's coming from Apache into Apache ;-) AFICT I have all of the necessary headers are in the source - hopefully I haven't missed anything. We probably just need to rename the packages, etc, to something more meaningful/appropriate to Mina. Thanks, Jeff Mark wrote: will do. BTW, do you have any code that I could use in the mina-examples component? I have the code you wrote up to MINA 2.0 compliance, but I want to provide a sample program as well. Thanks, Mark On 8/21/07, Jeff Genender [EMAIL PROTECTED] wrote: Let me know when you have moved the code over so I can start submitting patches to it since I am developing against the Geronimo sandbox now. Thanks, Jeff Mark wrote: I created a mina-httpclient component on the trunk. Just working things out, along with an example and I will check things in. On 8/21/07, Mike Heath [EMAIL PROTECTED] wrote: This sounds awesome! I would like to see this as the client part of AsyncWeb for two reasons. First it seams to be a natural fit. Second it might give us a little more incentive to finally get AsycWeb moved over to MINA. -Mike Jeff Genender wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff
Re: Asynchronous Http Client donation
Mike, I would concur with you on this. I think a sub-project of its own is good since it can be used as a standalone API (with a dependency on Mina of course). I would recommend that this API be a separate artifact from asyncweb as I think we want the client to be capable of being slit off from the server (for obvious reasons). Jeff Mike Heath wrote: I'm wondering where this project should really go. Do we want to make it part of MINA (ie. put it in mina/trunk) or do we want to create a separate subproject that depends on MINA (ie. put it in something like mina/async-httpclient/trunk). I'm concerned about the agility of MINA if we start adding protocol handlers to MINA itself. What if we make a change to MINA that breaks one of our protocol handlers? What if there's a bug in a protocol handler that doesn't affect 99.9% of MINA's user base? Will these problems keep us from making releases? If we fix a major bug in MINA that doesn't affect async-httpclient, do we still release a new version of async-httpclient with MINA because async-httpclient is part of the baseline MINA build? I would rather see async-httpclient be a subproject of MINA and have it reside it's own directory in subversion with its own build and with its own examples separate from the MINA examples. That being said, I would MUCH rather see AsyncWeb finally moved over to MINA as a sub-project and then make async-httpclient part of AsyncWeb. There's certainly going to be a lot of overlap between the two. We should leverage that. -Mike Mark wrote: I created a mina-httpclient component on the trunk. Just working things out, along with an example and I will check things in. On 8/21/07, Mike Heath [EMAIL PROTECTED] wrote: This sounds awesome! I would like to see this as the client part of AsyncWeb for two reasons. First it seams to be a natural fit. Second it might give us a little more incentive to finally get AsycWeb moved over to MINA. -Mike Jeff Genender wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff
Re: Asynchronous Http Client donation
Agreed...if we can split the artifacts, then that is fine with me. Jeff Mike Heath wrote: Jeff Genender wrote: I would concur with you on this. I think a sub-project of its own is good since it can be used as a standalone API (with a dependency on Mina of course). I would recommend that this API be a separate artifact from asyncweb as I think we want the client to be capable of being slit off from the server (for obvious reasons). Certainly if you want an HTTP client, it's unlikely that you would want an HTTP server. This, of course, makes sense. I would imagine, however, that there are going to be a lot of similarities between the client and server code (header parsing, cookies support, the many caching options of HTTP/1.1, etc.). That's why I was thinking making it part of AsyncWeb would be a good idea. I don't think the client and server should be distributed in the same artifact either. However, I believe there's a lot to be gained by keeping the the HTTP client and server close together. WDYT? -Mike
Re: Asynchronous Http Client donation
Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike
Re: Asynchronous Http Client donation
Kevin Smeltzer wrote: Is this a project for doing transfer through HTTP using Mina? If so it could be very valuable (to me anyways) :-D Yep ;-) On 8/27/07, Mark [EMAIL PROTECTED] wrote: I have been moving things around, creating the 3 separate subprojects. Everything is compiling and seems to be in good shape. I posted a question to the list a couple days ago about javadocs at the class level and have not heard back. Maybe your email and mine will bump this thread and someone can answer my question. Either way, I will check in what I have tonight. I'm on EST -- ..Cheers Mark On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Any status on where we are at with this? I have patches I want to start delivering ;-) Jeff Mike Heath wrote: I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike -- ..Cheers Mark
Re: Can someone provide http client example
Hi Ted, Yep...the error is a bug on how he handle the Host header. I opened a JIRA and attached a patch to fix it. https://issues.apache.org/jira/browse/DIRMINA-433 Thanks, Jeff tedc wrote: Hi Jeff: Thanks for your help. Now I can send the http request to server, but I recevie the request error from yahoo. And how can I send the query string to Google. Thanks for your help. Ted jgenender wrote: Hi Ted, A good example of how to use it is in AsyncHttpClientTest.java. The code still needs a bit of work and will undergo a few changes as it still has some functionality needed, but here is the gist of how to use it. You need to create an implementation of the AsyncHttpClientCallback. This is where you get notified of your response. In particular, you will be most interested in the onResponse() call. You then create a connection, let say you are going to yahoo... MyCallBack callback = new MyCallBack(); // This is your Callback impl AsyncHttpClient ahc = new AsyncHttpClient( http://www.yahoo.com;, callback ); ahc.connect(); Once you have made the connection, you need to set up your request for the URI. You can set request parameters, cookies, declare the method type, etc (look at the HttpRequestMessage.java for all the cool stuff you can do with it). But keeping it simple..: HttpRequestMessage request = new HttpRequestMessage(/index.html); Then you send the request: ahc.sendRequest( request ); When you receive a response, your callback should contain a HttpResponseMessage in the OnResponse(). Let me know if that helped. Jeff tedc wrote: Dear all : I had seen someone have http client program of mina, but have some can give a example like http server. I will try to see jgenender program, and don't know how to use it. anyone can give me some advice Thanks Ted Chen
Re: New name for ByteBuffer?
+1...renaming it would be good. When I explain it...I have to be very careful in saying I mean Mina's ByteBuffer..not a regular ByteBuffer Jeff Trustin Lee wrote: Hi folks, It is often confusing to discriminate MINA ByteBuffer and NIO ByteBuffer. Do we need renaming? I didn't have much difficulties actually because most Java code doesn't use both types at the same time. There was an opinion about renaming it to MinaByteBuffer, but I don't think it's the best name available for us. I think DataBuffer, ExtendedByteBuffer, ExtendedBuffer or just Buffer might also be a candidate. There's Buffer in NIO, too, but nobody uses that class directly. I'd like to find the best name; short and not confusing one. Please don't hesitate to respond to this message with your idea so we can find out the best alternative. Trustin
Test failures on trunk?
I noticed the following today: Failed tests: testSuspendResumeReadWrite(org.apache.mina.transport.socket.nio.DatagramTrafficControlTest) Does anyone know when that may get fixed? Thanks, Jeff
Re: How can I close the Client SocketConnector?
I have 2 patches awaiting to get applied to the 1.1 branch and 2,x that allows you to close the SocketConnector. Could someone please apply them? DIRMINA-441 DIRMINA-443 Thanks, Jeff kanful wrote: I can't close the Client SocketConnector? so I use normal socket to devlop client
Re: [jira] Commented: (DIRMINA-443) SocketConnection cannot be manually closed (for v2.X)
Can you apply DIRMINA-441 to the 1.1 branch? Thanks, Jeff Maarten Bosteels (JIRA) wrote: [ https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529425 ] Maarten Bosteels commented on DIRMINA-443: -- Thanks for the patch. I applied it to the trunk. Should we also apply this to SerialConnector, DatagramConnector and VmPipeConnector ? SocketConnection cannot be manually closed (for v2.X) - Key: DIRMINA-443 URL: https://issues.apache.org/jira/browse/DIRMINA-443 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M1 Reporter: Jeff Genender Assignee: Maarten Bosteels Fix For: 2.0.0-M1 Attachments: DIRMINA-443-jgenender.patch The SocketConnection cannot be closed. Currently it will wait a certain amount of timeout as specified by the worker timeout to shut down the connection. This can result in OOM and hanging clients until the timeouts occur. Mina should allow the SocketConnection to be closed manually if the connection is known to be completed.
Re: [jira] Commented: (DIRMINA-443) SocketConnection cannot be manually closed (for v2.X)
Maarten Bosteels wrote: Jeff, The 1.1 API is frozen. IMHO this is a new feature not a bug, so I think we shouldn't apply it to the 1.1 branch. I think I would certainly call it a bug since the client seems to hang under certain conditions in 1.1.2. There are several recent emails complaining about this, so it does seem to be an important issue. Since 2.X is in a state of flux and won't be released for a while yet, is there any chance a 1.1.3 can be made available and this patch as a part of it? Also if 1.1 is frozen, can we get a comment on the main web page stating that? It would be great to know the status. If its somewhere else, then I may have missed it ;-) Jeff regards, Maarten On 9/21/07, Jeff Genender [EMAIL PROTECTED] wrote: Can you apply DIRMINA-441 to the 1.1 branch? Thanks, Jeff Maarten Bosteels (JIRA) wrote: [ https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529425 ] Maarten Bosteels commented on DIRMINA-443: -- Thanks for the patch. I applied it to the trunk. Should we also apply this to SerialConnector, DatagramConnector and VmPipeConnector ? SocketConnection cannot be manually closed (for v2.X) - Key: DIRMINA-443 URL: https://issues.apache.org/jira/browse/DIRMINA-443 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M1 Reporter: Jeff Genender Assignee: Maarten Bosteels Fix For: 2.0.0-M1 Attachments: DIRMINA-443-jgenender.patch The SocketConnection cannot be closed. Currently it will wait a certain amount of timeout as specified by the worker timeout to shut down the connection. This can result in OOM and hanging clients until the timeouts occur. Mina should allow the SocketConnection to be closed manually if the connection is known to be completed.
Re: How can I close the Client SocketConnector?
https://issues.apache.org/jira/browse/DIRMINA-441 DIRMINA-443 was already applied. A work around to closing the client connection is to shutdown your Executor if you used that, and then do a connector.setWorkerTimeout(0). Jeff kanful wrote: where I can get it? give me the url please! thanks jgenender wrote: I have 2 patches awaiting to get applied to the 1.1 branch and 2,x that allows you to close the SocketConnector. Could someone please apply them? DIRMINA-441 DIRMINA-443 Thanks, Jeff kanful wrote: I can't close the Client SocketConnector? so I use normal socket to devlop client
Re: ASyncWeb v/s Tomcat 5.5.20 Performance issues
A few considerations for you... Be sure to tweak your TCP IP parameters or you will hit a wall very quickly with AsyncWeb. You need to significantly up your socket queue lengths and significantly decrease your TCP time wait. Otherwise you will fill your IP queue and your server will probably appear to hang for a while waiting for the TIME_WAIT and SYN_RECV to clear. There are probably several changes you need to tweak your IP stack. Google on tuning IP parameters for your OS and you should find lots of articles on how to. Also be sure you have a large enough acceptCount size to be sure it will handle the load, or you will get rejected connections. I would tweak the acceptCount to equal your maximum concurrent connections. Also...something else to keep in mind...AsyncWeb is really going to shine in concurrent connections, not necessarily transactions per second. This means it could handle a lot more load than a single threaded connector on Tomcat could. Thus speed is not necessarily a good way to measure scalability. Jeff Deepak J wrote: Perhaps not the right forum to post these results. But just wanted your opinion on the tests. S/W versions: Tomcat 5.5.20 ASyncWeb 0.8.2 JRE 1.5.0._06 Test Methodology: A multi thread client constructs HTTP/POST messages (headers + content). The size of each message is ~160KB. The client can be pointed either at Tomcat or at ASyncWeb server. The number of client threads and iterations per thread is configurable. Thus a config of thread=10 iterations=1000 will result in 1 HTTP/POST. Keep-Alive functionality is not being tested hence after each HTTP connection there is a call to disconnect(). A static counter is incremented after a 200 OK. After all client threads complete execution a result is printed indicating total time taken for the test, number of 200 OK received total connections/sec The server code, which resides in the Tomcat Servlet and ASyncWeb stand-alone app is identical in functionality in both places. When a request is received the Content-Length header is fetched. Data from the InputStream is read in a while loop and writtern in byte chunks of size 1024 to a byte array output stream. Once the stream has been read, the size of the byte array is compared with the content-length and a log is printed if they don't match. On successful completion a 200 OK is returned. Test Results: NoThreads Iterations Tomcat 5.5.20 ASyncWeb 0.8.2 - 1 10 1000 Test duration = 138626 millis Test duration = 901996 millis Total Connections = 9995 Total Connections = 1 Connections/Sec = 72 Connections/Sec = 11 2 1002 Test duration = 2878 millis Test duration = 20892 millis Total Connections = 200 Total Connections = 200 Connections/Sec = 69 Connections/Sec = 9 3 500 10Test duration = 41796 millis OutOfMemory in Server Total Connections = 5000 Connections/Sec = 119 - Now I am wondering if there are tweeks needed to get better number. Should AsyncWeb not perform better that Tomcat's One-Thread-Per-Connection model?
Re: HTTP Client using MINA
It appears HTTPClient is not NIO based, so the Mina alternative should perform better. However, there is the Apache httpcomponents-core that is a part of the http components project that does appear to be NIO based, although I don't know much about it's performance. Jeff Michael Grundvig wrote: I second that HTTPClient from Apache Commons is superb. It would be even better if it was written with MINA though and didn't use the Commons Logging absurdity. Mike - Original Message - From: hezjing [EMAIL PROTECTED] To: dev@mina.apache.org Sent: Friday, September 21, 2007 6:45 AM Subject: Re: HTTP Client using MINA Hi Siddarth Another alternative you may want look at, is HttpClient (see http://jakarta.apache.org/httpcomponents/httpclient-3.x/). On 9/21/07, Siddarth [EMAIL PROTECTED] wrote: I want to simulate an HTTP GET request , i want to write a Client programs which talks to few websites and does an http Get help appriciated -- View this message in context: http://www.nabble.com/HTTP-Client-using-MINA-tf4493177s16868.html#a12814517 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com. -- Hez
Re: Asynchronous timeout/sleep/delay/etc.
How is the ScheduledExecutorService a blocking mechanism? Jeff yz wrote: I just started playing around with Mina, and I tried searching the archives for a discussion about this, but I noticed a glaring lack of any asynchronous scheduling of callbacks. I.e., we can't schedule a timeout/sleep/delay within this framework. Is this accurate? Is there some reason why this relatively straightforward and standard feature is not available in this framework? As a workaround, it seems that we must resort to synchronous, blocking timeout mechanisms (e.g. ScheduledExecutorService). Is the general approach here to simply save the IoSession (while inside one of the IoHandler callbacks) and use it (a) from other threads (b) at any time in the future? If this is the case, meaning the IoSession never changes across the IoHandler callbacks, then why is IoSession continually passed back into those callbacks? IoSession says it's thread-safe (I assume this implies the thread-safety of the reactor core as well) but the Filters may not be. How do I tell if a particular filter is thread-safe? In particular, I'm interested in LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but for these there's no mention in the docs regarding their thread-safety. Thanks in advance for your answers.
Re: Asynchronous timeout/sleep/delay/etc.
yz wrote: It requires another thread. It requires a thread that is dedicated to managing scheduling as a daemon, but it certainly is not blocking anything else. I believe this is probably one of the components that is best suited for scheduling a timeout as it scales incredibly well. I have written some that handle 1000s of concurrent connections and have no issues at all. When you send a message, you would create a Future task via the SchedulerExecutorService in your messageSent(), with an ioSession as a member of the Future task. This requires nearly no overhead and has absolutely no blocking associated with it. If you receive a response w/in the allotted time, you cancel the timeout. If not, your task fires, and you can close the connection or do other actions. If you expect many many connections, you can use a thread pool to handle the firing of the tasks. If using a scheduler is not working for you, then you could make use of the session idler, but then you still are using an internal thread that is monitoring the idling time (which happens anyways), as a daemon. You are not going to get around something that polls something else, its the nature of the IO beast in just about any programming language. In any case, I do not see any reason why a ScheduledExecutorService is a bad thing. Jeff jgenender wrote: How is the ScheduledExecutorService a blocking mechanism? Jeff yz wrote: I just started playing around with Mina, and I tried searching the archives for a discussion about this, but I noticed a glaring lack of any asynchronous scheduling of callbacks. I.e., we can't schedule a timeout/sleep/delay within this framework. Is this accurate? Is there some reason why this relatively straightforward and standard feature is not available in this framework? As a workaround, it seems that we must resort to synchronous, blocking timeout mechanisms (e.g. ScheduledExecutorService). Is the general approach here to simply save the IoSession (while inside one of the IoHandler callbacks) and use it (a) from other threads (b) at any time in the future? If this is the case, meaning the IoSession never changes across the IoHandler callbacks, then why is IoSession continually passed back into those callbacks? IoSession says it's thread-safe (I assume this implies the thread-safety of the reactor core as well) but the Filters may not be. How do I tell if a particular filter is thread-safe? In particular, I'm interested in LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but for these there's no mention in the docs regarding their thread-safety. Thanks in advance for your answers.
Re: [VOTE] Import AsyncWeb from Safehaus to MINA
non-binding +1 Jeff Trustin Lee wrote: Hi, There has been enormous amount of requests about importing AsyncWeb under MINA PMC. I must admit that I was too lazy to deal with legal issues even after the proper software grant for AsyncWeb has been received. Now, I'd like to fire the vote for importing AsyncWeb under Apache MINA PMC. AsyncWeb is currently located at: * https://svn.safehaus.org/repos/asyncweb/trunk/ If the vote passes, I will fill out the incubation paperwork at: * http://incubator.apache.org/ip-clearance/index.html And we would then import AsyncWeb under our sandbox at: * https://svn.apache.org/repos/asf/mina/sandbox/asyncweb [ ]: +1, import [ ]: 0, abstain [ ]: -1, don't import Cheers, Trustin Lee
Re: poll: which logging framework are you using
[X] slf4j-simple Maarten Bosteels wrote: It would be interesting to know which logging framework your MINA applications are using. [ ] log4j [ ] logback [ ] java.util.logging [ ] slf4j-simple [ ] slf4j-nop [ ] x4juli [ ] other (please specify) Please, check all that apply. Thanks, Maarten
Re: MINA TCP/IP server clustering
I wrote an implementation of GCache (Geronimo Cache) that is in the Geronimo sandbox. Its a clustering implementation based on Mina. Its nto complete yet, but it gives you an idea. It is not JVM level, since it API based. If you are looking for an open source impl for a JVM based clustering container, have a look at Terracotta. Jeff Kumaran Arul wrote: Hi Has anyone got any experience with clustering MINA servers at a JVM level? How can we replicate IoSessions? Would Terracotta be a good choice? Any lead or tips will be greatly appreciated? Regards Arul *** CAUTION: This email and files included in its transmission are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us immediately and delete it without copying the contents contained within. Woolworths Limited (including its group of companies) do not accept liability for the views expressed within or the consequences of any computer viruses that may be transmitted with this email. The contents are also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner. ***
Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents
Trustin Lee wrote: 2) I also think mina-protocol-http-client module needs more work to provide enough features to compare with existing HTTP client libraries such as Jakarta HttpComponents, so moving it into sandbox might be a better solution considering that we are going to release MINA 2.0.0-M1 soon and we don't want to release unfinished module. It also might be the best idea to cooperate with HttpComponents team to make our current HTTP codec (i.e. mina-filter-codec-http) and mina-core plug into HttpComponents NIO extension very easily. I'd like to know what the HttpComponents team think about this issue. Trustin, I have a lot more code to contribute in this area as it is currently here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient This version contains authentication for Basic, Digest, and NTLM and is much more robust. I am currently working on connection reuse and caching and pooling for those HTTP/1.1 connections that support keep-alives. I am also working on allowing the NIO socket level attributes to be set as well as client SSL certificate authentication and Proxy Auth capabilities. Jeff Trustin
Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents
Whoops and forgot to mention...this version also has response timeouts working as well. Jeff Jeff Genender wrote: Trustin Lee wrote: 2) I also think mina-protocol-http-client module needs more work to provide enough features to compare with existing HTTP client libraries such as Jakarta HttpComponents, so moving it into sandbox might be a better solution considering that we are going to release MINA 2.0.0-M1 soon and we don't want to release unfinished module. It also might be the best idea to cooperate with HttpComponents team to make our current HTTP codec (i.e. mina-filter-codec-http) and mina-core plug into HttpComponents NIO extension very easily. I'd like to know what the HttpComponents team think about this issue. Trustin, I have a lot more code to contribute in this area as it is currently here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient This version contains authentication for Basic, Digest, and NTLM and is much more robust. I am currently working on connection reuse and caching and pooling for those HTTP/1.1 connections that support keep-alives. I am also working on allowing the NIO socket level attributes to be set as well as client SSL certificate authentication and Proxy Auth capabilities. Jeff Trustin
Re: AsyncHttpClient with no content-length header
Yes, please open a JIRA on this. According to the HTTP spec, anything with content should have a content line. However, there does appear to be a site that is not compliant (http://www.toptable.co.uk/) and probably more... thus we could fall back to reading until there is no more data. However, this concerns me as a possible buffer/memory problem (it would then be easy to crash a Mina client). Anyone have an opinion on this? Jeff Vishal_Jain wrote: Is there a JIRA id for this issue ? or any workarounds ? vishal berdim99 wrote: Hi. It seems that AsyncHttpClient fails to decode a web page in which the web-server doesn't send a content-length header. What happens is that the callback is called with a null content, after which the decoder throws an exception because it thinks that the rest of the incoming data are of a new HTTP response (but they are actually the previous response content). (Such web site is http://www.toptable.co.uk/). Any help is appreciated. Micha.
Re: [New Committer] Everyone let's give a warm welcome to Jeff Genender
Thank you and I am honored. ;-) I am a big fan of Mina and have been for quite a while and am excited to step up and help out. About me...I am a Apache junkie of sorts as I am a committer on Geronimo, OpenEJB, ServiceMix, and CXF. more or less a Java dude (Ill bet ya couldn't tell). Thanks again! Jeff Alex Karasulu wrote: Hi all, We have a new committer, Jeff Genender, who's a committer other projects here at the ASF and a member of the foundation as well. He's great guy and has been working on some of the http client code and is pretty excited about MINA ... let me stop putting words in his mouth though. Jeff go ahead and tell us about yourself if you have a minute. Welcome! Alex
AbstractIoSession and final qualifiers
Hey guys, I was hoping to see if we could discuss some of the final qualifiers on some of the methods in the AbstractIOSession. The reason I ask is it would be cool to be able to override some of the methods such as: public WriteFuture write(Object message) public final int getScheduledWriteMessages() To be able to write MockObjects for unit tests of code. Any thoughts on making these protected instead of final? Thanks, Jeff
Re: AbstractIoSession and final qualifiers
I like it (the assert) ;-)
But I am not sure about having a completely different
AbstractIOMockSession since we would then be copying code to a certain
degree. I think it would just be cleaner to have the methods protected
so there is no need for code duplication ;-)
What do *you* think? ;-)
Jeff
Emmanuel Lecharny wrote:
Jeff Genender wrote:
Hey guys,
I was hoping to see if we could discuss some of the final qualifiers
on some of the methods in the AbstractIOSession. The reason I ask is it
would be cool to be able to override some of the methods such as:
public WriteFuture write(Object message)
public final int getScheduledWriteMessages()
To be able to write MockObjects for unit tests of code. Any thoughts on
making these protected instead of final?
Thanks,
Jeff
Hi,
makes sense to me... Or we may have a AbstractMockIoSession implementing
the IoSession interface, for unit tests ?
While looking at the abstract class, I found some methods with this kind
of code :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
if (message == null) {
throw new NullPointerException(message);
}
...
Wouldn't be a perfect case for an assert ? Like :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
assert message != null : Null messages are not allowed;
...
wdyt ?
Re: AbstractIoSession and final qualifiers
I agree...this makes sense...Filter is the way to go.
Jeff
Trustin Lee wrote:
Alternatively, we could add a protected method in AbstractIoSession
and make write() method to call it before returning. However, it is
essentially the same with adding an IoFilter IMHO.
The implementation of IoSession and IoFilterChain is not so trivial so
creating another mock object is a kind of huge task so we will finally
have a lot of duplicated code there, so I think it is somewhat
difficult to create a separate mock object; I already tried to do that
and gave up. :)
Trustin
On Dec 27, 2007 10:48 AM, Trustin Lee [EMAIL PROTECTED] wrote:
Hi Jeff and Emmanuel,
You can add some hook for IoSession.write() by inserting an IoFilter,
so I am not sure about removing the final modifier from write().
Overriding getScheduledMessages and getScheduledBytes makes sense
though because they will always be 0 because messageSent event will be
always fired immediately.
WDYT?
Trustin
On Dec 27, 2007 10:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
Jeff Genender wrote:
What do *you* think? ;-)
Beside the assert, which was a side effect of my quick glance at the
method you want to override, I think that dooming the final is sane.
If someone needs to protect this method, then the best solution would be
to define a super class with final methods calling the AbstractIoSession
non final methods.
Another solution (puke) would be to remove the
public/protected/private qualifier, and to add a MockIoSession in the
same package. Not very elegant, but does the job too...
There are always tradeoff when you want to thoroughly unit-test some
code. When it comes to an API, it seems impossible to avoid those
tradeoff, IMHO.
Any other opinion ? Trustin ? Julien ?
Jeff
Emmanuel Lecharny wrote:
Jeff Genender wrote:
Hey guys,
I was hoping to see if we could discuss some of the final qualifiers
on some of the methods in the AbstractIOSession. The reason I ask is it
would be cool to be able to override some of the methods such as:
public WriteFuture write(Object message)
public final int getScheduledWriteMessages()
To be able to write MockObjects for unit tests of code. Any thoughts on
making these protected instead of final?
Thanks,
Jeff
Hi,
makes sense to me... Or we may have a AbstractMockIoSession implementing
the IoSession interface, for unit tests ?
While looking at the abstract class, I found some methods with this kind
of code :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
if (message == null) {
throw new NullPointerException(message);
}
...
Wouldn't be a perfect case for an assert ? Like :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
assert message != null : Null messages are not allowed;
...
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: AbstractIoSession and final qualifiers
Trustin (and others)...so how about these changes and additions to the
AbstractIoSession? This will allow the scheduledBytes/messages to be
overriden, and also allow someone to set them.
Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(working copy)
@@ -488,14 +488,22 @@
lastThroughputCalculationTime = currentTime;
}
-public final long getScheduledWriteBytes() {
+public long getScheduledWriteBytes() {
return scheduledWriteBytes.get();
}
-public final int getScheduledWriteMessages() {
+public int getScheduledWriteMessages() {
return scheduledWriteMessages.get();
}
+public void setScheduledWriteBytes(long byteCount){
+scheduledWriteBytes.set(byteCount);
+}
+
+public void setScheduledWriteMessages(int messages) {
+scheduledWriteMessages.set(messages);
+}
+
protected final void increaseReadBytes(long increment, long
currentTime) {
if (increment = 0) {
return;
Thanks,
Jeff
Trustin Lee wrote:
Hi Jeff and Emmanuel,
You can add some hook for IoSession.write() by inserting an IoFilter,
so I am not sure about removing the final modifier from write().
Overriding getScheduledMessages and getScheduledBytes makes sense
though because they will always be 0 because messageSent event will be
always fired immediately.
WDYT?
Trustin
On Dec 27, 2007 10:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
Jeff Genender wrote:
What do *you* think? ;-)
Beside the assert, which was a side effect of my quick glance at the
method you want to override, I think that dooming the final is sane.
If someone needs to protect this method, then the best solution would be
to define a super class with final methods calling the AbstractIoSession
non final methods.
Another solution (puke) would be to remove the
public/protected/private qualifier, and to add a MockIoSession in the
same package. Not very elegant, but does the job too...
There are always tradeoff when you want to thoroughly unit-test some
code. When it comes to an API, it seems impossible to avoid those
tradeoff, IMHO.
Any other opinion ? Trustin ? Julien ?
Jeff
Emmanuel Lecharny wrote:
Jeff Genender wrote:
Hey guys,
I was hoping to see if we could discuss some of the final qualifiers
on some of the methods in the AbstractIOSession. The reason I ask is it
would be cool to be able to override some of the methods such as:
public WriteFuture write(Object message)
public final int getScheduledWriteMessages()
To be able to write MockObjects for unit tests of code. Any thoughts on
making these protected instead of final?
Thanks,
Jeff
Hi,
makes sense to me... Or we may have a AbstractMockIoSession implementing
the IoSession interface, for unit tests ?
While looking at the abstract class, I found some methods with this kind
of code :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
if (message == null) {
throw new NullPointerException(message);
}
...
Wouldn't be a perfect case for an assert ? Like :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
assert message != null : Null messages are not allowed;
...
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: AbstractIoSession and final qualifiers
Yep...agreed...how is this?
Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(working copy)
@@ -496,6 +496,14 @@
return scheduledWriteMessages.get();
}
+protected void setScheduledWriteBytes(long byteCount){
+scheduledWriteBytes.set(byteCount);
+}
+
+protected void setScheduledWriteMessages(int messages) {
+scheduledWriteMessages.set(messages);
+}
+
protected final void increaseReadBytes(long increment, long
currentTime) {
if (increment = 0) {
return;
Trustin Lee wrote:
Hi Jeff,
Do we need to remove the final modifier if we are going to provide
setters? And assuming you are using DummySession as a mock object,
I'd suggest making AbstractIoSession.setScheduled...(...) protected
and make them public in DummySession. WDYT?
Cheers,
Trustin
On Dec 28, 2007 8:19 AM, Jeff Genender [EMAIL PROTECTED] wrote:
Trustin (and others)...so how about these changes and additions to the
AbstractIoSession? This will allow the scheduledBytes/messages to be
overriden, and also allow someone to set them.
Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(working copy)
@@ -488,14 +488,22 @@
lastThroughputCalculationTime = currentTime;
}
-public final long getScheduledWriteBytes() {
+public long getScheduledWriteBytes() {
return scheduledWriteBytes.get();
}
-public final int getScheduledWriteMessages() {
+public int getScheduledWriteMessages() {
return scheduledWriteMessages.get();
}
+public void setScheduledWriteBytes(long byteCount){
+scheduledWriteBytes.set(byteCount);
+}
+
+public void setScheduledWriteMessages(int messages) {
+scheduledWriteMessages.set(messages);
+}
+
protected final void increaseReadBytes(long increment, long
currentTime) {
if (increment = 0) {
return;
Thanks,
Jeff
Trustin Lee wrote:
Hi Jeff and Emmanuel,
You can add some hook for IoSession.write() by inserting an IoFilter,
so I am not sure about removing the final modifier from write().
Overriding getScheduledMessages and getScheduledBytes makes sense
though because they will always be 0 because messageSent event will be
always fired immediately.
WDYT?
Trustin
On Dec 27, 2007 10:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
Jeff Genender wrote:
What do *you* think? ;-)
Beside the assert, which was a side effect of my quick glance at the
method you want to override, I think that dooming the final is sane.
If someone needs to protect this method, then the best solution would be
to define a super class with final methods calling the AbstractIoSession
non final methods.
Another solution (puke) would be to remove the
public/protected/private qualifier, and to add a MockIoSession in the
same package. Not very elegant, but does the job too...
There are always tradeoff when you want to thoroughly unit-test some
code. When it comes to an API, it seems impossible to avoid those
tradeoff, IMHO.
Any other opinion ? Trustin ? Julien ?
Jeff
Emmanuel Lecharny wrote:
Jeff Genender wrote:
Hey guys,
I was hoping to see if we could discuss some of the final qualifiers
on some of the methods in the AbstractIOSession. The reason I ask is it
would be cool to be able to override some of the methods such as:
public WriteFuture write(Object message)
public final int getScheduledWriteMessages()
To be able to write MockObjects for unit tests of code. Any thoughts on
making these protected instead of final?
Thanks,
Jeff
Hi,
makes sense to me... Or we may have a AbstractMockIoSession implementing
the IoSession interface, for unit tests ?
While looking at the abstract class, I found some methods with this kind
of code :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
if (message == null) {
throw new NullPointerException(message);
}
...
Wouldn't be a perfect case for an assert ? Like :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
assert message != null : Null messages are not allowed;
...
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Question regards AsyncWeb
James, I believe it is here: https://svn.apache.org/repos/asf/mina/sandbox/asyncweb/ Jeff James Apfel wrote: Hi all, where's the current AsyncWeb code being hosted that compiles with MINA trunk? It be also awesome if somebody could give me some hints regards AsyncWeb and MINA 1.1.x. The latest release that's offered on safehaus.org seems to be built for older versions of MINA? Thanks James
Re: Happy new year !
Emmanuel Lecharny wrote: Hi Ladies and Gentlemen, I wish you an Happy New Year ! I hope that 2008 will be way better than 2007, with less wars, less bugs and less cholesterol :) Hmmm...with you being from France...that cholesterol thing may be a tough one ;-) Happy new year to you guys too and am glad to be helping out. Jeff
Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox
Trustin Lee wrote: AsyncWeb and Jeff's AsyncHttpClient are different projects. Anyways, Jeff is free to modify the trunk, which already contains AsyncHttpClient, whenever he wants. He made some big changes in Geronimo sandbox before I made some big changes in his original contribution, and that's why it's taking some time. So.. Jeff will migrate the code to the trunk eventually I guess. Yes I will ;-) I am swamped at the moment...but I will ;-) Jeff IMHO, AsyncWeb itself, being David (Irving) the original contributor of the project, needs more work and more contributor(s) to become a part of the trunk because David seems to be too busy to follow up the subproject for now unfortunately. Where are you David? We miss you so much! :) Trustin On Jan 10, 2008 6:16 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I think Jeff started working on some of it over at MINA btw. Excuse the cross post. Alex On Jan 9, 2008 4:10 PM, Matt Hogstrom [EMAIL PROTECTED] wrote: If it is better and easier than http-client are they interested in it? Seems like a logical fit. That said, I think Genender boy wanted to melt some metal when he started this work. If it remains without a home I'd put it in components and let folks pick it up if they are interested. On Jan 9, 2008, at 9:55 AM, Kevan Miller wrote: On Jan 8, 2008, at 9:59 AM, Donald Woods wrote: #3 is okay with me. Was just thinking that #2 (plugin) would allow us to expose it on our plugin website and allow other users to just place a dependency on it in their plugins Oops. Got distracted and forgot to reply... I was thinking that AHC functionality could be released under components (and thus easier to consume by other projects). We can then create a plugin which includes this component. So, really a combination of 2 and 3. --kevan -Donald Kevan Miller wrote: On Jan 5, 2008, at 2:45 PM, Donald Woods wrote: There has been a lot of ongoing work by Jeff, Prasad, Rick, Sangjin and others on the AsyncHttpClient (aka. AHC) code in the sandbox and I'd like to start the discussion on moving it from sandbox into trunk. There are a couple options as to where it could reside - 1) under server/trunk/applications 2) under server/trunk/plugins 3) under geronimo/components/ What are everyone's thoughts? I'd like to get this into our 2.1 release and possibly into the 2.0.x branch if time allows. Personally, I don't think it should go into server/trunk. There's a 4'th option -- create a subproject (e.g. geronimo/ahc). The only real difference, between this and 3) is web site, jira, etc. At the moment, I'm leaning towards 3) -- geronimo/components/ahc (or some more descriptive name), but could probably be swayed... --kevan
Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox
Ugg...yeah...we need to get that team looking at our stuff. The problem is that the large delta is where the problem is going to be. I would like to see the delta be made and brought over here and have them work over here. Jeff Emmanuel Lecharny wrote: Hey, Alex just posted some X-post information to MINA and Geronimo, just to inform MINA that Geronimo want to get Jeff's work out from Sandbox. What are all the next mails about ? I see mentions of a kind of roadmap for geronimo, and some other informations about asynchweb which is totally a different beast... I think some context has been added, and not through mails... Any heads up ? Trustin Lee wrote: What's important is actually not where to host it or whether to fork or not - Jeff, the main contributor of the project, and the MINA team already decided to host it under the MINA trunk and Jeff wants to keep working on here with AHC. So I think Jeff will take care of the Geronimo discussion properly. I also think it's OK even if they do whatever they want to do with G sandbox as long as Jeff will keep working here, which is much more reasonable than hosting it under HttpComponent project or Geronimo trunk. Jeff should explain this to the Geronimo team and I believe he already did very enough as a person who wants to host it here. Trustin On Jan 10, 2008 8:27 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I think you missed it again. See here: On Jan 9, 2008 4:10 PM, Matt Hogstrom [EMAIL PROTECTED] wrote: If it is better and easier than http-client are they interested in it? Seems like a logical fit. That said, I think Genender boy wanted to melt some metal when he started this work. If it remains without a home I'd put it in components and let folks pick it up if they are interested. They don't want to fork it at Geronimo but would prefer it to find a home that is more fitting. http-client was mentioned. Alex On Jan 9, 2008 6:16 PM, Trustin Lee [EMAIL PROTECTED] wrote: Well, I think it's OK for the Geronimo team to fork AHC, and I'd like to respect them if Jeff already gave the information that his AHC work will be placed under MINA trunk. They have their release schedule and I don't want to let them wait for us. They will need to migrate to the official MINA AHC eventually though. Jeff could show us better road map for this. Trustin On Jan 10, 2008 7:55 AM, Alex Karasulu [EMAIL PROTECTED] wrote: On Jan 9, 2008 4:57 PM, Trustin Lee [EMAIL PROTECTED] wrote: AsyncWeb and Jeff's AsyncHttpClient are different projects. Anyways, Jeff is free to modify the trunk, which already contains AsyncHttpClient, whenever he wants. I know that. You obviously missed why I posted this information. The AsyncHttpClient code Jeff worked on in his Geronimo sandbox is about to get forked over to some other project. The Geronimo folks are looking for a home for it. I wanted people in general to know that Jeff is here working on that stuff. Makes sense? Yep, thanks for the information. On Jan 10, 2008 7:02 AM, Jeff Genender [EMAIL PROTECTED] wrote: Trustin Lee wrote: He made some big changes in Geronimo sandbox before I made some big changes in his original contribution, and that's why it's taking some time. So.. Jeff will migrate the code to the trunk eventually I guess. Yes I will ;-) I am swamped at the moment...but I will ;-) On Jan 10, 2008 6:16 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I think Jeff started working on some of it over at MINA btw. Excuse the cross post. Alex On Jan 9, 2008 4:10 PM, Matt Hogstrom [EMAIL PROTECTED] wrote: If it is better and easier than http-client are they interested in it? Seems like a logical fit. That said, I think Genender boy wanted to melt some metal when he started this work. If it remains without a home I'd put it in components and let folks pick it up if they are interested. On Jan 9, 2008, at 9:55 AM, Kevan Miller wrote: On Jan 8, 2008, at 9:59 AM, Donald Woods wrote: #3 is okay with me. Was just thinking that #2 (plugin) would allow us to expose it on our plugin website and allow other users to just place a dependency on it in their plugins Oops. Got distracted and forgot to reply... I was thinking that AHC functionality could be released under components (and thus easier to consume by other projects). We can then create a plugin which includes this component. So, really a combination of 2 and 3. --kevan -Donald Kevan Miller wrote: On Jan 5, 2008
Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox
Not wrong at all. Its a little more complicated than that though :/ Let me get some of those guys to chime in. Jeff Emmanuel Lecharny wrote: Jeff Genender wrote: Ugg...yeah...we need to get that team looking at our stuff. The problem is that the large delta is where the problem is going to be. I would like to see the delta be made and brought over here and have them work over here. Jeff As there is nothing like what you have written in MINA currently, your options are : - move it from geronimo sandbox to some Mina sandbox - create a sub-project in Mina Obvioulsy, #1 is not a valid option ;) Am I wrong ? /Snip
Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox
Trustin Lee wrote: Sure we are! Please feel free to start to make contribution. :) BTW is there any express procedure for accepting the existing AHC committers (i.e. Sangjin and Rick) in the MINA PMC? You mean committer, not PMC? ;-) As you know, they are not ASF members and didn't contribute directly to the MINA project so far. I wonder what I am supposed to do. Should I wait for some patches from them just like we do for most people? Yes...absolutely (wait and have patches subitted or some contribution). Follow the Apache way ;-) Yet another list to subscribe to... ;-) Welcome! ;) Trustin
Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox
Keep in mind, I made a Mina 2 branch of AHC in the Geronimo sandbox a few weeks back...Its basically the same as the AHC Mina 1, but the APIs ere changed to work with Mina 2. But the Mina version is significantly different from the one in G right now. Jeff Sangjin Lee wrote: On 1/15/08, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 15, 2008, at 1:26 AM, Trustin Lee wrote: Hi Kevan, On Jan 12, 2008 2:59 AM, Kevan Miller [EMAIL PROTECTED] wrote: Note that this is cross-posted to geronimo dev and mina dev lists... Hopefully the last one... Alex and Trustin, Thanks for the info... More below... On Jan 9, 2008, at 6:16 PM, Trustin Lee wrote: Well, I think it's OK for the Geronimo team to fork AHC, and I'd like to respect them if Jeff already gave the information that his AHC work will be placed under MINA trunk. They have their release schedule and I don't want to let them wait for us. They will need to migrate to the official MINA AHC eventually though. Jeff could show us better road map for this. Sounds like a good plan. We wouldn't necessarily *have* to migrate, but I, for one, would expect that we'll *want* to migrate to Mina (once Mina was able to release the functionality and assuming Mina is as good as AHC... ;-) AHC already depends on MINA. For now, MINA has older version of AHC as a submodule, and Jeff is trying to move the stuff in the G sandbox here. Right. Sorry, I wasn't very clear. I should have said something like we'll *want* to migrate from Geronimo AHC to a Mina AHC... Sangjin, Rick, *and* Jeff have been making a number of changes and enhancements to AHC in our sandbox. Looks like some nice stuff... I would assume you'd be interested in their work (and would guess they'd like to share it with you)? Best to work out those details on mina dev, I would think... Rick has been a G committer for a while... Sangjin is new to our community, but has been making a number of good contributions to AHC. Sure we are! Please feel free to start to make contribution. :) BTW is there any express procedure for accepting the existing AHC committers (i.e. Sangjin and Rick) in the MINA PMC? As you know, they are not ASF members and didn't contribute directly to the MINA project so far. I wonder what I am supposed to do. Should I wait for some patches from them just like we do for most people? Sangjin is not a Geronimo committer, but has been making some nice contributions... There's no express procedure for moving code from Geronimo to Mina. You can always just copy the code. However, best, if Sangjin and Rick engaged with your community -- explaining their changes, and submitting patches. I'm suggesting that they do that, but it's their decision to make... --kevan As Kevan said, I'm not yet a Geronimo committer, but I've been actively providing patches around AHC, and I hope I'd be a committer soon. It'd be nice to become a Mina committer as well. :) I agree the right thing to do is for us to resubmit patches to Mina. Since the version of Mina the Geronimo AHC is based on is 1.1.x, I suspect simple copy just won't work. We could essentially replay our patches (presumably in the same order), making sure things work correctly at each step. How does that sound? Thanks, Sangjin
Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox
Hi sangjin, http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ Jeff Sangjin Lee wrote: Jeff, Can you point me to the Mina 2 branch of AHC in G sandbox? Thanks, Sangjin On 1/15/08, Jeff Genender [EMAIL PROTECTED] wrote: Keep in mind, I made a Mina 2 branch of AHC in the Geronimo sandbox a few weeks back...Its basically the same as the AHC Mina 1, but the APIs ere changed to work with Mina 2. But the Mina version is significantly different from the one in G right now. Jeff Sangjin Lee wrote: On 1/15/08, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 15, 2008, at 1:26 AM, Trustin Lee wrote: Hi Kevan, On Jan 12, 2008 2:59 AM, Kevan Miller [EMAIL PROTECTED] wrote: Note that this is cross-posted to geronimo dev and mina dev lists... Hopefully the last one... Alex and Trustin, Thanks for the info... More below... On Jan 9, 2008, at 6:16 PM, Trustin Lee wrote: Well, I think it's OK for the Geronimo team to fork AHC, and I'd like to respect them if Jeff already gave the information that his AHC work will be placed under MINA trunk. They have their release schedule and I don't want to let them wait for us. They will need to migrate to the official MINA AHC eventually though. Jeff could show us better road map for this. Sounds like a good plan. We wouldn't necessarily *have* to migrate, but I, for one, would expect that we'll *want* to migrate to Mina (once Mina was able to release the functionality and assuming Mina is as good as AHC... ;-) AHC already depends on MINA. For now, MINA has older version of AHC as a submodule, and Jeff is trying to move the stuff in the G sandbox here. Right. Sorry, I wasn't very clear. I should have said something like we'll *want* to migrate from Geronimo AHC to a Mina AHC... Sangjin, Rick, *and* Jeff have been making a number of changes and enhancements to AHC in our sandbox. Looks like some nice stuff... I would assume you'd be interested in their work (and would guess they'd like to share it with you)? Best to work out those details on mina dev, I would think... Rick has been a G committer for a while... Sangjin is new to our community, but has been making a number of good contributions to AHC. Sure we are! Please feel free to start to make contribution. :) BTW is there any express procedure for accepting the existing AHC committers (i.e. Sangjin and Rick) in the MINA PMC? As you know, they are not ASF members and didn't contribute directly to the MINA project so far. I wonder what I am supposed to do. Should I wait for some patches from them just like we do for most people? Sangjin is not a Geronimo committer, but has been making some nice contributions... There's no express procedure for moving code from Geronimo to Mina. You can always just copy the code. However, best, if Sangjin and Rick engaged with your community -- explaining their changes, and submitting patches. I'm suggesting that they do that, but it's their decision to make... --kevan As Kevan said, I'm not yet a Geronimo committer, but I've been actively providing patches around AHC, and I hope I'd be a committer soon. It'd be nice to become a Mina committer as well. :) I agree the right thing to do is for us to resubmit patches to Mina. Since the version of Mina the Geronimo AHC is based on is 1.1.x, I suspect simple copy just won't work. We could essentially replay our patches (presumably in the same order), making sure things work correctly at each step. How does that sound? Thanks, Sangjin
Re: [ASYNCWEB] What's the plan regarding it's leaving the sandbox?
I personally don't know what is going on but I really like AsyncWeb and would love to see it come out of the sandbox. I would be happy to also help refactoring it. Jeff Alex Karasulu wrote: Do you have any idea on when we can release MINA proper 2.0 M1. I ask this because I would like to see at least some beta release of asyncweb which depends on it? Furthermore we probably need to move it out of the sandbox now that the IP has been cleared but it needs some work. I will start cleaning it up to get it ready for some kind of beta release. Also are we bound to maintain the MINA API between milestone releases? Any comment? Anyone besides Trustin know what's going on? If releases without freezing the API are not possible then we might have an issue with this model. Alex
Re: [Asyncweb] Motives behind filter-codec-http and asyncweb
Trustin Lee wrote: BTW providing AHC as a subproject might be a good idea - for now it's included as a MINA submodule, but we can provide it as a separate subproject. I'd like to know what Jeff thinks about it. +1...I like the idea of it being a sub project ;-) Trustin On Jan 21, 2008 3:05 AM, Alex Karasulu [EMAIL PROTECTED] wrote: Hi, MINA 2.0 is pushing the inclusion of specific protocol codecs into the core: I am specifically referring to the filter-codec-http module. Who decided on this policy and why? Trustin, according to SVN logs you commit this and it seems as though some of it was extracted from or overlaps the asycweb functionality. What is the intention for asyncweb as a subproject if it's functionality is being moved over to MINA core? Thanks, Alex
Re: [Asyncweb] Updates on recent changes
Nice! Alex Karasulu wrote: Hi all, I started cleaning up and organizing the Asyncweb subproject today which entailed: o moving Asyncweb out of the sandbox into the new structure discussed here [0] with slight differences o moving filter-codec-http into Asyncweb as a module o changing package names o moving 3 classes of protocol-http-client into Asyncweb as a module o cleaning up NOTICE.txt and LICENSE.txt files o cleaning up problems resulting from back and forth movement of the HTTP codec Here's what the present directory structure of asyncweb looks like as seen here [1]: ... mina/asyncweb . |-- branches |-- tags `-- trunk |-- LICENSE.txt |-- NOTICE.txt |-- assembly |-- client |-- common |-- examples |-- pom.xml |-- server `-- spring There are 6 modules here. Some points about the module migrations and name changes: [NOTE: Below the module name based on the maven POM's name tag is used.] Module: Apache Asyncweb Common - Most of a common package containing the HttpX interfaces was, as shown earlier, re-factored and moved into the MINA subproject along with the HTTP codec into the MINA filter-codec-http module. Asyncweb is not concerned with advertising that this module and it's artifact is a MINA codec which a small part of it contains. Furthermore this module is shared between the http client AHC (3 classes) and the Asyncweb server. Because of these reasons it was best called the asyncweb-common module. Again the fact that this module contains a codec is irrelevant. Module: Apache Asyncweb Client - The Asyncweb Client module is comprised of 3 Java source files and represents the previous protocol-http-client which was referred to as Async HTTP Client (AHC). This module depends on and uses the Asyncweb Common API and the HTTP codec within it to function. Hence as discussed and out of common sense this protocol-http-client module in the MINA subproject was moved under Asyncweb as the Apache Asyncweb Client module. Module: Apache Asyncweb Server -- This represents the old Asyncweb 'core' module from the sandbox with the mentioned cleanups. Module: Apache Asyncweb Spring -- This represents the old Asyncweb 'springframework' integration module from the sandbox with the mentioned cleanups. Module: Apache Asyncweb Examples --- This represents the old Asyncweb 'example' module from the sandbox with the mentioned cleanups. Module: Apache Asyncweb Assembly --- This represents the old Asyncweb 'assembly' module from the sandbox with minor cleanups. I hope everyone has a chance to take a look, build etc and give feedback. If curious and you don't have the time here's what the build run output looks like with these names and this structure. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Apache Asyncweb Parent [INFO] Apache Asyncweb Common [INFO] Apache Asyncweb Server [INFO] Apache Asyncweb Client [INFO] Apache Asyncweb Spring [INFO] Apache Asyncweb Examples ... [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Asyncweb Parent SUCCESS [ 1.856s] [INFO] Apache Asyncweb Common SUCCESS [ 4.871s] [INFO] Apache Asyncweb Server SUCCESS [ 3.959s] [INFO] Apache Asyncweb Client SUCCESS [ 11.553s] [INFO] Apache Asyncweb Spring SUCCESS [ 0.668s] [INFO] Apache Asyncweb Examples .. SUCCESS [ 0.795s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] I hope this report clarifies the changes and helps people get back up to speed with Asyncweb. Thanks, Alex [0] Directory Restructuring Thread - http://tinyurl.com/23dclx [1] Asynchweb in Subversion - http://svn.apache.org/repos/asf/mina/asyncweb
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] On bringing the code bases and communities together
Rick, This was the port I did to Mina 2: http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ Jeff Rick McGuire wrote: Alex Karasulu 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? Yes, I'm definitely interested in helping out. Right now, I'm having a hard time figuring which is the correct Mina 2.0 version. There appear to be at least 3 different versions of an AsyncHttpClient floating around (one in the Mina trunk, one in the AsyncWeb tree, one in the Geronimo sandbox). Which is the appropriate one to start porting the recent changes to the 1.1.5 version to? Rick 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
Yes.. I think that is the best course of action. I think they are pretty similar since I created the mina 2 version in late December. I think the delta is rather small. Jeff On Jan 31, 2008, at 1:34 PM, Sangjin Lee [EMAIL PROTECTED] wrote: Just so I understand... What is the direction we're taking? Just for the terminology sake, I'll call these versions - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were working on) - g-ahc-v2: Geronimo AHC based on Mina trunk - mina-ahc: Mina AHC that was refactored into asyncweb Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to migrate them again from g-ahc-v2 to mina-ahc? Thanks, Sangjin On Jan 30, 2008 6:36 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] wrote: Being that its in the sandbox...anything goes. ;-) However...with that said...lets see what pans out here at Mina. I would certainly consider the delta now before we get 3 diverse versions ;-) Yes the preferred version is Mina 2.x. Indeed! We might want to first make sure the two Geronimo forks are merged and using MINA 2.0. Meaning all the features and fixes in the one based on MINA 1.1.x are put into the one based on MINA 2.0-M1. That might bring the consolidated Geronimo fork closer to the MINA version in Asyncweb trunk. Then we can focus on how to merge these two together? Alex
Re: [AsyncHttpClient] On bringing the code bases and communities together
Or you can use Linux or Mac ;-) j/k! Thanks for looking into that Rick. Jeff Rick McGuire wrote: I had some time this morning, and decided to take a look at this. It was fairly straightforward merging the changes back in to the 2.0 sandbox branch. There's a bit of a problem going on here with the jsps used for the tests. In the 1.1.5-based version, there was no eol-style property set for the jsps. This caused the strings that were returned by the tests to use \n for line terminators, which the unit tests expected to find in the message responses. In the 2.0 version, the eol-style is set to native, which causes the unit tests to fail when run on a Windows system. I was able to hack these up so they're now running cleanly, but I'm not terribly confident these won't end up breaking again in the future. I suspect a less encoding-specific approach is going to be needed for validating the responses should be used. Rick Jeff Genender wrote: Yes.. I think that is the best course of action. I think they are pretty similar since I created the mina 2 version in late December. I think the delta is rather small. Jeff On Jan 31, 2008, at 1:34 PM, Sangjin Lee [EMAIL PROTECTED] wrote: Just so I understand... What is the direction we're taking? Just for the terminology sake, I'll call these versions - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were working on) - g-ahc-v2: Geronimo AHC based on Mina trunk - mina-ahc: Mina AHC that was refactored into asyncweb Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to migrate them again from g-ahc-v2 to mina-ahc? Thanks, Sangjin On Jan 30, 2008 6:36 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] wrote: Being that its in the sandbox...anything goes. ;-) However...with that said...lets see what pans out here at Mina. I would certainly consider the delta now before we get 3 diverse versions ;-) Yes the preferred version is Mina 2.x. Indeed! We might want to first make sure the two Geronimo forks are merged and using MINA 2.0. Meaning all the features and fixes in the one based on MINA 1.1.x are put into the one based on MINA 2.0-M1. That might bring the consolidated Geronimo fork closer to the MINA version in Asyncweb trunk. Then we can focus on how to merge these two together? Alex
Re: I wish to say a few words...
Thanks guys! Jeff Emmanuel Lecharny wrote: Alex Karasulu wrote: On Feb 3, 2008 4:53 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Jeff Genender wrote: Is someone not doing a good job as a monitor? This stuff shouldn't get onto these lists. Id do monitor every single mail on MINA and Directory. I can assure you that this mail hasn't been considered as spam at all. It went directly through the mailing list, for some reason. Should we report this to infra ? Yeah good point otherwise it will happen over and over again. Reported...
Re: connect timeout
great question..Im interested in this as well. Jeff Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? Thanks, Sangjin
Re: [AsyncHttpClient] On bringing the code bases and communities together
Mike Heath wrote: I've been looking into merging http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ into http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/ and I'm trying to figure out the best way to proceed. Here are some of the pain points I see: - The only redeeming quality about the AsyncWeb client is that it uses the AsyncWeb codec. - There are a few things in AHC that duplicate functionality already available in MINA (timeouts for example) I think this timeout is a different timeout in implementation...that is unless this was added to 2.0, then duplication may be correct. Its a response timeout, not socket timeout...I think thats different. - The AHC codec and the AsycnWeb codec have diverged quite a bit. To resolve these pain points, here is how I would like to proceed. I would like to copy the AHC async-http-client-mina2 code as is into the AsyncWeb client repository. Because AHC and AsyncWeb client use different package names, there shouldn't be any conflicts doing this. Once that is done, we can look at removing the AHC code that reimplements functionality available in MINA. As long as all the tests are passing, we should be fine and if there are gaps in testing, we should fill those. Once that is done, we can look at refactoring the AHC code base to use the AsyncWeb codec while at the same time, make sure that the AsyncWeb codec isn't missing any functionality that is implemented in AHC. I think at this point, we can rename the AHC packages and move it over top the current AsyncWeb client. Am I missing anything in AsyncWeb client that needs to merged into AHC? It's only four classes and I didn't see anything in there that isn't available in AHC. Before going ahead and doing this, I wanted to know what everyone else thinks of this plan. Does anyone else have a different idea as to how best to undertake this merge? Am I missing anything? I like the plan...seems like a good way to go. -Mike Sangjin Lee wrote: Yeah I believe so (as far as I can tell). It was more or less a straightforward porting, so there might be interesting and subtle behavior changes we may need to look at. But it should be a good solid baseline. Thanks, Sangjin On Feb 4, 2008 2:50 PM, Mike Heath [EMAIL PROTECTED] wrote: Rick McGuire wrote: I had some time this morning, and decided to take a look at this. It was fairly straightforward merging the changes back in to the 2.0 sandbox branch. There's a bit of a problem going on here with the jsps used for the tests. In the 1.1.5-based version, there was no eol-style property set for the jsps. This caused the strings that were returned by the tests to use \n for line terminators, which the unit tests expected to find in the message responses. In the 2.0 version, the eol-style is set to native, which causes the unit tests to fail when run on a Windows system. I was able to hack these up so they're now running cleanly, but I'm not terribly confident these won't end up breaking again in the future. I suspect a less encoding-specific approach is going to be needed for validating the responses should be used. Rick Rick, Does http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ contain all the bug fixes and latest features of AsyncHttpClient? Can we use this to merge the changes over to the client under MINA? -Mike snip
Re: [AsyncHttpClient] On bringing the code bases and communities together
Mike Heath wrote: What the FAQ is saying is that the idle event wont tell you which request message was issued when the timeout occured. So using an idle read to detect an unresponsive connection is perfectly legitimate. I don't see why using idle wouldn't work for pipelining. If the session times out, it gets closed which would cause any pending requests to fail anyway. I may just be presumptuous. Am I missing something? This is pipelining...using a single connection for reuse for multiple requests, which tells me that a sessionIdle would probably not work. But if you are saying its possible, then great! Jeff -Mike
Re: [AsyncHttpClient] On bringing the code bases and communities together
Mike Heath wrote: To clarify, my understanding of pipelining is that it is sending multiple requests and then waiting for the corresponding responses. This is more than HTTP keep alive which would also allow using a single connection for multiple requests but doesn't necessarily involve the batching of pipelining. I understand it slightly different..that you can send multiple requests through the same socket. The difference between what you said and what I said is I think pipelining does not have stacked waiting. But if you are saying its possible, then great! What I'm saying is that in the AHC code at http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2, the HttpIoHandler.TimeoutTask is unaware of which request has been sent. It only knows which IoSession is being used (that's the only field in the TimeoutTask). So essentially the timeout logic as it is implemented in AHC is no different than using the MINA idle logic. Does the AHC client currently support pipelining? If I issue two pipelined requests, and the first one times out causing the session to close. How does the future of the second request get notified of the timeout? I only see code for working with CURRENT_REQUEST (from the IoSession attributes). I don't see any code for dealing with pending requests. You are rightno AHC does not support pipelining but we were coding it to go in that direction so we could. We knew that it would be a lot more complex to implement, but wanted to sow the seeds of the code to handle it when we did. OTOH, I must admit I implemented the ScheduledExecutor based on the FAQ and a few IRC discussions ;-) but if sessionIdle will work, then that would be the way to go. -Mike BTW - Thanks for the discussion, Jeff. It's really helped me to go back and look deeper in the AHC code. Thank you...and thanks for taking an interest...this is great ;-) -Mike
Re: [AsyncHttpClient] On bringing the code bases and communities together
Wow...this is awesome...I could have used this because this is essentially the same mechanism I wrote in AHC ;-) Yeah...this should be documented in the FAQ somewhere as this would come in handy. Jeff Julien Vermillard wrote: Hi, Just by the way, if you want to monitor a request/response behaviour you got the reqres filter : http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/ Julien
Re: [AsyncWeb] SSL server and client certs
Look in the Trust Factory..that is exactly where you need to look. Currently the SSL impl is based on communication and anonymous only (I was working on the SSL client cert but got side tracked with my new job). You probably should allow for a setter that allow you to set a certificate object and, to make things easy on the user, a way to pull one from a file and keystore (Im just thing about how to make this API as simple as possible). The Trust Factory is exactly the area I would recommend adding the enhancement. Alan...this is awesome stuff...thanks for taking such an interest! Jeff Alan D. Cabrera wrote: I need this. What will it take for me to add it? It looks like it I need to flesh out that trust factory. Regards, Alan
Re: [AsyncWeb] Need an async client now
I agree...I think 2.0 is the way to go...the enhancements really make it nicer. Jeff Alex Karasulu wrote: On Feb 9, 2008 12:39 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote: On Feb 9, 2008 3:56 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: What should I use? I prefer the API from Geronimo but I see that it doesn't get built in in Mina. I would also prefer to use Mina 1.x and wait until Mina 2.x shakes itself out. So, I'm going to toss out the idea of releasing the new API as 1.0 and we can release the new Mina 2.x based API as 2.0. Thoughts? IMO I think looking ahead towards the use of MINA 2.0 is the best route here and it seems that people have already taken care of the merge. Perhaps there's some emails that you may have missed on the commits@ list and here. Mike already merged the two I think unless I'm mistaken which may be the case since I have been catching up as well. Well, it is in SVN. At the moment there are two clients in there. The newer one does not get added to the Jar artifact per its POM configuration. I really prefer the newer one from Geronimo. Oh and 1.0 whichever MINA it's based on makes sense to me but jumping to 2.0 to denote the use of MINA 2.0 sounds good too. I just think we should stick to MINA 2.0 through and through because of the gains made therein. Only the Pope and my mother-in-law are infallible. I think that MINA 2.x rocks and will be a resounding success but I think it will take a little bit for things to shake out. IIUC, there's still discussion to fiddle with bits of 2.0. I just want to start w/ MINA 1.x for now. Its characteristics are known and it's been around the block a few times. I am happy to do the scut work for a 1.0 release. Loved the comment about the Pope and your MIL :). You can always work on a 1.0 based version but we're still far from a release as well since the PMC is just mobilizing around these new projects. Also note that a MINA 2.0release is imminent. Furthermore there's been considerable effort put into keeping all the people interested in Asyncweb working together towards a common goal. Sticking to MINA 2.0 overall will be in the best interest of the community. We're seeing great synergy where core MINA folks are working closely with the AHC developers. It's really great to see ramping up and took a bit of effort. If there are any hick-ups along the way with MINA 2.0 you have my word and I'm sure the word of others' here to resolve them immediately. Fragmenting this community into those that work on 1.0 and 2.0 based version of AHC just when the collaboration is ramping up would not be good. Please don't presume the time frame is going to be longer when based on MINA 2.0. Whatever the issue may be for you we'll try our best to accommodate whatever it may be. Is there some other problem that you have not mentioned which requires a 1.0 release besides just doing it rapidly? Thanks, Alex
Re: [AsyncWeb] AHC Wiki Space Created
Awesome...thanks Alan. Alan D. Cabrera wrote: I've made this space for us: http://cwiki.apache.org/confluence/display/AHC/Index Regards, Alan
Re: [AsyncWeb] Client redesign
David M. Lloyd wrote: Yes, this is my thinking as well - the casual user wants a simplified API, while the advanced user wants a more detailed interface. Certainly no reason not to offer both capabilities ;-) Jeff - DML
Re: [VOTE] Release Apache MINA 2.0-M1
+1 Mike Heath wrote: Hello Community, It looks like Maarten has resolved DIRMINA-513. I don't see any reason to hold up a 2.0-M1 release. There are a multitude of changes in MINA 2.0-M1, too many to enumerate in a single email. A laundry list of changes going into this release can be found here https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel This release should not be considered final nor entirely stable. It is a release so that developers using MINA know what to expect in 2.0 as well as help us to find bugs and deficiencies in the API. [ ]: +1, Release MINA 2.0-M1 [ ]: 0, Abstain [ ]: -1, Don't release MINA 2.0-M1 -Mike
Re: MINA at JavaOne 2008 - idea wanted
Yeah I am in agreement with Mike. An architectural overview...and an example (heck use AHC vs HttpClient) and show how it scales. That will get ooohs and ahhhs. Jeff Mike Heath wrote: One of the problems I've had when promoting MINA is that most Java developers don't understand the scalability implications of the thread-per-connection architecture. If I jump right in with how cool MINA is with its separation of concerns, futures, filters, event mechanism, simplifies packet fragmentation problems, etc., the audience either gets lost or replies with something like, Using InputStreamsis just as flexible as filters but doesn't come with all the difficulties of having to build a state machine. MINA just makes things complicated! However, if I start out showing how quickly I get an OOM exception when using a thread-per-connection architecture and then show how I can handle thousands of connections in MINA without consuming loads of memory, the audience is able to better understand the main problem that MINA solves. Showing how painful it is to use NIO directly is fairly simple at this point. The important part is making sure the audience understands the need for the functionality that NIO has to offer. Once the audience understands the problems MINA solves, I've found they're usually much more receptive to the coolness that MINA has to offer. Just my $0.02. -Mike 이희승 (Trustin Lee) wrote: Hi, I was invited as a speaker of JavaOne 2008 and will speak about Apache MINA there. Please feel free to contact me to give me some idea about what you want to hear about MINA if you have any plan to attend this year's JavaOne. Cheers, Trustin
Re: doubt Mina
FYI...if you are going to do this...you are gonna have to tweak your IP
stack to be able to handle that many open sockets.
Jeff
[EMAIL PROTECTED] wrote:
to example echoserver, how to make this test:
open 2 conection and send message simultaneous? someone did this?
I want to check the performance of the example echoserver.
some tips?
thanks
On 2/13/08, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [AsyncWeb] build broken w/ last checkin
Sangjin Lee wrote: I noticed this too... Incidentally I also noticed that the SSL unit tests were broken due to the way that the SSL filter is added but that seems to be an old issue. The SSL filter should be added before the protocol codec filter... Shall I file a bug and submit a patch for both? File a bug and *commit* a patch...you are a committer now ;-) Jeff
Re: [AsyncWeb] build broken w/ last checkin
I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: Do we need all those @Override ?
I would keep them because they really help when there are changes in super classes during a compile. Jeff Emmanuel Lecharny wrote: i guys, while browsing MINA's code, I see @Override used everywhere. I know it can be helpful when overriding an existing method, but do you think we need to keep them ? wdyt ?
Re: Do we need all those @Override ?
Yep...thats basically correct. Its a protection for if you change a base method. Normally w/o the annotation, you would orphan any subclasses by changing a super class signature. With the @Override, the compiler throws an error and says you are overriding a function that doesn't exist. Its really good for orphan control. Its great because debugging these things can be awful which is why I typically like them. They have saved me many times ;-) Jeff Emmanuel Lecharny wrote: Alex Karasulu wrote: Hey Mike, Jeff, Not denying these claims but just curious. Can you guys educate me as to how it works, or helps in these cases. I never bothered to investigate this @Override tag. Basically (and I'm not a user of this tag), it's helpfull when you want to override a method from an upper class and want to be sure that the API user won't call the wrong method by mistake. For instance, suppose you override the compareTo method because the super.compareTo is not ok, and now suppose you misnamed the method (compareto with a lower 't'). The API user will use compareTo, and will call the super method instead of the one you want him to use. With the @Override tag, this can't happen, because the compiler won't fine a compareto method, and will issue an error. So, yes, it may be useful. Thanks, Alex On Thu, Jun 5, 2008 at 6:28 PM, Jeff Genender [EMAIL PROTECTED] wrote: I would keep them because they really help when there are changes in super classes during a compile. Jeff Emmanuel Lecharny wrote: i guys, while browsing MINA's code, I see @Override used everywhere. I know it can be helpful when overriding an existing method, but do you think we need to keep them ? wdyt ?
Re: [VOTE] Releasing FtpServer 1.0.0-M3
+1 On Sep 4, 2008, at 12:44 PM, Alex Karasulu wrote: [X]: +1, Release FtpServer 1.0.0-M3 Alex
Re:
[X] Freeze the code, move to MINA 2.0-RC1 On Nov 18, 2008, at 4:04 AM, wrote: Hi guys, I think it's time to stop discussing for ever and to start a vote. MINA 2.0.0-Mx is around for months now, and we have more and more users developing applications around it. We have tons of proposal to improve MINA, but many of them are pretty drastic, and may jeopardize our users' investment. OTOS, if we close MINA 2.0 now, we also close the door to some very important features and improvement we want to have in MINA, which will be differed for months if we start a 3.0. So the best would be to determinate which strategy should be the best. Here is a proposal. [] Continue to add new features to MINA 2.0 milestones until we reach a stable point [] Freeze the code, move to MINA 2.0-RC1 [] I abstain If we select (1), we will have to determinate the clear roadmap, otherwise we won't be able to release 2.0 before 2017... If we pick (2), we have to check the open JIRAs, fix them, and define a timeframe for 2.0-RC1 release (and it should be a matter of weeks, not months) Guys, it's up to you ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [PROPOSAL] Create a MINA subproject to implement a SSH server based on Mina
Great idea...great code! On Nov 19, 2008, at 4:27 AM, Guillaume Nodet wrote: I guess the next step is to start a formal vote about that, right ? As I've been the only committer on the project, I don't think a software grant would be needed for that. On Thu, Nov 13, 2008 at 3:07 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: A few weeks ago, I've started a small project at googlecode to implement an SSH server in Java based on Mina. You'll find some background at http://gnodet.blogspot.com/ The project is still in its early stage and require a lot more work to be fully usable, but I've been doing some tests and the basic SSH protocol itself is implemented. The project is available at http://code.google.com/p/sshd/ My thinking is that it would be a good candidate to become a subproject of Mina (along with ftpserver and asyncweb), so i'm starting this discussion to gauge the interest of the MINA TLP to host such a subproject. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
+1 Jeff On Nov 20, 2008, at 2:52 AM, Guillaume Nodet wrote: +1 On Thu, Nov 20, 2008 at 12:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, Guillaume Nodet has written a SSH server based on MINA, and as we discussed it last week, it would be interesting to have it as a subproject. It's time for a formal vote then : [] +1 Yes, accept the SSH server as a sub-project [] +/-0 I don't really care [] -1 Nope, it does not belong to MINA -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [Vote] Release MINA 2.0.0-M4
+1 On Dec 4, 2008, at 4:49 PM, Emmanuel Lecharny wrote: Hi guys, we have released 2.0.0-M3 a few weeks ago (nov, 8th). I think it's time for the last milestone before RC1 now. We still have a few issues to fix (7), but so far, the API won't change now. I would call this release the API freeze release. Once release, we should work on 2.0-RC1, fixing the last bugs, and more important, adding documentation to the project. Hopefully, we can get a 2.0-RC1 by the very beginning of 2009, and a 2.0-GA a few weeks later, if everything goes right. So now, let's open the vote : [] +1, let's release 2.0.0-M4 and freeze the API [] +/- 0, abstain [] -1 : we are not ready, let's wait a bit more. Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: IntelliJ IDEA for development
They already offer open source licenses to Apache (and many other open source projects) as opposed to per-project. Committers with apache.org addresses just need to apply. Here is the info: http://www.jetbrains.com/idea/buy/buy.jsp#openSource Thanks, Jeff On Jan 21, 2009, at 3:58 AM, Ashish wrote: JetBrains supports open source community, including ASF, by providing individual licenses. I was thinking for applying for Open Source License for MINA project Should I go ahead and apply for it? Do we have any guidelines for the same? I have used IntelliJ for a quite sometime and abandoned it couple of months ago, as the new version was creating more trouble than helping me. Lately I have been using MyEclipse for all my development. The reason why I want to try it again is, IDEA is little lighter than Eclipse (while running). Any suggestions?
Re: AsyncWeb jars incomplete
Ditto for me... glad to see folks making use of this. I could help a bit too, but my bandwidth is also tight. Glad to see this come up again. Jeff On Mar 3, 2009, at 10:13 AM, Sangjin Lee wrote: I was one of the people who were involved in bringing AHC over from the Geronimo sandbox (where it was first developed) to under asyncweb. Originally it was based on mina 1.1.x as at that time mina 2.0 was still in its active development. We did the bare minimum to make it compile against mina 2.0 (but not necessarily all the runtime correctness), and merged them. It landed at the org.apache.ahc package to avoid confusion with the pre-existing client code that was under org.apache.asyncweb.client. The intention has been that not only would we make it work correctly with 2.0, move to a common codec, subsume the existing client, etc. but also would redesign the client. Unfortunately, the momentum stalled because key people who were most interested in making this happen (myself included) didn't get to make the big push. For me, my involvement was cut down for reasons that are unrelated to the project. Some discussion threads that may be of help: http://tinyurl.com/djr4pa http://tinyurl.com/azbpzg http://tinyurl.com/dkrlzv http://tinyurl.com/csonsf Having said that, I'd love to see this get going again (although my bandwidth on this is still quite limited). I'd certainly be happy to contribute what I can... As a side note, there is a working version of the asyncweb client in the 1.0 branch. This is almost the original version that is based on 1.0, and I think it is of production quality (we're using it in production). It hasn't seen an official release however. But please note that I don't think we will (or should) support this in a serious manner. Instead, we need to focus our effort on the trunk version based on mina 2.0. My 2 cents. Thanks, Sangjin On Mon, Mar 2, 2009 at 8:34 AM, Jacob Tomaw jacob.to...@gmail.com wrote: Emmanuel, Your caution is understandable. The only code change for the server is setting up the MINA LoggingFilter, but clearly there might be changes in MINA from M3 to M4 that affect the server in an unknown way. I am very interested in improving AsyncWeb (at least the client portion). My company is in the process of upgrading out 85+ application (no idea how many JVMs) to use AHC to communicate with each other. Is there someone already attached to the project who has a deep knowledge of AsyncWeb and has a direction they would like to see the project go? Right now there are to clients in the client dir and it is not clear what should happen with the two of them and if any more transitioning need to take place. Thanks, Jacob On Fri, Feb 27, 2009 at 11:25 AM, Emmanuel Lecharny elecha...@apache.org wrote: Jacob Tomaw wrote: I see that this is happening because the client is not completely moved from the ahc structure to the asyncweb.client structure. It is also not using the common codec. I am prepared to open jiras and create patches to clean this up. However, I want to gauge the likelihood of these patches being integrated into the trunk. I see several jiras with ptches attached and not further comment. Neither acceptance or rejection. Hi Jacob, it's just a matter to find people interested in improving AsyncWeb ! I will have a look at the patches, and try to get them applied. However, I have a very shallow knowledge about AsyncWeb code base, so I'm afraid it can break the server... Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org -- Jacob Tomaw tfl:The Flatiron Life (http://tomaw.com) Follow me on Twitter! (http://twitter.com/JacobTomaw)
Re: unable to send multiple messages simontanously
This is usually caused by an un-tuned IP stack in your OS. These symptoms usually occur when you have hit the max sockets. You generally hit this limit because your socket timeouts are set too high (it can be 30-60 seconds by default before the socket is released back to the OS). I would Google tuning IP stacks for your particular OS and concentrate on upping your allowed sockets and setting your socket timeout/wait to 1 second. If you are sending all these calls from a single client, you may need to do this on the client too. Jeff On Mar 14, 2009, at 7:53 AM, Nagesh wrote: Hi All, I am testing the server load by trying to send multiple messages simontanously. I am trying to create the 100 sessions and trying to write messages to those 100 session with a second gap. but it starts sending up to some time after that it does not give any exception and stops sending messages. can any one suggest me what might be the problem and possible solution to it. any help is highly appreciated. Thanks, Ajay.
Re: [VOTE] Vysper as MINA subproject
+1 On Apr 12, 2009, at 2:32 AM, Julien Vermillard wrote: Hi guys, Bernd Fondermann has written a XMPP server based on MINA in Apache labs. As discussed earlier we all see interest in making Vysper a MINA sub-project, do let's vote : [] +1 Yes, accept Vysper as a sub-project [] +/-0 I don't really care [] -1 Nope, MINA is not the place for Vysper Julien
Re: [VOTE] Release MINA 2.0.0-M6
+1 On May 26, 2009, at 12:52 PM, Niklas Gustavsson wrote: On Tue, May 26, 2009 at 3:08 PM, Emmanuel Lecharny elecha...@apache.org wrote: I didn't produced any package, as the mavn assembly plugin is deeply bugged Binaries available at http://people.apache.org/~ngn/mina/2.0.0-M6/ [X] +1: Yes, release MINA-2.0.0-M6 /niklas
Re: [VOTE] Releasing FtpServer 1.0.2
+1 On Jun 13, 2009, at 3:38 AM, Guillaume Nodet wrote: +1 On Fri, Jun 12, 2009 at 22:40, Niklas Gustavssonnik...@protocol7.com wrote: Hey, We got another set of bugs fixed, so I think we're ready for a 1.0.2. You can find the binaries and Maven artifacts here: http://people.apache.org/~ngn/ftpserver/1.0.2/ These files was built from the following code: https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.2 The bugs fixed are: https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/ 12313952 [ ]: +1, Release FtpServer 1.0.2 [ ]: 0, Abstain [ ]: -1, Don't release FtpServer 1.0.2 /niklas -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: asyncweb client 1.0 work
+1... can't wait to see the contribution! Jeff On Jun 17, 2009, at 3:33 PM, Sangjin Lee wrote: Hi, We've been actively using the asyncweb client (the 1.0 version) in production for a while, and I have a number of pent-up changes I wish to contribute back. Our company also has a couple of critical enhancements in mind, and I would like to see that done on this 1.0 branch. I know that there is a trunk version but it has been dormant with little activity for quite some time now (and I shoulder part of the blame as a committer). But we've come to a point where we can no longer defer making these changes and enhancements until the trunk version becomes fully baked while there is a great production that's production ready. So, in light of that, I'd like to open up the asyncweb client 1.0 branch and contribute these bug fixes as well as a couple of enhancements in the future. There was no official release from that branch anyway, and I feel this is something that will add a lot of value to many people. Please let me know if you have objections, and we can discuss. I'd also like to you those of you who are using the asyncweb client in any way and chime in on the discussion. Thanks much! Regards, Sangjin
Re: [Vysper] EhCache implementation - Some queries
Then open a JIRA at Codehaus for Maven Repos and ask Jason if he would push it to central too. He also is a good guy and usually will do that for you unless there are some nasty licensing issues. Jeff On Jul 31, 2009, at 7:47 AM, Ashish wrote: On Fri, Jul 31, 2009 at 6:56 PM, Jeff Genenderjgenen...@apache.org wrote: Contact Greg Luck (the founder). He is really nice and usually is pretty responsive about getting ehcache into central. Thanks Jeff. Will definitely contact Greg. Anyways this is one interesting post from his blog http://gregluck.com/blog/archives/2009/05/anyone_with_a_p.html This explains why he is using the current repos Jeff -- thanks ashish
Re: [VOTE] Release SSHD 0.2.0
+1 Jeff On Aug 21, 2009, at 10:02 AM, Guillaume Nodet wrote: I've uploaded a new release of SSHD that a few bugs / enhancements. The release is available at http://people.apache.org/~gnodet/staging/sshd-0.2.0/ The source distributions are available at: http://people.apache.org/~gnodet/staging/sshd-0.2.0/org/apache/sshd/sshd/0.2.0/sshd-0.2.0-project.tar.gz http://people.apache.org/~gnodet/staging/sshd-0.2.0/org/apache/sshd/sshd/0.2.0/sshd-0.2.0-project.zip http://people.apache.org/~gnodet/staging/sshd-0.2.0/org/apache/sshd/sshd/0.2.0/sshd-0.2.0-project.tar.bz2 The release page is available at: http://cwiki.apache.org/SSHD/sshd-020.html Please review and vote [ ] +1 Release SSHD 0.2.0 [ ] -1 Do not release -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [Vote] Releasing FtpServer 1.0.3 - take 2
+1 On Oct 5, 2009, at 12:44 AM, Guillaume Nodet wrote: +1 On Tue, Sep 29, 2009 at 22:36, Niklas Gustavsson nik...@protocol7.com wrote: Hey, After rolling back the change that would have made the LIST and STAT commands break backwards compatibility, here's a new build. You can find the binaries and Maven artifacts here: http://people.apache.org/~ngn/ftpserver/1.0.3/ These files was built from the following code (recreated from the 1.0.x branch): https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.3 The bugs fixed are: https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/ 12314039 [ ]: +1, Release FtpServer 1.0.3 [ ]: 0, Abstain [ ]: -1, Don't release FtpServer 1.0.3 /niklas -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: AHC api
Looks like you have the right list? ;-) Jeff On Nov 17, 2009, at 7:23 PM, Alan D. Cabrera wrote: I want to flesh out a new async http client. I've got my own ideas for the api and would like to check them in to solicit comments. Where would be a good place to put this? Regards, Alan
Re: AHC api
Why not sandbox (i.e. make a place in the sandbox) the idea and send a pointer to the list? I look forward to seeing what you have! Jeff On Nov 17, 2009, at 9:00 PM, Alan D. Cabrera wrote: Heh, heh. I should have been more explicit. I have a set of interfaces and would like to check them in for people to throw darts at. Regards, Alan On Nov 17, 2009, at 7:57 PM, Jeff Genender wrote: Looks like you have the right list? ;-) Jeff On Nov 17, 2009, at 7:23 PM, Alan D. Cabrera wrote: I want to flesh out a new async http client. I've got my own ideas for the api and would like to check them in to solicit comments. Where would be a good place to put this? Regards, Alan
Re: [VOTE] Release Apache Mina SSHD 0.3.0 (2nd try)
+1 Jeff On Nov 20, 2009, at 7:18 AM, Guillaume Nodet wrote: I've uploaded another release candidate of SSHD 0.3.0. The release is available at http://people.apache.org/~gnodet/staging/sshd-0.3.0/ The source and binary distributions are available at: http://people.apache.org/~gnodet/staging/sshd-0.3.0/org/apache/sshd/apache-sshd/0.3.0/ The binary distribution includes a very simple demo which is far from perfect but that's a start at least ... The release page is available at: http://cwiki.apache.org/SSHD/sshd-030.html Please review and vote [ ] +1 Release SSHD 0.3.0 [ ] -1 Do not release -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release Apache Mina SSHD 0.3.0 (2nd try)
+1 Jeff On Nov 23, 2009, at 1:52 AM, Guillaume Nodet wrote: +1 On Fri, Nov 20, 2009 at 15:18, Guillaume Nodet gno...@gmail.com wrote: I've uploaded another release candidate of SSHD 0.3.0. The release is available at http://people.apache.org/~gnodet/staging/sshd-0.3.0/ The source and binary distributions are available at: http://people.apache.org/~gnodet/staging/sshd-0.3.0/org/apache/sshd/apache-sshd/0.3.0/ The binary distribution includes a very simple demo which is far from perfect but that's a start at least ... The release page is available at: http://cwiki.apache.org/SSHD/sshd-030.html Please review and vote [ ] +1 Release SSHD 0.3.0 [ ] -1 Do not release -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: AHC API
On Nov 23, 2009, at 2:47 PM, Alan D. Cabrera wrote: I've checked in my *very* rough initial thoughts for an API. I vetted them against an Amazon S3 API that I am working on https://svn.codehaus.org/livetribe/nursery/livetribe-s3-api . Can you point out a little more specifically? Can you point out the http specific code? There was a discussion on this a while back. I thought that the connector/connection/client/factory was a bit awkward, imho. There were a few other things but rather than making a tedious comparison I thought that I would just highlight what I think are the key important features of the my API sketch. Hehe - the connector/connection/client/factory was my awkward implementation. ;-) /me dusts himself off after the bus is done running him over ;-) At the time my employer needed something literally within one week to show to its client. So I simply mirrored some of the Mina API to keep it simple, while at the same time utilizing GOF best practice patterns. This was before me running it by anyone. So lets just say it was something I literally threw together (but as a positive note, it certainly performed darn well) ;-) I'm pretty sure that it can support all the use cases listed in http://cwiki.apache.org/AWEB/client-use-cases.html plus a few more. My API is pretty simple. Factories create clients and clients create connections; you can forgo the use of factories. Connections can be reused to implement load balancing/proxying. You'll notice that the core components are not littered with implementation parameters. These are left to implementations of HttpConfig. Yeah that makes a lot more sense. I have an asynchronous mechanism to download content as the HTPP response is being parsed. I think my mechanism for supplying multiple MIME content is pretty clean. Can we see it? Jeff Extensions of HttpListener can be added to obtain various events. I thought that the type safety of listeners would be preferred to a generic HttpEvent listener. There may be overlap with existing APIs. Regards, Alan
Re: AHC API
On Nov 23, 2009, at 4:19 PM, Alan D. Cabrera wrote: Ahh, well, I did state that it was only bit awkward but, now that I know who wrote it I can call it a steaming pile ;) (Just kidding)r DOH! Actually I was talking about the proposed API that we had worked out a while back. Not the 1.x from Geronimo. Whew! /me notices no dust as he guesses he wasn't actually thrown under the bus and it was just a bad dream Look at ClientTest.testSendMultipleAttachments() and ClientTest .testReceiveMultipleAttachments() for a thin mockup of my ideas. A more concrete use can be seen in my S3 API implementation mentioned above. I'll have a looksy. I look forward to seeing what is here ;-) Jeff Regards, Alan
Re: What about releasing a 2.0-RC2/2.0.0 ?
+1 Jeff On Jan 12, 2010, at 10:02 AM, Emmanuel Lecharny wrote: We have fixed some important issues lately in 2.0-RC1 : DIRMINA-749 : We cannot anymore inject more than one CODEC in the chain. DIRMINA-678 : NioProcessor 100% CPU usage on Linux (epoll selector bug) DIRMINA-650 : Mina server does not recieve all data sent by client using SSLSocketFactory Isn't it time for a new release ? Should we call it 2.0.0 ? -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: Are we ready for MINA 2.0.0-RC2 ?
May I ask why this must be a RC2? I think the 2.0 series has gone on a long time and its ok to release a 2.0 version. Thats why we can release 2.0.1, etc. Also... folks have issues with 2.0 release because the dot oh have negative connotations. IMHO, lets get a real 2.0 out and start working on bug fixes. I think we should get out a nice 2.0 and one of the guys can blast it to TSS, etc to show we are moving along again. Thoughts? Jeff On Jan 22, 2010, at 10:41 AM, Emmanuel Lecharny wrote: Sorry, there are some unscheduled issues too : DIRMINA-738Using IoEventQueueThrottler with a WriteRequestFilter can lead to hangs DIRMINA-379setKeepAlive/setTcpNoDelay and exceptions in Windows Vista DIRMINA-724getScheduledWriteMessages not zero after all sessions closed I think we should at least check the first one before launching a vote... Julien Vermillard a écrit : Le Fri, 22 Jan 2010 18:22:35 +0100, Emmanuel Lecharny elecha...@gmail.com a écrit : Hi guys, the JIRA list has been cleared, we just have 5 remaining issues so far : Bug DIRMINA-539NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig Impr DIRMINA-682We need a better documentation for the ExecutorFilter [was :Writing more than one message will block until the MessageReceived as been fully proceced] Impr DIRMINA-593Javadoc documentation for org/apache/mina/ filter/reqres Task DIRMINA-477Update page about differences between 1.x and 2.x Task DIRMINA-708Unbound thread growth on discovery attempts : Improve documentation With one bug ony, and not even a bug I think we will fix, my opinion is that we are ready for a release. Should I postpone all those issues to a newly created 2.0.0-GA version and launch a vote ? +1 for RC2 and postponing remaining issues -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: Are we ready for MINA 2.0.0-RC2 ?
On Jan 25, 2010, at 1:23 AM, Julien Vermillard wrote: Hi, IMO it's dot zero ready, the main effort is on the website and all the PR stuff implying the 2.0 release. it would be a shame to release 2.0 without good announcement and an updated/cleaned website. So lets do that ;-) Jeff Julien Le Fri, 22 Jan 2010 10:47:12 -0700, Jeff Genender jgenen...@apache.org a écrit : May I ask why this must be a RC2? I think the 2.0 series has gone on a long time and its ok to release a 2.0 version. Thats why we can release 2.0.1, etc. Also... folks have issues with 2.0 release because the dot oh have negative connotations. IMHO, lets get a real 2.0 out and start working on bug fixes. I think we should get out a nice 2.0 and one of the guys can blast it to TSS, etc to show we are moving along again. Thoughts? Jeff On Jan 22, 2010, at 10:41 AM, Emmanuel Lecharny wrote: Sorry, there are some unscheduled issues too : DIRMINA-738Using IoEventQueueThrottler with a WriteRequestFilter can lead to hangs DIRMINA-379setKeepAlive/setTcpNoDelay and exceptions in Windows Vista DIRMINA-724getScheduledWriteMessages not zero after all sessions closed I think we should at least check the first one before launching a vote... Julien Vermillard a écrit : Le Fri, 22 Jan 2010 18:22:35 +0100, Emmanuel Lecharny elecha...@gmail.com a écrit : Hi guys, the JIRA list has been cleared, we just have 5 remaining issues so far : Bug DIRMINA-539NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig Impr DIRMINA-682We need a better documentation for the ExecutorFilter [was :Writing more than one message will block until the MessageReceived as been fully proceced] Impr DIRMINA-593Javadoc documentation for org/apache/mina/ filter/reqres Task DIRMINA-477Update page about differences between 1.x and 2.x Task DIRMINA-708Unbound thread growth on discovery attempts : Improve documentation With one bug ony, and not even a bug I think we will fix, my opinion is that we are ready for a release. Should I postpone all those issues to a newly created 2.0.0-GA version and launch a vote ? +1 for RC2 and postponing remaining issues -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com -- Julien Vermillard Archean Technologies http://www.archean.fr
Re: Another Test
Wow... the test passed! Look! --- T E S T S --- Running dev@mina.apache.org alanTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.369 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [ On Feb 9, 2010, at 8:04 PM, Alan D. Cabrera wrote: Another simple test Regards, Alan
Re: Another Test
Ha! On Feb 10, 2010, at 9:33 AM, Alan D. Cabrera wrote: Yeah, my domain records got messed up so it had no SPF records and the apache mail server was balking at my emails to the lists. Regards, Alan (hee hee) On Feb 9, 2010, at 7:42 PM, Jeff Genender wrote: Wow... I'm quite pleased with myself! Look! --- T E S T S --- Running dev@mina.apache.org jeffTest Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: too much time on your hands FAILURE! Results : Failed tests: humor(dev@mina.apache.org jeffTest) Tests run: 1, Failures: 1, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [ On Feb 9, 2010, at 8:04 PM, Alan D. Cabrera wrote: Another simple test Regards, Alan
Re: Hudson strat to p*ss me off ...
It may be worth looking into whether we can use Bamboo which is much better at CI. Its an atlassian project and I think it falls under the usual free open source license. Jeff On Feb 20, 2010, at 2:59 PM, Emmanuel Lecharny wrote: Hi guys, is there any reason why this stupid Hudson *always* fail when we commit some new code, and one hour later come back with again 6 useless mails telling us that Hey, sorry, I was totally f*cked up last time I sent you 6 mails ? If Hudson can't inform us when there are *real* errors, at some point, we will simply ignore the alerts and lose all interest of having Hudson as a safety belt ! Sounds to me like Peter and the wolf... -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: [VOTE] Release MINA 2.0 (take 2)
+1 Jeff On Feb 23, 2010, at 6:21 AM, Emmanuel Lecharny wrote: Hi guys, I canceled the previous vote which was not mentionning a svn version. Julien was kin enough to generate jars : http://people.apache.org/~jvermillard/2.0.0-RC2/ (source tarballs are also available). The build is based on svn revision r912511. [ ] +1 Yes, release 2.0 now [ ] +/-0 I have no opinion [ ] -1 No, wait. My vote : +1 Vote is on for 72 hours, up to friday, 3pm Paris time -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: [VOTE] Release FtpServer 1.0.4 - take 2
+1 Jeff On Mar 7, 2010, at 1:23 PM, Niklas Gustavsson wrote: Hey, Alright, I've fixed the issues found by Sai, here's take 2 on this release vote. You can find the distributions and Maven artifacts here: http://people.apache.org/~ngn/ftpserver/1.0.4/ These files was built from the following code: https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.4 Changelog: https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/12314283 [ ]: +1, Release FtpServer 1.0.4 [ ]: 0, Abstain [ ]: -1, Don't release FtpServer 1.0.4 /niklas
Re: [VOTE] Release SSHD 0.4.0 (third try)
+1 Jeff On May 11, 2010, at 9:24 AM, Guillaume Nodet wrote: +1 On Mon, May 10, 2010 at 21:44, Guillaume Nodet gno...@gmail.com wrote: I've uploaded a RC for SSHD 0.4.0 at https://repository.apache.org/content/repositories/orgapachemina-026/ The release notes are available at https://cwiki.apache.org/SSHD/sshd-040.html Please review and vote. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: MINA coding conventions
+1 Jeff On May 30, 2010, at 3:03 PM, Niklas Gustavsson wrote: Hi In our current coding conventions, we use maximum line widths of 80 chars. I personally find this somewhat limited on modern displays and tend to prefer 120 chars. How about changing this in our coding conventions? /niklas
Re: [VOTE] Time for another vote on MINA 2.0 ?
+1 Jeff On May 31, 2010, at 1:16 AM, Guillaume Nodet wrote: +1 On Mon, May 31, 2010 at 09:11, Emmanuel Lecharny elecha...@gmail.comwrote: Hi guys, we blocked a release a few weeks ago, because some test was failing on windows. Maarten has provided a working version of this test, I'm now wondering if we should not release 2.0, instead of waiting forever that magically the release gets out of the box. My opinion is that the current trunk may not be perfect, but unless we release it, it will be difficult to know what's wrong about it. We also can release a 2.0.1 if needed. I mean, perfection is a goal, not a requirement... Also my perception is that everyone is waiting for 2.0 to be out before starting to work on 3.0. I think it's time. So : [] +1 Yes, release MINA 2.0 [] +/-0 No opinion [] -1 No, we are not ready yet. Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] MINA 2.0.0 take 2
[X ] +1 | Release MINA 2.0.0 Jeff On Sep 17, 2010, at 12:18 PM, Emmanuel Lecharny wrote: Hi, The last version of MINA (2.0.0) has been released ! Here are the complete release notes from JIRA: Bug * [DIRMINA-539 https://issues.apache.org/jira/browse/DIRMINA-539] - NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig * [DIRMINA-650 https://issues.apache.org/jira/browse/DIRMINA-650] - Mina server does not recieve all data sent by client using SSLSocketFactory * [DIRMINA-678 https://issues.apache.org/jira/browse/DIRMINA-678] - NioProcessor 100% CPU usage on Linux (epoll selector bug) * [DIRMINA-679 https://issues.apache.org/jira/browse/DIRMINA-679] - NullPointerException in ProtocolCodecFilter.filterWrite * [DIRMINA-684 https://issues.apache.org/jira/browse/DIRMINA-684] - NullPointerException when opening socket to localhost * [DIRMINA-711 https://issues.apache.org/jira/browse/DIRMINA-711] - Adding some logs in the chain make the MDCFilter tests to fail * [DIRMINA-720 https://issues.apache.org/jira/browse/DIRMINA-720] - Hardware Flow Control Disables Serial Port on Windows Platform * [DIRMINA-732 https://issues.apache.org/jira/browse/DIRMINA-732] - Session Idle events never comes in sessions managed by NioDatagramAcceptor * [DIRMINA-733 https://issues.apache.org/jira/browse/DIRMINA-733] - The profile method in the ProfilerTimerFilter can caused more methods to be profiled than intended. * [DIRMINA-742 https://issues.apache.org/jira/browse/DIRMINA-742] - When session is closed, DefaultIoFilterChain is in deadlock. * [DIRMINA-746 https://issues.apache.org/jira/browse/DIRMINA-746] - DefaultSocketSessionConfig.setReceiveBufferSize(...) throws NullPointerException * [DIRMINA-748 https://issues.apache.org/jira/browse/DIRMINA-748] - CachedBufferAllocator does not free buffers when maxCachedBufferSize=0 * [DIRMINA-749 https://issues.apache.org/jira/browse/DIRMINA-749] - Cannot have more than one CODEC in the chain * [DIRMINA-753 https://issues.apache.org/jira/browse/DIRMINA-753] - Some writes observed to stall until select times out * [DIRMINA-755 https://issues.apache.org/jira/browse/DIRMINA-755] - IoConnectot.dispose blocks forever * [DIRMINA-760 https://issues.apache.org/jira/browse/DIRMINA-760] - Client fails to detect disconnection * [DIRMINA-762 https://issues.apache.org/jira/browse/DIRMINA-762] - WARN org.apache.mina.core.service.IoProcessor - Create a new selector. Selected is 0, delta = 0 * [DIRMINA-763 https://issues.apache.org/jira/browse/DIRMINA-763] - Errors with Datagram when running tests on linux * [DIRMINA-764 https://issues.apache.org/jira/browse/DIRMINA-764] - DDOS possible in only a few seconds... * [DIRMINA-770 https://issues.apache.org/jira/browse/DIRMINA-770] - Remove all the new NullPointerException() * [DIRMINA-771 https://issues.apache.org/jira/browse/DIRMINA-771] - Calling NioSocketSession.toString() causes java.lang.Error * [DIRMINA-777 https://issues.apache.org/jira/browse/DIRMINA-777] - IoSessionConfig.setUseReadOperation(true) doesn't seem to work * [DIRMINA-778 https://issues.apache.org/jira/browse/DIRMINA-778] - TextLineDecoder not thread safe? * [DIRMINA-779 https://issues.apache.org/jira/browse/DIRMINA-779] - SSLHandler can re-order data that it reads * [DIRMINA-782 https://issues.apache.org/jira/browse/DIRMINA-782] - Combination of SslFilter FileRegionWriteFilter causes messageSent events to be lost * [DIRMINA-784 https://issues.apache.org/jira/browse/DIRMINA-784] - Error with MDCInjectionFilter on Windows Improvement * [DIRMINA-593 https://issues.apache.org/jira/browse/DIRMINA-593] - Javadoc documentation for org/apache/mina/filter/reqres * [DIRMINA-682 https://issues.apache.org/jira/browse/DIRMINA-682] - We need a better documentation for the ExecutorFilter [was :Writing more than one message will block until the MessageReceived as been fully proceced] * [DIRMINA-707 https://issues.apache.org/jira/browse/DIRMINA-707] - Add sendfile support to APR transport * [DIRMINA-751 https://issues.apache.org/jira/browse/DIRMINA-751] - IoBuffer.normalizeCapacity improvement * [DIRMINA-754 https://issues.apache.org/jira/browse/DIRMINA-754] - Javadoc omission in IoFilterChain#fireMessageSent() * [DIRMINA-761 https://issues.apache.org/jira/browse/DIRMINA-761] - how to shutdown a mina application * [DIRMINA-780 https://issues.apache.org/jira/browse/DIRMINA-780] - Writing null objects to the Session should raise an Exception Task * [DIRMINA-477 https://issues.apache.org/jira/browse/DIRMINA-477] - Update page about differences between 1.x and 2.x * [DIRMINA-575
Re: [VOTE] MINA 2.0.0 take 3 !
+1 Jeff On Sep 21, 2010, at 4:55 PM, Emmanuel Lecharny wrote: Hi, After Alain found that there were some missing ASL headers in the last released version, the latest vote has been reverted, and I just released MINA again (after having checked that we don't have any missing ASL.20 header - rat will of course complain because .settings files don't contain such headers. That also means we have to add .settings into svn:ignore for 2.0.1). So, let's resume : The last version of MINA (2.0.0) has been released for the third time :) ! Here are the complete release notes from JIRA: Bug * [DIRMINA-539 https://issues.apache.org/jira/browse/DIRMINA-539] - NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig * [DIRMINA-650 https://issues.apache.org/jira/browse/DIRMINA-650] - Mina server does not recieve all data sent by client using SSLSocketFactory * [DIRMINA-678 https://issues.apache.org/jira/browse/DIRMINA-678] - NioProcessor 100% CPU usage on Linux (epoll selector bug) * [DIRMINA-679 https://issues.apache.org/jira/browse/DIRMINA-679] - NullPointerException in ProtocolCodecFilter.filterWrite * [DIRMINA-684 https://issues.apache.org/jira/browse/DIRMINA-684] - NullPointerException when opening socket to localhost * [DIRMINA-711 https://issues.apache.org/jira/browse/DIRMINA-711] - Adding some logs in the chain make the MDCFilter tests to fail * [DIRMINA-720 https://issues.apache.org/jira/browse/DIRMINA-720] - Hardware Flow Control Disables Serial Port on Windows Platform * [DIRMINA-732 https://issues.apache.org/jira/browse/DIRMINA-732] - Session Idle events never comes in sessions managed by NioDatagramAcceptor * [DIRMINA-733 https://issues.apache.org/jira/browse/DIRMINA-733] - The profile method in the ProfilerTimerFilter can caused more methods to be profiled than intended. * [DIRMINA-742 https://issues.apache.org/jira/browse/DIRMINA-742] - When session is closed, DefaultIoFilterChain is in deadlock. * [DIRMINA-746 https://issues.apache.org/jira/browse/DIRMINA-746] - DefaultSocketSessionConfig.setReceiveBufferSize(...) throws NullPointerException * [DIRMINA-748 https://issues.apache.org/jira/browse/DIRMINA-748] - CachedBufferAllocator does not free buffers when maxCachedBufferSize=0 * [DIRMINA-749 https://issues.apache.org/jira/browse/DIRMINA-749] - Cannot have more than one CODEC in the chain * [DIRMINA-753 https://issues.apache.org/jira/browse/DIRMINA-753] - Some writes observed to stall until select times out * [DIRMINA-755 https://issues.apache.org/jira/browse/DIRMINA-755] - IoConnectot.dispose blocks forever * [DIRMINA-760 https://issues.apache.org/jira/browse/DIRMINA-760] - Client fails to detect disconnection * [DIRMINA-762 https://issues.apache.org/jira/browse/DIRMINA-762] - WARN org.apache.mina.core.service.IoProcessor - Create a new selector. Selected is 0, delta = 0 * [DIRMINA-763 https://issues.apache.org/jira/browse/DIRMINA-763] - Errors with Datagram when running tests on linux * [DIRMINA-764 https://issues.apache.org/jira/browse/DIRMINA-764] - DDOS possible in only a few seconds... * [DIRMINA-770 https://issues.apache.org/jira/browse/DIRMINA-770] - Remove all the new NullPointerException() * [DIRMINA-771 https://issues.apache.org/jira/browse/DIRMINA-771] - Calling NioSocketSession.toString() causes java.lang.Error * [DIRMINA-777 https://issues.apache.org/jira/browse/DIRMINA-777] - IoSessionConfig.setUseReadOperation(true) doesn't seem to work * [DIRMINA-778 https://issues.apache.org/jira/browse/DIRMINA-778] - TextLineDecoder not thread safe? * [DIRMINA-779 https://issues.apache.org/jira/browse/DIRMINA-779] - SSLHandler can re-order data that it reads * [DIRMINA-782 https://issues.apache.org/jira/browse/DIRMINA-782] - Combination of SslFilter FileRegionWriteFilter causes messageSent events to be lost * [DIRMINA-784 https://issues.apache.org/jira/browse/DIRMINA-784] - Error with MDCInjectionFilter on Windows Improvement * [DIRMINA-593 https://issues.apache.org/jira/browse/DIRMINA-593] - Javadoc documentation for org/apache/mina/filter/reqres * [DIRMINA-682 https://issues.apache.org/jira/browse/DIRMINA-682] - We need a better documentation for the ExecutorFilter [was :Writing more than one message will block until the MessageReceived as been fully proceced] * [DIRMINA-707 https://issues.apache.org/jira/browse/DIRMINA-707] - Add sendfile support to APR transport * [DIRMINA-751 https://issues.apache.org/jira/browse/DIRMINA-751] - IoBuffer.normalizeCapacity improvement * [DIRMINA-754 https://issues.apache.org/jira/browse/DIRMINA-754] - Javadoc omission in IoFilterChain#fireMessageSent() * [DIRMINA-761
Re: [VOTE] Release Apache FtpServer 1.0.5
+1 Jeff Sent from my iPhone On Sep 26, 2010, at 1:56 PM, Niklas Gustavsson nik...@protocol7.com wrote: Hi We've fixed quite a few bugs in FtpServer and I think we're ready for a new release. I've uploaded binaries at: https://repository.apache.org/content/repositories/orgapachemina-015/ These are based on the source here: https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.5/ The change log is here: https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/12314821 Let's vote: [ ] +1, release FtpServer 1.0.5 [ ] 0 [ ] -1, don't release because... /niklas
Re: [VOTE] Release Apache FtpServer 1.0.5, take 2
+1 Jeff On Sep 27, 2010, at 1:12 PM, Niklas Gustavsson wrote: Hi I've fixed the bug discovered by Sai and the license header reported by Emmanuel. New binaries at: https://repository.apache.org/content/repositories/orgapachemina-016 These are based on the source here: https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.5/ The change log is here: https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/12314821 Let's vote, again: [ ] +1, release FtpServer 1.0.5 [ ] 0 [ ] -1, don't release because... /niklas
Re: [VOTE] MINA 2.0.1
+1 Jeff On Oct 22, 2010, at 11:19 AM, Emmanuel Lecharny wrote: Hi, a serious regression has been found in MINA 2.0.0. It has been fixed in 2.0.1 and I suggest we vote a release. Here is the regression description : * [DIRMINA-803 https://issues.apache.org/jira/browse/DIRMINA-803] - ProtocolCodecFilter.filterWrite() is no longer thread-safe Here's the Jira link for this version if you'd like to review issues in more details: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10670styleName=Htmlversion=12313702 A temporary tag has been created (it can be removed if the vote is not approved): http://svn.apache.org/viewvc/mina/tags/2.0.1/ The svn revision is :http://svn.apache.org/viewvc?rev=1026395 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-002/ The distributions are available for download on : https://repository.apache.org/content/repositories/orgapachemina-004/org/apache/mina/mina-parent/2.0.1/ Let's vote again : [ ] +1 | Release MINA 2.0.1 [ ] ±0 | Abstain [ ] -1 | Do *NOT* release MINA 2.0.1 Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
