Re: XML Server example [DIRMINA-258]
Ashish, Did you ever post this code to the repository? Thanks, Mark On Wed, Dec 29, 2010 at 10:15 PM, Ashish paliwalash...@gmail.com wrote: On Thu, Dec 30, 2010 at 12:06 AM, Niklas Gustavsson nik...@protocol7.com wrote: On Wed, Dec 29, 2010 at 7:24 PM, Emmanuel Lécharny elecha...@apache.org wrote: great ! We have to make it an independent module in MINA then, because it's really the XML parser we want to use for any kind of XML based protocol in MINA ! Right, that would be easy enough. It's designed to be independent on Vysper. However, it currently only implements the limited subset of XML that XMPP uses. So, for generic XML usage, further development would be needed (like comments, doctype, PIs). I think it should be fine to start with :) users will have something to start with. Coming back to my dumb question, about adding an XML example along with MINA examples. I see two ways 1. Implement a codec (fork from Vysper and refine) and use it in the example. 2. Provide a simple example and continue to work on #1 I see no harm in providing an example with 2.0.X series and have more robust codec in 3.0. - ashish
Re: MIBA 2.0.0 : what's next ?
I assume the API will be backwards compatible though, right? On Tue, Sep 28, 2010 at 7:38 PM, Emmanuel Lécharny elecha...@apache.org wrote: On 9/28/10 4:36 PM, Alex Karasulu wrote: I'm afraid that MINA 3.0 will be a total rewrite, with no way to get fixes from 2.0... I consider 2.0 as dead wood at this point. Hahaha is this a reference to the crusty Norwegian Wood codename that someone gave it a while back? Not even close to that ! It's just a coincidence... Regardless yeah sounds like it. No worries then. But why bother forking a branch instead just move the current 2.0 trunk to 2.0 branch and start writing fresh new code? We already have a 2.0 branch. May be we will remove what we have in trunk and move the 3.0 branch to trunk, now that the 2.0.1 branch has been created. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: MIBA 2.0.0 : what's next ?
+1, create a mina-2.0.x branch and let trunk be 3.0. Also, what about all current bugs/feature requests in JIRA, should we move them to 3.0? I see that there a a bunch of JIRA entries currently in as 2.0.1, but should we make sure that they should be 2.0.1 and not 3.0? ...just my $.02 On Mon, Sep 27, 2010 at 11:37 AM, Emmanuel Lecharny elecha...@gmail.com wrote: Hi guys, now that we got this damn release done, what will we do next ? There are many things we still have to take care of : - the MINA new site is still pending, waiting for some love (http://mina.apache.org/mina2/) - the doco is also lagging a lot, and we may want to improve it - more important, IMO, is the next version. Should we create an branch for 2.0.1 immediately, and let trunk be 3.0 ? wdyt ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [VOTE] MINA 2.0.0 take 3 !
+1 On Wed, Sep 22, 2010 at 8:21 AM, Maarten Bosteels mbosteels@gmail.com wrote: +1 Maarten On Wed, Sep 22, 2010 at 9:52 AM, Emmanuel Lecharny elecha...@gmail.comwrote: [X] +1 | Release MINA 2.0.0 my vote, btw. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3.0] Some thoughts on Debug tool
I am all for using JMX. I have used JMX in a few MINA-based applications to gather performance numbers and worked out really well. On Thu, Aug 19, 2010 at 9:41 AM, Ashish paliwalash...@gmail.com wrote: Guys, I just added some thoughts on the Debug tool on MINA 3.0 design page (https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design). Ideas are better on wiki than in my mind. JMX would be the best way to get the data from running App, as we shall be able to extract more data from running JVM. On the initial thoughts, we can capture Statistical and Configuration information in the tool, which shall help see the system in action. Few items indentified are Configuration - (Probably would be good if we can allow change in config from the same UI as well as expose JMX API's) Chain Config Acceptor Selector Strategy ?? Stats Session's Session data Heaps Usage ??? I believe our users can provide more info on what might help them better manage/debug their systems. Thoughts/Comments/Suggestion? thanks ashish
[jira] Commented: (DIRMINA-258) Example of an XML server and Client.
[ https://issues.apache.org/jira/browse/DIRMINA-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12802665#action_12802665 ] Mark Webb commented on DIRMINA-258: --- I think handing this off to Ashish might be a good idea. He seems to know what we need and since he is asking I have no problems handing it off. Example of an XML server and Client. Key: DIRMINA-258 URL: https://issues.apache.org/jira/browse/DIRMINA-258 Project: MINA Issue Type: New Feature Reporter: Martin Helmhout Assignee: Mark Webb Priority: Minor Attachments: MINA_XMLServer.zip, MINA_XMLServer.zip, XMLserver095.zip The attachment contains an example of an XML Server + client and should help start people building their server quickly. Because an XML server was not in the examples, I created quickly something for myself, but want others to also get the fruits and make them better if possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Bug, need to perform action after socket bind, but before connection attempt for AbstractPollingIoConnector
I have the patches and will handle the JIRA entry. --Mark On Tue, Jun 23, 2009 at 9:35 AM, Emmanuel Lecharnyelecha...@apache.org wrote: Dauch, Kevin - AES wrote: I'm setting up a connection using an ephemeral port to from X to Y, but before the connection is attempted I need to know the port that has been assigned after the bind operation, but before the connection is attempted. Attached is a solution to the problem. Hi Kevin, attachments don't make it through the mailing list (Antispam policy in action :/ ). Can you create a JIRA and attach the patch ? Thanks ! Kevin Dauch Software Engineer kevin.da...@itt.commailto:kevin.da...@itt.com | dir + 315.838.7164 ITT AES | 474 Phoenix Drive | Rome, NY 13441 This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Feature request, need to perform action after socket bind, but before connection attempt for AbstractPollingIoConnector
Kevin, Your best bet would be to submit a bug and then post the patch, or code. It will probably not go in to the 2.0 baseline, but will certainly be considered for the 3.0 baseline. On Wed, Jun 17, 2009 at 12:56 PM, Dauch, Kevin - AESkevin.da...@itt.com wrote: I'm setting up a connection using an ephemeral port to from X to Y, but before the connection is attempted I need to know the port that has been assigned after the bind operation, but before the connection is attempted. I created an interface PostBindInitializer that is called after the bind but before connection is attempted in AbstractPollingIoConnector.connect0(). I've coded it and can submit the added code + changes for the community to review. Kevin Dauch Software Engineer kevin.da...@itt.commailto:kevin.da...@itt.com | dir + 315.838.7164 ITT AES | 474 Phoenix Drive | Rome, NY 13441 This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
Re: [MINA 3.0] Preliminary thoughts.
Between work and school, I have been really busy. I have been keeping up with the mailing list, but not doing much with the code. Things are starting to shake loose for me, so I will be able to jump back in now. What do you see as the major roadblocks to releasing 2.0? On Fri, Jun 12, 2009 at 3:34 AM, Emmanuel Lecharnyelecha...@apache.org wrote: Mark Webb wrote: What are the plans for release of 2.0 and the migration to a 3.0 development? Is anyone prototyping any of these ideas in sandboxes? Hi Mark, those are just random thoughts I put down on the site after having posted them to the list. I wrote them during my long commute from house to my client's office. Right now, there is nothing started, except a few experiment in some branches (https://svn.apache.org/repos/asf/mina/branches/mina-new-chain2 ) done a few months ago. The main target is still to get MINA 2.0 out asap, and it takes forever, because a few peeps are working on it, something I can understand. MINA 2.0 code is far from being perfect, and it's not very funny to try to fix bugs in it, as the inner documentation is pretty sparse, and you have to double guess what some portion of the code is supposed to do before trying to fix it. My idea, when I posted this 3.0 mail, was to try to get more excitation from all of the people musing around MINA. It's always fun to start a new version, and it's most certainly useful to see what people have in mind, instead of going forward, code and commit. It will take a couple of months before MINA 2.0 will be released (after a couple of RC), and I think we are close to the final version. Seems to be good timing to start thinking seriously about MINA 3.0 ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [MINA 3.0] Preliminary thoughts.
What are the plans for release of 2.0 and the migration to a 3.0 development? Is anyone prototyping any of these ideas in sandboxes? On Thu, Jun 11, 2009 at 7:55 AM, Emmanuel Lecharnyelecha...@apache.org wrote: I have created a Wiki page containing this discussion : http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design Julien Vermillard wrote: Hi, reply inline Le Wed, 10 Jun 2009 21:37:10 +0200, Emmanuel Lecharny elecha...@apache.org a écrit : Hi guys, as I'm commuting every day for a long distance, I have had time to think about what I would see in MINA 3.0. Here is the result of my random thoughts And not see anymore ;) Mina 3.0 design and expected features - - selectors usage We should be able to define the number of selectors to use, and to define what they will be used for. For instance, atm, we have a selector in the Acceptor, plus a selector per Processor. This is not necessarily the best solution. * do some perf tests to see if it's better to use one or many selectors. * decouple the selector usage from the the selector definition. It should be possible to define one single selector and use it in many places * the Acceptor and Processor should not necessarily be associated with a thread. it's up to the user to define the thread model to use Actually look like we need different strategy for different usage. On the right threading/selector strategy look like there is no real consensus and we will need to experiment for finding the default solution. - Chain The current chain implemention is cumbersome. We would like to have something easier to manipluate, and also easier to debug. * the chain should be optionally dynamic : a session can add a new filter in the chain whenever needed * we should not always copy the chain in each session, if the chain is immutable Yes, cause most of time we configure the chain on the acceptor and never change it again. Look like we agreed on copy-on-write for that. * however, it should be possible to change the global chain without breaking the processing. * we should have one chain for incoming messages, and another one for outgoing messages * it should be possible to have a multi-stage codec (ie, add more than one codec filter in the chain) Mandatory, it's very often I use a TextLineCodec and a String-to-Pojo filter, and I'm sure I'm not alone. * we should allow a queuing mechanism to be put in between each filters What is that for ? Look like you got a new idea :) * the Head and Tail filters are useless : they should be removed Yes * a chain may not be a list of filters. It can be a graph If we can keep the API simple enough, why not. - Filters * a filter should accept a streamObject, the Object can change from one filter to another. it's up to the user to correctly handle the Object. You want to say multi layer codec ? * the executor filter could be present in moe than one place in the chain (SEDA) Mandatory if someone really want SEDA. * statistic must be established with a filter Again mandatory. You won't do stats the same way on HTTP or FTP and stats can be very costy. * we should define two interfaces for filters : IngoingFilter and OutgoingFilter. They will expose the methods to process ingoing and outgoing messages The question is where to put sessionOpen/Closed/Idle in a two chains model. - Session * we should have two kind of sessions : statefull and stateless. Sometime, we don't need to store any kind of information in a session If we create the HashMap on first additon, where is the gain ? * we should add a sessionManager instead of all the existing queues used to manage the dead sessions, the idle sessions, etc. We need to rethink the whole separation between IoProcessor and IoService and where we manage closing/accepting queues. * session should not necessarily be associated with a processor. +1 * If a session is statefull, then we should attach the data to the channel instead of creating a map for that Can you say more about that, where is the gain ? * A session must be attached to an acceptor, allowing more than one chain if the acceptor is to deal with more than one single SocketServer We need to find away for running more than 1 kind of port/protocol with the same set of Thread/Executors. I suppose it would be interesting for ADS. On my side I run servers with 3 or 4 SocketAcceptors for different protocols, somthing like 10 SocketConnectors for different protocols. Perfs aren't an issue for me actually, be it can change. - codec * we don't have stateful or stateless codecs. We should distinguish the two kinds of codec someone can use. +1 * we should efine a collection of existing codecs For that we need a standard way of doing a codec on the Pojo side. I'm sure LDAP pjo oof ADs are very different
Re: [VOTE] Release MINA 2.0.0-M6
[X] +1: Yes, release MINA-2.0.0-M6 On Tue, May 26, 2009 at 9:08 AM, Emmanuel Lecharny elecha...@apache.org wrote: Hi, it was expected to be available last week, sorry for the delay. Here is an official vote for a 2.0.0-M6 mina release, which fixes a few but serious issues, including one major regression I injected in the code. The code has been moved to a branch, on revision 778682 : http://svn.apache.org/viewvc/mina/branches/mina-2.0.0-M6/ I didn't produced any package, as the mavn assembly plugin is deeply bugged (http://mail-archives.apache.org/mod_mbox/maven-users/200709.mbox/%3c9ab4ff82-4097-4391-b1dc-9c7a7217d...@commonjava.org%3e) [ ] +1 : Yes, release MINA-2.0.0-M6 [ ] +/- 0 : I don't have any opinion [ ] -1 : No, it's not ready Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]
#4 is the best.. On Fri, Apr 17, 2009 at 8:55 AM, Michael Jakl jakl.mich...@gmail.com wrote: On Fri, Apr 17, 2009 at 14:21, Edouard De Oliveira doe_wan...@yahoo.fr wrote: i do agree if some remainder to mina is a wish maybe combining the V feathers with mina logo (replacing the mina text with Vysper) is the way Good point! Here a few ideas based on the Mina logo: http://stuff.interlinked.org/VysperLogos/mina_vysper.png (first try, click on your own risk :)) http://stuff.interlinked.org/VysperLogos/mina_vysper2.png http://stuff.interlinked.org/VysperLogos/mina_vysper3.png http://stuff.interlinked.org/VysperLogos/mina_vysper4.png (like 3 but with shadows) Cheers, Michael
Re: [VOTE] Vysper as MINA subproject
+1 On Sun, Apr 12, 2009 at 1:34 PM, Niklas Gustavsson nik...@protocol7.com wrote: On Sun, Apr 12, 2009 at 10:32 AM, Julien Vermillard jvermill...@archean.fr wrote: [X] +1 Yes, accept Vysper as a sub-project /niklas
Re: [DISCUSS] Moving Vysper lab to MINA as a sub-product
I think its a great idea!! +1 On Wed, Apr 8, 2009 at 1:09 PM, Ashish paliwalash...@gmail.com wrote: What's the final take on Vysper as a subproject? - ashish
MINA 3.0
I see that there are JIRA entries for MINA 3.0. Is there a branch for this yet, or are we still using the trunk for that? Sorry, I've been away for a while. New job and grad school are taking up alot of time. --Mark
twitter and MINA
Found this on reddit. Thought you all might find this interesting. http://github.com/robey/kestrel/tree/master Looks like their message queue system is written using Scala and uses MINA. really cool!!
Re: Road to RC1
I agree with Ashish. We should move the 1.0 information from the front main page On Tue, Jan 27, 2009 at 12:49 AM, Ashish paliwalash...@gmail.com wrote: On Mon, Jan 26, 2009 at 4:06 PM, Emmanuel Lecharny elecha...@gmail.com wrote: On Sat, Jan 24, 2009 at 1:07 PM, Julien Vermillard jvermill...@archean.fr wrote: Hi, Looks like we are near to RC1, mostly doc issues remaining : https://issues.apache.org/jira/browse/DIRMINA/fixforversion/12313160 For me the most important are : - reqres filter which is totally javadocless - documentation on how to setup and use APR transport (I'll do it) - update website (Ashish is doing a great job here) Do you see any other important issues ? I think it would be nice if we can have a GA or an RC of MINA2 for Apachecon EU. Julien We also have to check JIRA and clean it (ie, either postpone issues or fix them). The web-site is to me the most importing thing to clean : it's a mix up of 1.0 and 2.0 documentation, leading our users to confusion. Do we really need 1.0 stuff? means on the front page. It gives an impression that we are developing parallel on both :-( Lets all take a while and browse the pages and create a page which list all the pages that need to be updated for 2.0 (something similar was done for ApacheDS for i18 of messages). Shall be easy for all to contribute. IMHO, we are not too far from a RC1. May be a matter of one or two weeks, assuming we all have a little time to work on it ;) Thanks !
Re: serveral questions
My guess would be that an IOException or maybe another related exception would occur because MINA could not write the data. Depending on your filter chain, you may get an OOM error. On Wed, Dec 24, 2008 at 4:36 AM, Steve Johns steven.mark.jo...@gmail.com wrote: Can everyone answer my first question?Thanks. On Mon, Dec 15, 2008 at 7:40 PM, Ashish paliwalash...@gmail.com wrote: Not sure for 1.1.7, but here is what I can tell you from 2.0 Please NOTE that these may not be the accurate answers. On Sun, Dec 14, 2008 at 1:43 PM, Steve Johns steven.mark.jo...@gmail.com wrote: Hi I have several quesions about MINA.I am using mina1.1.7. 1)If server doesn't detect the session close signal and server keeps sending large amount of message to that session.What will happen?OOM? No Clue 2)How does MINA manage the internal queue for incoming and outcoming messages?Is there anyway to control these queue size? For Queue Size, don't think we can control the size, as this is the construct used private final BlockingQueueIoSession waitingSessions = new LinkedBlockingQueueIoSession(); Using a different constructor we could have specified the size 3)Adding the ExecutorFilter after decoder and encoder filter will cause message receive no in order? Checkout Event Ordering details at http://mina.apache.org/report/trunk/xref/org/apache/mina/filter/executor/ExecutorFilter.html AFAIK, for an IoSession using OrderedThreadPool, it shall maintain the sequence Thanks.
[jira] Commented: (DIRMINA-586) Dynamic delimiter support for TextLineCodecFactory
[ https://issues.apache.org/jira/browse/DIRMINA-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12658598#action_12658598 ] Mark Webb commented on DIRMINA-586: --- I vote to close it. If we have functionality to solve the request, then it should be closed. Dynamic delimiter support for TextLineCodecFactory -- Key: DIRMINA-586 URL: https://issues.apache.org/jira/browse/DIRMINA-586 Project: MINA Issue Type: Improvement Components: Filter Affects Versions: 2.0.0-M1 Reporter: Trustin Lee Priority: Minor Fix For: 2.0.0-RC1 TextLineCodecFactory supports static delimiters only. For some cases, users need to switch the delimiter dynamically depending on context. Related discussion is found here: http://markmail.org/message/loiqoej35evt2yvv -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
asyncweb - cannot add 2 HttpServiceFilters to 1 ServiceContainer
I am trying to add 2 service filters to a service container. I am using an instance of BasicServiceContainer and adding two instances of HttpServiceHandler to the service container. I can only get responses from the first service handler that I add to the service container. Is this how its supposed to work? Looking at BasicServiceContainer, the service handlers are added to a List, so I assume that multiple handlers can be added to a container. Thanks for any help you may have. Mark
Re: asyncweb - cannot add 2 HttpServiceFilters to 1 ServiceContainer
Figured it out. The HttpServiceHandler class will send a 404 message if the handler's resolver does not match a request. I thought that it should just pass the request to the next filter via the call to next.invoke(); I just wrote my own handler to just pass the request along the chain if the request does not match. --Mark On Wed, Dec 10, 2008 at 3:10 PM, Mark Webb [EMAIL PROTECTED] wrote: I am trying to add 2 service filters to a service container. I am using an instance of BasicServiceContainer and adding two instances of HttpServiceHandler to the service container. I can only get responses from the first service handler that I add to the service container. Is this how its supposed to work? Looking at BasicServiceContainer, the service handlers are added to a List, so I assume that multiple handlers can be added to a container. Thanks for any help you may have. Mark
Re: [SSHD] Other resources needed ?
If we have them for other sub-projects we should have one for SSHD. On Fri, Dec 5, 2008 at 11:29 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, what about requesting some specific mailing list for SSHD (and for AsyncWeb too) at least for users ? Also we need to add MINA to the Export Matrix (http://apache.org/dev/crypto.html) as we are using some crypto now. Anyone ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
What was the result of this? Is the integration being done? On Thu, Nov 20, 2008 at 12:29 PM, Jeff Genender [EMAIL PROTECTED] wrote: +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] Create a MINA subproject to implement a SSH server based on Mina
Not a problem. On Thu, Dec 4, 2008 at 11:05 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: What was the result of this? Is the integration being done? Ooopps... Seems like I forgot to close the vote. My bad ! So here are the results : 7 +1 binding votes, 5 +1 non binding votes So it's a go. I will inform Guillaume about this, and grant him commit access to MINA. Sorry for the delay ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: svn commit: r723396 [1/12] - in /mina/sshd/trunk: ./ src/ src/docs/ src/main/ src/main/filtered-resources/ src/main/filtered-resources/org/ src/main/filtered-resources/org/apache/ src/main/filtere
Awesome. I am really looking forward to playing with this. One note, you may want to change the java package to org.apache.mina.sshd. More of an opinion of mine, but not sure if there are any guidelines on this. Thanks Mark On Thu, Dec 4, 2008 at 1:59 PM, [EMAIL PROTECTED] wrote: Author: gnodet Date: Thu Dec 4 10:59:31 2008 New Revision: 723396 URL: http://svn.apache.org/viewvc?rev=723396view=rev Log: Commit code from the google project, refactored into org.apache.sshd package Added: mina/sshd/trunk/LICENSE.txt mina/sshd/trunk/NOTICE.txt mina/sshd/trunk/pom.xml mina/sshd/trunk/src/ mina/sshd/trunk/src/docs/ mina/sshd/trunk/src/docs/draft-ietf-secsh-filexfer-13.txt mina/sshd/trunk/src/docs/rfc4251.txt mina/sshd/trunk/src/docs/rfc4252.txt mina/sshd/trunk/src/docs/rfc4253.txt mina/sshd/trunk/src/docs/rfc4254.txt mina/sshd/trunk/src/docs/rfc4255.txt mina/sshd/trunk/src/docs/rfc4256.txt mina/sshd/trunk/src/docs/rfc4419.txt mina/sshd/trunk/src/main/ mina/sshd/trunk/src/main/filtered-resources/ mina/sshd/trunk/src/main/filtered-resources/org/ mina/sshd/trunk/src/main/filtered-resources/org/apache/ mina/sshd/trunk/src/main/filtered-resources/org/apache/sshd/ mina/sshd/trunk/src/main/filtered-resources/org/apache/sshd/sshd-version.properties mina/sshd/trunk/src/main/java/ mina/sshd/trunk/src/main/java/org/ mina/sshd/trunk/src/main/java/org/apache/ mina/sshd/trunk/src/main/java/org/apache/sshd/ mina/sshd/trunk/src/main/java/org/apache/sshd/ClientChannel.java mina/sshd/trunk/src/main/java/org/apache/sshd/ClientSession.java mina/sshd/trunk/src/main/java/org/apache/sshd/SshClient.java mina/sshd/trunk/src/main/java/org/apache/sshd/SshServer.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/UserAuth.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/auth/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/auth/UserAuthPassword.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/AbstractClientChannel.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/ChannelSession.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/ChannelShell.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/AbstractDHGClient.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/DHG1.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/DHG14.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/session/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/session/ClientSessionImpl.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/ mina/sshd/trunk/src/main/java/org/apache/sshd/common/AbstractFactoryManager.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/AbstractSessionIoHandler.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Channel.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Cipher.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Compression.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Digest.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/FactoryManager.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/KeyExchange.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/KeyPairProvider.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Mac.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/NamedFactory.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Random.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Signature.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/SshConstants.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/SshException.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/AbstractChannel.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ChannelOutputStream.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ChannelPipedInputStream.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ChannelPipedOutputStream.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/Window.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/ mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/AES128CBC.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/AES192CBC.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/AES256CBC.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/BaseCipher.java
Re: svn commit: r723396 [1/12] - in /mina/sshd/trunk: ./ src/ src/docs/ src/main/ src/main/filtered-resources/ src/main/filtered-resources/org/ src/main/filtered-resources/org/apache/ src/main/filtere
ok. no problem On Thu, Dec 4, 2008 at 5:05 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: Awesome. I am really looking forward to playing with this. One note, you may want to change the java package to org.apache.mina.sshd. More of an opinion of mine, but not sure if there are any guidelines on this. Currently, asyncweb and ftpserver use org.apache.asyncweb and org.apache.ftpserver. I'm not sure that we should do differentely for sshd ... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vote] Release MINA 2.0.0-M4
[X] +1, let's release 2.0.0-M4 and freeze the API On Thu, Dec 4, 2008 at 7:50 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: And here is my vote : [X] +1, let's release 2.0.0-M4 and freeze the API -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Asyncweb error
I am working on writing a simple web server application using the asyncweb library. I am getting the following error. I am using Google Chrome to test the server. I do get the proper response in the browser but I also see this exception in the output of the server. java.lang.IllegalArgumentException: No enum const class org.apache.asyncweb.common.HttpMethod. at java.lang.Enum.valueOf(Enum.java:192) at org.apache.asyncweb.common.HttpMethod.valueOf(HttpMethod.java:1) at org.apache.asyncweb.common.codec.HttpRequestLineDecodingState$1.finishDecode(HttpRequestLineDecodingState.java:66) at org.apache.mina.filter.codec.statemachine.ConsumeToDynamicTerminatorDecodingState.finishDecode(ConsumeToDynamicTerminatorDecodingState.java:103) at org.apache.mina.filter.codec.statemachine.DecodingStateMachine.finishDecode(DecodingStateMachine.java:151) at org.apache.mina.filter.codec.statemachine.DecodingStateMachine.finishDecode(DecodingStateMachine.java:151) at org.apache.mina.filter.codec.statemachine.DecodingStateProtocolDecoder.finishDecode(DecodingStateProtocolDecoder.java:100) at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed(ProtocolCodecFilter.java:258) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:378) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:49) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:817) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:87) at org.apache.mina.filter.logging.MdcInjectionFilter.filter(MdcInjectionFilter.java:137) at org.apache.mina.filter.util.CommonEventFilter.sessionClosed(CommonEventFilter.java:55) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:378) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:49) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:817) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:87) at org.apache.mina.core.session.IoEvent.run(IoEvent.java:64) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:551) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:543) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:487) at java.lang.Thread.run(Thread.java:619) [13:50:47] DEBUG [DecodingStateMachine ] Ignoring the exception caused by a closed session. java.lang.IndexOutOfBoundsException: Index: 1, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at org.apache.asyncweb.common.codec.HttpRequestDecodingStateMachine$2.finishDecode(HttpRequestDecodingStateMachine.java:97) at org.apache.mina.filter.codec.statemachine.DecodingStateMachine.finishDecode(DecodingStateMachine.java:168) at org.apache.mina.filter.codec.statemachine.DecodingStateMachine.finishDecode(DecodingStateMachine.java:151) at org.apache.mina.filter.codec.statemachine.DecodingStateProtocolDecoder.finishDecode(DecodingStateProtocolDecoder.java:100) at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed(ProtocolCodecFilter.java:258) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:378) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:49) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:817) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:87) at org.apache.mina.filter.logging.MdcInjectionFilter.filter(MdcInjectionFilter.java:137) at org.apache.mina.filter.util.CommonEventFilter.sessionClosed(CommonEventFilter.java:55) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:378) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:49) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:817) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:87) at org.apache.mina.core.session.IoEvent.run(IoEvent.java:64) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:551) at
Re: Asyncweb error
Here is what the browser prints out. I am now using the listener example and getting the same exception. -- You sent these headers with your request: Accept = text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset = ISO-8859-1,*,utf-8 Accept-Encoding = gzip,deflate,bzip2,sdch Accept-Language = en-US,en Connection = Keep-Alive Host = localhost:9012 User-Agent = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/0.4.154.29 Safari/525.19 X-SDCH = Chrome 0.4.154.29 -- On Wed, Dec 3, 2008 at 2:29 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: I am working on writing a simple web server application using the asyncweb library. I am getting the following error. I am using Google Chrome to test the server. I do get the proper response in the browser but I also see this exception in the output of the server. What is the request the server is receiving ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Asyncweb error
hrmm... Shouldn't it be a GET? I am just typing in the URL and pressing the enter key. I tried Internet Exploder and Google Chrome and got the same results. On Wed, Dec 3, 2008 at 2:41 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: Here is what the browser prints out. I am now using the listener example and getting the same exception. -- You sent these headers with your request: Accept = text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset = ISO-8859-1,*,utf-8 Accept-Encoding = gzip,deflate,bzip2,sdch Accept-Language = en-US,en Connection = Keep-Alive Host = localhost:9012 User-Agent = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/0.4.154.29 Safari/525.19 X-SDCH = Chrome 0.4.154.29 -- from the stack trace you posted, the error is due to a wrong http method (it should be OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE or CONNECT). What is the method you are using ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Asyncweb error
Just tried Firefox and saw the exception. On Wed, Dec 3, 2008 at 2:46 PM, Mark Webb [EMAIL PROTECTED] wrote: hrmm... Shouldn't it be a GET? I am just typing in the URL and pressing the enter key. I tried Internet Exploder and Google Chrome and got the same results. On Wed, Dec 3, 2008 at 2:41 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: Here is what the browser prints out. I am now using the listener example and getting the same exception. -- You sent these headers with your request: Accept = text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset = ISO-8859-1,*,utf-8 Accept-Encoding = gzip,deflate,bzip2,sdch Accept-Language = en-US,en Connection = Keep-Alive Host = localhost:9012 User-Agent = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/0.4.154.29 Safari/525.19 X-SDCH = Chrome 0.4.154.29 -- from the stack trace you posted, the error is due to a wrong http method (it should be OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE or CONNECT). What is the method you are using ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Asyncweb error
I am seeing the same error with wget as well. I think I have narrowed down the problem. In the class HttpRequestLineDecodingState line 67 you have an IoBuffer that represents the request. There is then the following line of code: HttpMethod method = HttpMethod.valueOf(product.getString(asciiDecoder)); When I print out the variable product using a hex dumper, I get the following: : 47 45 54 20 2F 72 73 73 20 48 54 54 50 2F 31 2E GET /rss HTTP/1. 0010: 30 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 57 0..User-Agent: W 0020: 67 65 74 2F 31 2E 31 31 2E 33 0D 0A 41 63 63 65 get/1.11.3..Acce 0030: 70 74 3A 20 2A 2F 2A 0D 0A 48 6F 73 74 3A 20 6C pt: */*..Host: l 0040: 6F 63 61 6C 68 6F 73 74 3A 39 30 31 32 0D 0A 43 ocalhost:9012..C 0050: 6F 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 65 70 2D onnection: Keep- 0060: 41 6C 69 76 65 0D 0A 0D 0A 00 00 00 00 00 00 00 Alive... 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The rest is all zero and the buffer is 2048 bytes. I might be off on this, but I am not sure we want to pass in a 2048 byte IoBuffer to valueOf in order to get a result back. --Mark On Wed, Dec 3, 2008 at 2:50 PM, Mark Webb [EMAIL PROTECTED] wrote: Just tried Firefox and saw the exception. On Wed, Dec 3, 2008 at 2:46 PM, Mark Webb [EMAIL PROTECTED] wrote: hrmm... Shouldn't it be a GET? I am just typing in the URL and pressing the enter key. I tried Internet Exploder and Google Chrome and got the same results. On Wed, Dec 3, 2008 at 2:41 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: Here is what the browser prints out. I am now using the listener example and getting the same exception. -- You sent these headers with your request: Accept = text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset = ISO-8859-1,*,utf-8 Accept-Encoding = gzip,deflate,bzip2,sdch Accept-Language = en-US,en Connection = Keep-Alive Host = localhost:9012 User-Agent = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/0.4.154.29 Safari/525.19 X-SDCH = Chrome 0.4.154.29 -- from the stack trace you posted, the error is due to a wrong http method (it should be OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE or CONNECT). What is the method you are using ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: 2.0-RC1 road to success ...
What I meant was, do we have pop/imap and smtp access using our apache.org accounts. Can I set up thunderbird to send/receive mail? This is just something that I did not set up but might now be interested in doing. On Sun, Nov 23, 2008 at 7:23 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: Don't committers have apache.org email accounts? I never set mine up. Where can I go to get directions on that? You can commit with your apache.org email, which is mwebb at apache dot org as requested one year and a half ago. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: 2.0-RC1 road to success ...
Thanks for the info. You certainly don't have to sell me on gmail, I have been using it for years and think its the best. On Sun, Nov 23, 2008 at 7:44 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: What I meant was, do we have pop/imap and smtp access using our apache.org accounts. Can I set up thunderbird to send/receive mail? AFAIR, you can forward any mail you receive to mwebb at a.o to another mail account by updating your .forward on your people.a.o/mwebb home directory. Apache does not setup a mailbox for your account. You have some instruction here : http://www.apache.org/dev/user-email.html FYI, I usually redirect everything to gmail, just because they have a bloody good anti-spam system (and I must say I do that for all my incoming mails : I forward all of them to gmail, and thunderbird is reading them from gmail. Two big advantages : - less spam - and I have a web access to my mail. However, on big cons : I depend on google who now has a total access to my private data...) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Commented: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649786#action_12649786 ] Mark Webb commented on DIRMINA-489: --- The code submitted by David Lloyd has been placed in the baseline. Unless there are problems, this should be closed. Composite IoBuffer -- Key: DIRMINA-489 URL: https://issues.apache.org/jira/browse/DIRMINA-489 Project: MINA Issue Type: New Feature Components: Core Reporter: David M. Lloyd Assignee: Mark Webb Fix For: 3.0.0-M1 Attachments: mina-composite-20080515.patch.gz, mina-composite-20080517.patch, mina-composite-20080521-2.patch, mina-composite-20080521.patch, mina-composite-20080723-1.patch, mina-composite-20080723-2.patch Provide a way to create a large IoBuffer from several smaller IoBuffers, without copying the underlying data. It would probably be acceptable to constrain the composite buffer in various ways, for example by disallowing autoexpanding or otherwise changing the capacity, the implementation could be greatly simplified. The goal is to be able to process large messages with a minimum of copying. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649891#action_12649891 ] Mark Webb commented on DIRMINA-489: --- Fine by me. Composite IoBuffer -- Key: DIRMINA-489 URL: https://issues.apache.org/jira/browse/DIRMINA-489 Project: MINA Issue Type: New Feature Components: Core Reporter: David M. Lloyd Assignee: Mark Webb Fix For: 3.0.0-M1 Attachments: mina-composite-20080515.patch.gz, mina-composite-20080517.patch, mina-composite-20080521-2.patch, mina-composite-20080521.patch, mina-composite-20080723-1.patch, mina-composite-20080723-2.patch Provide a way to create a large IoBuffer from several smaller IoBuffers, without copying the underlying data. It would probably be acceptable to constrain the composite buffer in various ways, for example by disallowing autoexpanding or otherwise changing the capacity, the implementation could be greatly simplified. The goal is to be able to process large messages with a minimum of copying. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: mina as a load balancer
Thanks. I am going to give it a try and see what happens. --Mark On Thu, Nov 13, 2008 at 5:29 AM, Ashish [EMAIL PROTECTED] wrote: not exactly as as load balancer, but did tried my hands on processing messages in fault tolerant mode :-) no concrete results yet On Thu, Nov 13, 2008 at 12:36 AM, Mark Webb [EMAIL PROTECTED] wrote: Has anyone ever looked into this? -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [PROPOSAL] Create a MINA subproject to implement a SSH server based on Mina
+1 On Thu, Nov 13, 2008 at 9:35 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Guillaume Nodet 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. Sounds a pretty interesting project. I think that MINA already hosts AsyncWeb, FtpServer, having a ssh server fits pretty well IMHO. So you have my +1 ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : [VOTE] Merging some simplifications
simple is all I understand. +1 On Wed, Nov 12, 2008 at 11:36 AM, Edouard De Oliveira [EMAIL PROTECTED] wrote: +1 for merging Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php De : Julien Vermillard [EMAIL PROTECTED] À : dev@mina.apache.org Envoyé le : Mercredi, 12 Novembre 2008, 10h22mn 28s Objet : [VOTE] Merging some simplifications Hi, Since it's cutting some feature, I would like a vote before merging my branch from sandbox to trunk. The branch : http://svn.apache.org/repos/asf/mina/sandbox/jvermillard/mina-cleaning/ The list of changes : http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fmina%2Fsandbox%2Fjvermillard%2Fmina-cleaning * Removed IoService idle event, you still have IoSession idle. * Reworked IdleStatusChecker for make the code easier to understand. * Removed setTrafficMask and keeped suspendWrite / suspendRead methods. * Removed trafficMask event from the IoFilter chain. * Applied http://issues.apache.org/jira/browse/DIRMINA-620 by removing superfluous IoSession close() methods. When you close a session, you need to use session.close(boolean); and say explicitly if you want to flush the write queue or no. [ ]: +1, Merge to trunk [ ]: 0, Abstain [ ]: -1, Don't merge Julien
mina as a load balancer
Has anyone ever looked into this?
Re: [MINA 2 new chain] Some feedback
I might need some beers just to cure the headache I get from looking at that stack trace. I agree that the +1 is ugly and the ChainIterator is a much better solution. Would a queue work in this situation? --Mark On Mon, Nov 10, 2008 at 8:56 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, I'm still doing some experiment with the new chain (in mina-new-chain2 branch). It's not totally satisfactory, mainly for two reasons : - I have used a List to store the filters, so I have to propagate an integer index to jump from one filter to another. This is a bit ugly, as you have inex+1 all over the code. I will move to what was suggested by Steve Ulrich (passing a ChainIterator instead of an index will mask the ugly +1). - The current MINA code is so damn complex that it makes it an order of magnitude more complicated to fix than to rewrite it, but this is not something I want to jump in, yet. As an example, here is the stack you get when you receive a message and send back a response (just for you to realize how insane is the current code ...). And we only have three filters : mdc, codec and logging. AbstractPollingIoProcessor$Processor.run() NioProcessor(AbstractPollingIoProcessorT).process() NioProcessor(AbstractPollingIoProcessorT).process(T) NioProcessor(AbstractPollingIoProcessorT).read(T) | DefaultIoFilterChain.fireMessageReceived(java.lang.Object) | DefaultIoFilterChain.callNextMessageReceived(IoFilterChain$Entry, IoSession, Object) | DefaultIoFilterChain$HeadFilter(IoFilterAdapter).messageReceived(IoFilter$NextFilter, IoSession, Object) | DefaultIoFilterChain$EntryImpl$1.messageReceived(IoSession, Object) | DefaultIoFilterChain.callNextMessageReceived(IoFilterChain$Entry, IoSession, Object) | MdcInjectionFilter(CommonEventFilter).messageReceived(IoFilter$NextFilter, IoSession, Object) | MdcInjectionFilter.filter(IoFilterEvent) | IoFilterEvent.fire() | DefaultIoFilterChain$EntryImpl$1.messageReceived(IoSession, Object) | DefaultIoFilterChain.callNextMessageReceived(IoFilterChain$Entry, IoSession, Object) | ProtocolCodecFilter.messageReceived(IoFilter$NextFilter, IoSession, Object) | | TextLineDecoder.decode(IoSession, IoBuffer, ProtocolDecoderOutput) | | TextLineDecoder.decodeAuto(TextLineDecoder$Context, IoSession, IoBuffer, ProtocolDecoderOutput) | | -+ | | ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush() | | DefaultIoFilterChain$EntryImpl$1.messageReceived(IoSession, Object) | | DefaultIoFilterChain.callNextMessageReceived(IoFilterChain$Entry, IoSession, Object) | | LoggingFilter.messageReceived(IoFilter$NextFilter, IoSession, Object) | | DefaultIoFilterChain$EntryImpl$1.messageReceived(IoSession, Object) | | DefaultIoFilterChain.callNextMessageReceived(IoFilterChain$Entry, IoSession, Object) | | DefaultIoFilterChain$TailFilter.messageReceived(IoFilter$NextFilter, IoSession, Object) | | ChatProtocolHandler.messageReceived(IoSession, Object) | | ChatProtocolHandler.broadcast(String) | | NioSocketSession(AbstractIoSession).write(Object) | | NioSocketSession(AbstractIoSession).write(Object, SocketAddress) | | DefaultIoFilterChain.fireFilterWrite(WriteRequest) | | DefaultIoFilterChain.callPreviousFilterWrite(IoFilterChain$Entry, IoSession, WriteRequest) | | DefaultIoFilterChain$TailFilter.filterWrite(IoFilter$NextFilter, IoSession, WriteRequest) | | DefaultIoFilterChain$EntryImpl$1.filterWrite(IoSession, WriteRequest) | | DefaultIoFilterChain.callPreviousFilterWrite(IoFilterChain$Entry, IoSession, WriteRequest) | | LoggingFilter(IoFilterAdapter).filterWrite(IoFilter$NextFilter, IoSession, WriteRequest) | | DefaultIoFilterChain$EntryImpl$1.filterWrite(IoSession, WriteRequest) | | DefaultIoFilterChain.callPreviousFilterWrite(IoFilterChain$Entry, IoSession, WriteRequest) | | ProtocolCodecFilter.filterWrite(IoFilter$NextFilter, IoSession, WriteRequest) | | | TextLineEncoder.encode(IoSession, Object, ProtocolEncoderOutput) | | | ProtocolCodecFilter$ProtocolEncoderOutputImpl(AbstractProtocolEncoderOutput).write(Object) | | | -+ | |
Re: [MessageSent] let's remove it...
spot on. +1. remove it.
On Mon, Nov 10, 2008 at 7:11 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
Hi guys,
a few days ago, Julien suggested that we should remove this event. I never
used it, found it a bit cumbersome, but didn't had time to double check
what's doing.
Let's go back to the mailing list...
Back in july, I posted a mail where I questionned some code :
ProtocolCodecFilter.filterWrite() {
...
ProtocolEncoder encoder = getEncoder(session);
ProtocolEncoderOutputImpl encoderOut = getEncoderOut(session,
nextFilter, writeRequest);
try {
encoder.encode(session, message, encoderOut);
// Here, the encoded message is sent.
encoderOut.flush();
// Here an empty message is sent...
nextFilter.filterWrite(session, new WriteRequest(
new MessageByteBuffer(writeRequest.getMessage()),
writeRequest.getFuture(),
writeRequest.getDestination()));
There are two places in this code where the message is written : in the
encoderOut.flush() and in the filterWrote() call.
Trustin replied saying :
The two code blocks above are effectively same. The reason we call
filterWrite once more with an empty buffer (MessageByteBuffer or
MessageWriteRequest) is to generate a proper messageSent event which
corresponds to the written message. Let me know if there's more efficient
way to take care of messageSent events.
There is an obvious way to be more efficient here : simply not sending this
messageSent event !
But this is not a good enough reason to remove it. Let's dig another mail.
https://issues.apache.org/jira/browse/DIRMINA-574
Steps to reproduce:
1) Connection is closed at the socket level.
2) A user writes a message.
3) the message is encoded by a ProtocolCodecFilter.
4) MINA notices the closed socket and fires a sessionClosed event.
5) After the sessionClosed event is fired, IoFilterChain.clear() is called.
6) MINA tries to write the user write request, but the session is closed
already - all write requests are discarded.
7) Before MINA discards all write requests, MINA checks if the first item in
the queue is an empty buffer, which means a special separator which is
handled by ProtocolCodecFilter.
8) If there's an empty buffer in the head of the queue, MINA fires a
messageSent event with the empty buffer in the hope that ProtocolCodecFilter
will catch it.
9) However, the filter chain is empty and therefore IoHandler implementation
gets ClassCastException.
At step 8, we send a MessageSent event, which leads to an Exception.
Clearly, this is not good. Removing the MessageSent event will immediatly
solve this blocker issue.
Last, not least, another mail states that :
Also, I'd like to make a plug for removing messageSent() callbacks and
having the end-user API rely on WriteFutures instead. It's a hassle to
write new filters when you have to worry about passing back the correct
object.
Using WriteFuture will clearly be a better way to get the message as it has
been posted to the chain, instead to having to encode it back, as it's
currently done.
Anyone disagree ? Anything I missed ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: onPreAdd, onPostAdd, onPreRemove, onPostRemove : are they useful ?
never used them. On Sun, Nov 9, 2008 at 2:52 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: never used them. On Sat, Nov 8, 2008 at 11:35 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, while working on the chain refactoring, I found that those four methods are never invoked into the core (invocation for these methods can only be found in tests, and always by explicit calls). Do we really needs them ? Has someone already uase them ? Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: onPreAdd, PostAdd, remove : correction
If they are not being used, delete them. I can say that I have never used them.
--Mark
On Sat, Nov 8, 2008 at 5:43 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
Hi,
those methods are called when a new filter is registred into the chain.
However, the few filters implementing those methods typically check that the
added filter is not already present in the chain :
ProtocolCodecFilter, ExecutorFilter, KeepAliveFilter :
public void onPreAdd(IoFilterChain parent, String name,
NextFilter nextFilter) throws Exception {
if (parent.contains(this)) {
throw new IllegalArgumentException(
You can't add the same filter instance more than once.
Create another instance and add it.);
but SslFilter does some intrigating things, which seems to me deserves to be
found in a init() method.
IMO, pre/post operation are just a bit too much. The way it should be done
is :
- init the filter
- add/remove a filter from the chain
and that's it.
Anyone has a better vision of what those method are good for ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [proposal] Was : Re: setTrafficMask poll again
Getting compilation errors. Cannot find the TrafficMask class: /Users/elihusmails/dev/mina/mina-cleaning/core/src/main/java/org/apache/mina/core/filterchain/IoFilter.java:[25,35] cannot find symbol symbol : class TrafficMask location: package org.apache.mina.core.session /Users/elihusmails/dev/mina/mina-cleaning/core/src/main/java/org/apache/mina/core/filterchain/IoFilterAdapter.java:[24,35] cannot find symbol symbol : class TrafficMask location: package org.apache.mina.core.session /Users/elihusmails/dev/mina/mina-cleaning/core/src/main/java/org/apache/mina/core/filterchain/IoFilterChain.java:[28,35] cannot find symbol symbol : class TrafficMask location: package org.apache.mina.core.session /Users/elihusmails/dev/mina/mina-cleaning/core/src/main/java/org/apache/mina/core/filterchain/DefaultIoFilterChain.java:[36,35] cannot find symbol symbol : class TrafficMask location: package org.apache.mina.core.session --Mark On Fri, Nov 7, 2008 at 10:54 PM, Mark Webb [EMAIL PROTECTED] wrote: +1 On Wed, Nov 5, 2008 at 1:16 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 On Wed, Nov 5, 2008 at 3:01 PM, Julien Vermillard [EMAIL PROTECTED]wrote: I would like to propose : - ignore setTrafficMask events in the filter chain (looks like Mark is already agreeing) - remove setTrafficMask(..) and keep the following IoSession methods : suspendRead(), suspendWrite(), resumeRead(), resumeWrite() which naming is much better and add methods isWriteSuspended() isReadSuspended() Kill the TrafficMask class and clear all the filters of references to TrafficMas, and of course fix transport classes. That would reduce the complexity of the thingy and make the API for pausing traffic a bit more user-friendly. WDYT ? Julien On Tue, 4 Nov 2008 18:38:15 +0100 Julien Vermillard [EMAIL PROTECTED] wrote: It was used by Read/WriteThrottlingFilter wich was removed of 2.0 : http://www.nabble.com/Dropping-traffic-throttling-from-2.0-td16092085.html as said by Emm look like it's used nowhere is MINA codebase. As said by Trustin in this mail the remplacement is supposed to be o.a.m.f.executor.* and no references to setTrafficMask(); Frankly I don't understand how you can throttle read, without using setTrafficMask and disabling OP_READ on the low level socket. Julien On Tue, 4 Nov 2008 18:01:58 +0100 Maarten Bosteels [EMAIL PROTECTED] wrote: Wasn't it an attempt to implement throttling ? When requests are coming in faster than they're being processed = set TrafficMask to block reading = TCP buffers will fill up (OS level) = TCP will tell sender to slow down = OOM prevented when queue of incoming messages gets smaller = resume reading I haven't tried this yet, so I could be totally wrong. Maarten On Tue, Nov 4, 2008 at 5:50 PM, Julien Vermillard [EMAIL PROTECTED]wrote: Hi, There is something in MINA who has hook everywhere in the core, it's traffic mask. As far I understand the concept, the idea is to be able to block read and/or writes using session.setTrafficMask(...), I never needed it, and I wonder who use it and for what exactly ? Julien
Re: [proposal] Was : Re: setTrafficMask poll again
I just went ahead and fixed the errors. On Sat, Nov 8, 2008 at 8:30 PM, Mark Webb [EMAIL PROTECTED] wrote: Getting compilation errors. Cannot find the TrafficMask class: /Users/elihusmails/dev/mina/mina-cleaning/core/src/main/java/org/apache/mina/core/filterchain/IoFilter.java:[25,35] cannot find symbol symbol : class TrafficMask location: package org.apache.mina.core.session /Users/elihusmails/dev/mina/mina-cleaning/core/src/main/java/org/apache/mina/core/filterchain/IoFilterAdapter.java:[24,35] cannot find symbol symbol : class TrafficMask location: package org.apache.mina.core.session /Users/elihusmails/dev/mina/mina-cleaning/core/src/main/java/org/apache/mina/core/filterchain/IoFilterChain.java:[28,35] cannot find symbol symbol : class TrafficMask location: package org.apache.mina.core.session /Users/elihusmails/dev/mina/mina-cleaning/core/src/main/java/org/apache/mina/core/filterchain/DefaultIoFilterChain.java:[36,35] cannot find symbol symbol : class TrafficMask location: package org.apache.mina.core.session --Mark On Fri, Nov 7, 2008 at 10:54 PM, Mark Webb [EMAIL PROTECTED] wrote: +1 On Wed, Nov 5, 2008 at 1:16 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 On Wed, Nov 5, 2008 at 3:01 PM, Julien Vermillard [EMAIL PROTECTED]wrote: I would like to propose : - ignore setTrafficMask events in the filter chain (looks like Mark is already agreeing) - remove setTrafficMask(..) and keep the following IoSession methods : suspendRead(), suspendWrite(), resumeRead(), resumeWrite() which naming is much better and add methods isWriteSuspended() isReadSuspended() Kill the TrafficMask class and clear all the filters of references to TrafficMas, and of course fix transport classes. That would reduce the complexity of the thingy and make the API for pausing traffic a bit more user-friendly. WDYT ? Julien On Tue, 4 Nov 2008 18:38:15 +0100 Julien Vermillard [EMAIL PROTECTED] wrote: It was used by Read/WriteThrottlingFilter wich was removed of 2.0 : http://www.nabble.com/Dropping-traffic-throttling-from-2.0-td16092085.html as said by Emm look like it's used nowhere is MINA codebase. As said by Trustin in this mail the remplacement is supposed to be o.a.m.f.executor.* and no references to setTrafficMask(); Frankly I don't understand how you can throttle read, without using setTrafficMask and disabling OP_READ on the low level socket. Julien On Tue, 4 Nov 2008 18:01:58 +0100 Maarten Bosteels [EMAIL PROTECTED] wrote: Wasn't it an attempt to implement throttling ? When requests are coming in faster than they're being processed = set TrafficMask to block reading = TCP buffers will fill up (OS level) = TCP will tell sender to slow down = OOM prevented when queue of incoming messages gets smaller = resume reading I haven't tried this yet, so I could be totally wrong. Maarten On Tue, Nov 4, 2008 at 5:50 PM, Julien Vermillard [EMAIL PROTECTED]wrote: Hi, There is something in MINA who has hook everywhere in the core, it's traffic mask. As far I understand the concept, the idea is to be able to block read and/or writes using session.setTrafficMask(...), I never needed it, and I wonder who use it and for what exactly ? Julien
Re: New branch for clearing features
Thanks. I am using eclipse as well. I guess I will keep on creating new workspaces. --Mark On Fri, Nov 7, 2008 at 4:28 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Julien Vermillard wrote: On Thu, 6 Nov 2008 22:24:48 -0500 Mark Webb [EMAIL PROTECTED] wrote: I have a simple, somewhat related question. With all of these branches now being used, what IDE are you all using and how are you keeping all the branches straight? I am using Eclipse and am creating a new workspace for each branch. It seems like there much be an easier way. TIA Mark Hi, I'm using mvn eclipse:eclipse and new workspace and as everybody suffering eclipse OOM errors and crappyness if I load too much project in my workspace :( I'm using eclipse, and have a different instance for each branch : IFAIK, you can't load twice the same project in one workspace, even if it's supposed to be on what eclipse call 'workspace' (which is unrelated to the 'workspace' you create on the disk). I don't have any OOM, even with something like 6 projects loaded : - ADS - MINA - FtpServer - AsyncWeb - JMeter - My own test project but I'm using my own eclipse launch script to use 800 Mb. Of course, I'm on Linux ! If someone has a better solution, I would love to have more than one MINA version in eclipse ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: UDP request/response, second attempt
Sure, it can be done. the problem is that the packets could be received on either end out of order, or not at all. As long as you are willing to accept these risks, you will be fine. On Thu, Nov 6, 2008 at 8:57 AM, Lorenz Breu [EMAIL PROTECTED] wrote: Hi again OK, these questions may seem dumb to you, so sorry for the inconvenience. Anyway, has anybody ever implemented a request/response mechanism using the Datagram classes in MINA (e.g. NIODatagramConnector)? My question is if it was intended to be used in this way, i.e. if is possible for an Acceptor's handler to do a session.write(reply) after receiving a request and a Connector's handler to do a session.read(reply) after sending the request. In java.io a socket can be read from after a send event, but what I have to do now is prepare a connector (i.e. find a free port), then start an acceptor on that port. When that is ready I can send the request. The acceptor on the other side receives the message and sends the reply back out through it's own connector to the port the request came from. The original sender then receives the reply on it's acceptor and disposes the acceptor once the message is received. So for each request/reply the requester has to set up and dispose a new acceptor, which may lead to unnecessary overhead(??). I was considering adding a java.io reply socket to my AprDatagramSession, but that would be a hack and wouldn't quite fit in with the rest of the framework. So, to summarize, should it be possible to reply to a request within a DatagramSession? Has it been done with the NIO stuff? If so, I would continue looking for a solution in the APR transport classes. Regards, Lorenz
Re: [proposal] Was : Re: setTrafficMask poll again
+1 On Wed, Nov 5, 2008 at 1:16 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 On Wed, Nov 5, 2008 at 3:01 PM, Julien Vermillard [EMAIL PROTECTED]wrote: I would like to propose : - ignore setTrafficMask events in the filter chain (looks like Mark is already agreeing) - remove setTrafficMask(..) and keep the following IoSession methods : suspendRead(), suspendWrite(), resumeRead(), resumeWrite() which naming is much better and add methods isWriteSuspended() isReadSuspended() Kill the TrafficMask class and clear all the filters of references to TrafficMas, and of course fix transport classes. That would reduce the complexity of the thingy and make the API for pausing traffic a bit more user-friendly. WDYT ? Julien On Tue, 4 Nov 2008 18:38:15 +0100 Julien Vermillard [EMAIL PROTECTED] wrote: It was used by Read/WriteThrottlingFilter wich was removed of 2.0 : http://www.nabble.com/Dropping-traffic-throttling-from-2.0-td16092085.html as said by Emm look like it's used nowhere is MINA codebase. As said by Trustin in this mail the remplacement is supposed to be o.a.m.f.executor.* and no references to setTrafficMask(); Frankly I don't understand how you can throttle read, without using setTrafficMask and disabling OP_READ on the low level socket. Julien On Tue, 4 Nov 2008 18:01:58 +0100 Maarten Bosteels [EMAIL PROTECTED] wrote: Wasn't it an attempt to implement throttling ? When requests are coming in faster than they're being processed = set TrafficMask to block reading = TCP buffers will fill up (OS level) = TCP will tell sender to slow down = OOM prevented when queue of incoming messages gets smaller = resume reading I haven't tried this yet, so I could be totally wrong. Maarten On Tue, Nov 4, 2008 at 5:50 PM, Julien Vermillard [EMAIL PROTECTED]wrote: Hi, There is something in MINA who has hook everywhere in the core, it's traffic mask. As far I understand the concept, the idea is to be able to block read and/or writes using session.setTrafficMask(...), I never needed it, and I wonder who use it and for what exactly ? Julien
Re: poll VmPipe
I have never used it. I could see it having a utility for unit testing, but that is it. On Thu, Nov 6, 2008 at 11:05 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: peter royal wrote: On Nov 6, 2008, at 7:28 AM, Dan Creswell wrote: Hmmm, if VmPipe is done right it should allow me to build an app/service on top of MINA that can easily be tested all inside of a single JVM (good for unit testing amongst other things) or deployed fully networked with minimum code disruption. Is it intended to be used in such a fashion? If not possibly it can be dropped. I am using it for exactly this purpose. We have two services that can either be deployed as separate VMs, or inside of the same VM. WHen its inside the same VM, we cull out the protocol filters and just use a VmPipe. Minimal code disruption to support both configurations. Interesting. Edouard's proposal then makes sense : implementing the underlying communication using Queues and removing a lot of the current code could help. You will still have the same API (IoAcceptor/IoConnector), and won't be disruptive. This has to be evaluated. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: ConnectionThrottleFilter
I am not currently using this for anything, I am sure that given enough time I could come up with reasons for using it. OTOH, if we are looking to streamline the baseline, I say remove it and maybe create a filter repository that people can get to for additional filters. Something similar to what Apache has done with its modules. --Mark On Thu, Nov 6, 2008 at 3:58 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Niklas Gustavsson wrote: On Thu, Nov 6, 2008 at 6:46 PM, Julien Vermillard [EMAIL PROTECTED] wrote: But if you accept the session (opening) you send all the TCP soup for opening/accepting the socket connection, and if you close the session directly you send all the TCP soup for closing the socket connection. I hardly can imagine it can protect you from any DoS. That would at least be cheaper than doing the rest of your stuff (decoding/encoding, bussines logic and so on) , right? Well, if you are going to drop connections just because you have hundred (or even thousands) arriving at the same time, then that means your server is being badly DoSed. Now you have two cases : - your server is reachable by outsiders : you better have a front system to deal with such attacks. Whatever you do on MINA side will be far from enough to protect you. So I tend to think that, in this case, the connection throttling is absolutely useless. - your server is only used from a private nertwork. Some wrong process is pounding your server, and it will make it dies sooner or later. Again, in this case, I would rather let it die quickly, in order to be able to react quickly. Considering that such attacks (or incorrect usage from internal applications) are impossible to avoid, trying to fix them on the application layer is like trying to empty the sea with a tea spoon... So while not the perfect protection, it is certainly better than nothing. well, in this very case, doing nothing or something is equivalent. You are just offering a small margin during which your server will resist, but I'm not sure it worth the effort. Of course, IMHO :) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: setTrafficMask poll again
+1 to remove it. On Wed, Nov 5, 2008 at 3:36 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 04 Nov 2008 18:24:15 +0100 Emmanuel Lecharny [EMAIL PROTECTED] wrote: Maarten Bosteels wrote: Wasn't it an attempt to implement throttling ? I have no idea. The documentation is pretty scarse, it's not used anywhere but as a parameter passed from method to method, the event type is never used to create an event ... When requests are coming in faster than they're being processed = set TrafficMask to block reading Which part of MINA is setting this flag ? = TCP buffers will fill up (OS level) = TCP will tell sender to slow down = OOM prevented when queue of incoming messages gets smaller = resume reading May be it's a part of a big DoS protection heuristic, but it seems to be lagging seriously. Even the throttling filter is a bit incomplete ... Anyone has a better picture than me on this matter ? Abouot traffic mask the new filter chain I think you could remove the filtering events related to setTrafficMask. See https://issues.apache.org/jira/browse/DIRMINA-467 I think we will never need it. Julien
Re: [About the Filter Chain] Proposals
I agree that we should not 'slaughter' the current code since we are getting close to a final 2.0 release. On Sat, Nov 1, 2008 at 4:27 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: After letting the dust settle on this thread, I can say that I agree with what Alex is saying. I think a 2-way system makes complete sense. Ok. We then will create a branch named mina-new-chain then, in which we will experiment. Be ready for some bad butchering :) One great interest I have in this is how will it work with containers such as Spring. I have been using MINA with Spring alot lately and want to make sure we keep this support in our system. Having some feedback on how you are using MINA with Spring could be interesting. Atm, we have some coupling with xbean which is quite complex to decipher, and this is certainly not something we want to break... Maybe a thread discussing MINA + Spring could help a lot to avoid big mistakes to be done while refactoring the code. But keep in mind that we can't afford to slaughter MINA current code as we are using it in ADS, and we don't really want to re-implement from scratch everything we have done, so trust me on that, we are going to be very cautious ! Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [About the Filter Chain] Events
I have used MESSAGE_SENT, not sure I agree that it should disappear. What about situations where MINA is used in a client library? Won't much of your list be reversed? On Mon, Nov 3, 2008 at 9:41 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi, as I'm looking deeply into the impact on the code of the new chain proposals, I'm looking at the events we are handling. In the following list, I have sorted all the events in two categories : incoming and outgoing events. Incoming events are those received from the clients, outgoing events are those emitted by the server. Here is the list of those events : SESSION_CREATED : An incoming event. SESSION_OPENED : Seems to me to be a duplication of the previous event. An incoming event. SESSION_CLOSED : An incoming event. MESSAGE_RECEIVED : Clearly an incoming event. MESSAGE_SENT : IMHO, useless. Must disappear. SESSION_IDLE : Questionable. But if we keep it, should be considered as an incoming event. EXCEPTION_CAUGHT : Interesting ... IMO, an incoming event too. Even if generated during a write operation (or while processing a Write event), it's applied to the session.incomingChain so that all the filters can handle it. The question is : should we also propagate this event through the outgoingChain ? WRITE : Outgoing event. CLOSE : Not sure what this event is used for. We already have a SESSION_CLOSED, I'm wondering if it's not a duplication. SET_TRAFFIC_MASK : Seems to be used nowhere. It appears to have been created to handle custom events. I suggest that we ignore this event, unless someone has a clear vision on how to use it and why. Did I forgot anything important? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [About the Filter Chain] Proposals
I think we should focus on getting 2.0 out the door. We have been working on it long enough and I think there are many people using it in production or near-production systems. Once we release, we will probably get alot more feedback and can use that feedback to enhance/fix the next version. I would think that we should move right towards 3.0. As we get closer and closer to a release, I think the API should not change and therefore we should not be adding functionality into the system unless something is really broke. just my $.02 Mark On Mon, Nov 3, 2008 at 10:06 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: I agree that we should not 'slaughter' the current code since we are getting close to a final 2.0 release. This is something we have to discuss. Here, IMHO, we have two options, both have pros and cons : 1) go as far as needed to get a MINA 2.0 with as much cleaning as needed. 2) Release MINA 2.0 as fast as possible, fixing the most obvious bugs, and move directly to a MINA 3.0 Option (1) pros : - as MINA 2.0 API is not stabilized yet (we are still working on milestone), this let use the opportunity to do those changes with a minimal harm - we can do that now, not waiting for a 2.0 release to be done in, say, 2 months - this is the perfect opportunity to clean up the code, add the missing documentation, and delivering a much better release Option (1) cons : - it will takes months before we can release a long waited new release - many users are already using mina 2.0, and they will be unpleased if we change a lot of things into it - we have to be careful not to remove any of the existing functionalities, something we don't have to take care for a 3.0 branch, as it won't be used in production before quite a long time Option (2) pros : - freedom ! No need to care about the existing code, we can even start from a white page. - the community can grow faster, as we may have people who are reluctant to enter the project while it's in a pre-release state - we are not limited in time. 2.0 is expected sooner or later, with a 3.0, we have more than a year to get something done Option (2) cons : - we will have to maintain a 2.0 version which is far from being perfect - 2.0 seems to be slow, compared to other framework. Not that important IMHO, but releasing a dog is not the perfect way to get some good reports... - people who are expecting a better MINA (a simpler one) might wait for one more year until 3.0 is out. Even worse, they can run away... Of course, I'm just dumping some of the ideas I have about that. atm, I have not yet set my mind on which option is the best, but we can still work with both options in mind, as soon as what we do is done in a branch. Soon, we will be able to decide if we release a 2.0 with or without those modifications, and then merge the branch into trunk or create a new version, closing the 2.0 branch (ie : it will become a release branch). In any case, there is something very important : the current code base is not known by a lot of people, and it will take time to build a new community around the core code base. The biggest question is : will we find enough people wanting to work on the current trunk in order to get the new release (be it 2.0 or 3.0) ? And how long will they be dedicated ? What if we release a 2.0-RC in the next few months and as we don't have anyone wanting to start a 3.0 ? so, now, wdyt ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [About the Filter Chain] Proposals
I am not really doing anything crazy with Spring, just an acceptor, handler and filter chain. One item that might be nice is a way to order the filters in the chain. Right now its a map. I am not sure if filters stay in order when you use Spring. I would like to Spring-enable more classes, especially filters but things are fine right now for my requirements. On Sat, Nov 1, 2008 at 4:27 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: After letting the dust settle on this thread, I can say that I agree with what Alex is saying. I think a 2-way system makes complete sense. Ok. We then will create a branch named mina-new-chain then, in which we will experiment. Be ready for some bad butchering :) One great interest I have in this is how will it work with containers such as Spring. I have been using MINA with Spring alot lately and want to make sure we keep this support in our system. Having some feedback on how you are using MINA with Spring could be interesting. Atm, we have some coupling with xbean which is quite complex to decipher, and this is certainly not something we want to break... Maybe a thread discussing MINA + Spring could help a lot to avoid big mistakes to be done while refactoring the code. But keep in mind that we can't afford to slaughter MINA current code as we are using it in ADS, and we don't really want to re-implement from scratch everything we have done, so trust me on that, we are going to be very cautious ! Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [About the Filter Chain] Events
I had logic in my IoHandler that was quite complex and there were 3 different parts of the code that could send data back to the client. Instead of placing a WriteFuture in all 3 places, I put the logic in messageSent. I could just define an IoFutureListener that is passed into all 3 WriteFuture's though. If it makes our lives (as API developers) easier, then I can change my code (as an end user). --Mark On Mon, Nov 3, 2008 at 10:13 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: I have used MESSAGE_SENT, not sure I agree that it should disappear. May I ask you in which context you used it ? I'm wondering if we can cover your case with WriteFuture ? What about situations where MINA is used in a client library? Won't much of your list be reversed? That's a very good question ! I don't think it makes any difference. From the client side, the incoming events are generated by an outgoing event on the server side. Ie, the server write a response, then the client get a MESSAGE_RECEIVED event to deal with. In fact, it's really like if you have nothing in between the client and the server. The client write a message, the server read it, then the server write the response, the client read it. If you take the protocolCodecFilter, it works the same for the server and the client. A message will have to be encoded in both case when writing the message (and it's always on the outgoing chain), and decoded when read (incoming chain). I may miss something, but AFAICS, it's absolutely symetric. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [About the Filter Chain] Proposals
I agree completely with all of Niklas's comments. On Mon, Nov 3, 2008 at 11:49 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Niklas Gustavsson wrote: On Mon, Nov 3, 2008 at 4:13 PM, Mark Webb [EMAIL PROTECTED] wrote: I think we should focus on getting 2.0 out the door. We have been working on it long enough and I think there are many people using it in production or near-production systems. Once we release, we will probably get alot more feedback and can use that feedback to enhance/fix the next version. Big +1. We will find areas that we would like to improve during the foreseeable future (this change and ByteBuffer comes to mind). yop. And I don't see how we can include that in 2 weeks... Including all such changes will delay 2.0 for a long time, long enough for MINA to get behind other frameworks. Having a real release out will mean getting further feedback from users, so far I haven't seen a lot of users requesting this change nor the ByteBuffer change. I think we're too critical, the code is great. Well, IMHO, the code works. Saying that it's great is another story :) (but this might just be a matter of taste ...) Anyway, I agree with what you say. We don't release fast enough. Atm, regardless to the current code quality, and performance, I think MINA 2 is usable, even if there are still some issues to fix. I will do some quick perf tests on ADS with MINA 2 and give you some feedback soon. Release early, release often. We do neither. eh ;) I would think that we should move right towards 3.0. I say go work on a branch (as already suggested) and see where that leads. There is a new branche for such experiment. Branching is certainly the way to go, whatever we do regarding the release ! I would like to let this thread go for a little bit (let's say a couple of days), and then, I think we will have to vote : going for 2.0-RC or modify the code massively. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [About the Filter Chain] Proposals
After letting the dust settle on this thread, I can say that I agree with what Alex is saying. I think a 2-way system makes complete sense. One great interest I have in this is how will it work with containers such as Spring. I have been using MINA with Spring alot lately and want to make sure we keep this support in our system. --Mark On Sat, Nov 1, 2008 at 4:29 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2008 at 8:28 PM, Emmanuel Lecharny [EMAIL PROTECTED]wrote: Hi, I'm currently reviewing the Filter chain we are using internally. This is one of the most appealing feature we have, as it allows us to design a versatile handling of incoming and outgoing messages. However, in many respects, the current implementation is pretty complicated, and could benefit from some refactoring. I will first try to summarize what we need, and then, from these needed features, I will try to define what should remain, and what could be change and improved. 1) What we need --- - Incoming requests must be handled in a pipeline, where filters are executed one after the other, in a predefined order. - This order is defined by the protocol designer - It can change during the processing, for instance if we need to set up some logging for debug purpose - Another case would be that some filter can be added or removed depending on the current message state (a good example could be a multi-layer protocol decoder) - This pipeline is a two-way pipeline : it handles incoming requests, and outgoing responses - The filter chain is not static, but it should be thread safe, so any kind of modification must *not* lead to some exception (NPE or inconsistent state) - Passing to the next filter should be possible in the middle of a filter processing (ie, in a specific filter, you can do some pre-processing, call the next filter, and do some post-processing) - We should be able to use different pipelines depending on the service (filters can be arranged differently on the same server for 2 different services) - Even for two different sessions, we may have different chain of filters (one session might use a Audit filter while the next is just fine without this filter) - We want to decouple the message processing from the socket processor, using a special filter which use an executor to process the message in its own thread (I wish I didn't forgot anything) and, ultimately : - It should be easy to debug - it should be FAST... :) All those features describe the perfect system :). How what we have fits this beautiful picture ? 2) Possible improvements The first big point is that we currently have one single chain, when having two could help a lot. The current chain is two-ways, with forward links and backwards link. As we have to handle incoming requests but also write outgoing response, it has to be two-ways. But one single chain is certainly not the best way to handle this. There is no reason why the outgoing chain should be the same than the incoming chain. We may even not use the same filters ! Proposition (a) : Let's create two chains instead of one : a reader-chain/incoming-chain and a writer-chain/outgoing-chain. One other big issue is the way the chain is created and used. Here is, for a very simple chain, the stack trace we obtain (we just have a ProtocolCodecFilter into the chain, nothing else) when an incoming message is being processed, from the bottom to the top (o.a.m stands for org.apache.mina in this trace) Thread [NioProcessor-1] (Suspended) o.a.d.agent.ldap.LdapConnectionImpl.messageReceived(o.a.m.core.session.IoSession, java.lang.Object) line: 597 -- here, we call the handler ... - o.a.m.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(o.a.m.core.filterchain.IoFilter$NextFilter, o.a.m.core.session.IoSession, java.lang.Object) line: 755 o.a.m.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(o.a.m.core.filterchain.IoFilterChain$Entry, o.a.m.core.session.IoSession, java.lang.Object) line: 440 o.a.m.core.filterchain.DefaultIoFilterChain.access$5(o.a.m.core.filterchain.DefaultIoFilterChain, o.a.m.core.filterchain.IoFilterChain$Entry, o.a.m.core.session.IoSession, java.lang.Object) line: 435 o.a.m.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(o.a.m.core.session.IoSession, java.lang.Object) line: 835 -- here, we call the next filter in the chain, which is the Tail filter - o.a.m.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush() line: 539 o.a.m.filter.codec.ProtocolCodecFilter.messageReceived(o.a.m.core.filterchain.IoFilter$NextFilter, o.a.m.core.session.IoSession, java.lang.Object) line: 265 -- here, we jump to the ProtocolCodec filter - o.a.m.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(o.a.m.core.filterchain.IoFilterChain$Entry,
Re: Who is going to go to ApacheCon US next month ?
Not me. I have some hard deadlines here at the office On Thu, Oct 2, 2008 at 2:23 PM, Niklas Gustavsson [EMAIL PROTECTED] wrote: On Thu, Oct 2, 2008 at 7:24 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: I'd love to be there, I will ask my boss to pay for the trip but I am afraid it won't happen. Chances are bigger for ApacheCon Europe 2009 (Amsterdam). I'm also aiming for ApacheCon Europe. Planing to send in a paper or two. /niklas
Application Period Opens for Travel Assistance to ApacheCon US 2008
The Travel Assistance Committee is taking in applications for those wanting to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New Orleans. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon US 2008 who need some financial support in order to get there. There are VERY few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF and open source in general. Financial assistance is available for flights, accomodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in Europe and or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon US of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the application form and details for submitting. Time is very tight for this event, so applications are open now and will end on the 2nd October 2008 - to give enough time for travel arrangements to be made. Good luck to all those that will apply. Regards, The Travel Assistance Committee
Re: Web site refactoring proposal
Seems like a very good move to me... On Tue, Sep 2, 2008 at 10:25 AM, Emmanuel Lecharny [EMAIL PROTECTED]wrote: Niklas Gustavsson wrote: On Sat, Jun 7, 2008 at 3:24 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Otherwise, I would also suggest some refactoring of the main site. Here is some proposal : While we're at it, why not get a similar download page as ActiveMQ got, it's a beaty: http://activemq.apache.org/activemq-510-release.html /niklas Any objection if I whip a quick refactoring of MINA web site, just to get something like this : *Latest Downloads* Mina 2.0.0-M3 Mina 1.1.7 Mina 1.0.10 FtpServer 1.0.0-M2 AsyncWeb-unstable * Projects Mina FtpServer AsyncWeb Downloads Roadmap * Documentation MINA 1.0 MINA 1.1 MINA 2.0 FtpServer AsyncWeb FAQ * Resources Mailing lists IRC Issue tracking Sources Performances Testimonies Articles/conferences * Community Team License Contributing Thanks ASF sponsors Sponsorship program * Upcoming ApacheCon US logo wdyt ? PS: this will be just a first step. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : 2.0 Roadmap ?
So how can we get paid to work MINA full time ? :) On Wed, Aug 27, 2008 at 3:37 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi Mark, thanks for the comments ! More inline Mark Webb wrote: I agree with everything that you all have said here. The one thing I would add is about the documentation/tutorials. I look around at some other projects and sometimes the documentation is better, sometimes its worse. Focusing on the better projects, the documentation is spot-on professional. I have been working with ActiveMQ lately and the whole idea of the Enterprise Integration Patterns (EIP) is fantastic. AFAIK, ctiveMQ has been heavily backed by IONA, who paid some peeps to work on it, as they are offering Fuse, an enterprise version of ActiveMQ. THis may explain the quality of ActiveMQ site. It shows use cases and associated documentation. I think this is what we need. If you want an SMTP server do this, if you want an FTP server do that. The list goes on and on. Agreed. I think part of the problem with documentation is that the learning curve on the MINA internals is steep. I have been on the project for a couple years and only in the last 4-6 months can I say that I really understand the entire system. This makes it tough for people to dive in an help. That's so true ! And the overly complexity of the code, when you think that it's a small code base (45 KSlocs, out of which the core is 33KSlocs) is killing us, specially when you have sparce doc/javadoc. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Anyone know why Spring integration was renamed to integration-beans?
We did not want it to be spring-centric. The goal was to support all of the IoC containers like xbeans, spring, pico. On Tue, Aug 26, 2008 at 1:04 PM, Trustin Lee (이희승) [EMAIL PROTECTED] wrote: On Wed, 27 Aug 2008 01:36:19 +0900, Julien Vermillard [EMAIL PROTECTED] wrote: due to lack of doc/mails as usual http://markmail.org/message/o5lzxyrcnkawhnnj -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: Re : 2.0 Roadmap ?
I agree with everything that you all have said here. The one thing I would add is about the documentation/tutorials. I look around at some other projects and sometimes the documentation is better, sometimes its worse. Focusing on the better projects, the documentation is spot-on professional. I have been working with ActiveMQ lately and the whole idea of the Enterprise Integration Patterns (EIP) is fantastic. It shows use cases and associated documentation. I think this is what we need. If you want an SMTP server do this, if you want an FTP server do that. The list goes on and on. I think part of the problem with documentation is that the learning curve on the MINA internals is steep. I have been on the project for a couple years and only in the last 4-6 months can I say that I really understand the entire system. This makes it tough for people to dive in an help. ...just my $.02 On Tue, Aug 26, 2008 at 7:38 PM, Edouard De Oliveira [EMAIL PROTECTED] wrote: Hi guys, Little late on the subject but better late than never as people says Code features : - integrating proxy patch The proxy connector needs some javadocing and maybe some tighter integration with the core as it was primarily intended to work out of the box without any core modifications. Some comments from the team would be much appreciated as sometimes it is difficult to question myself after so much time thinking on it fresh eyes could open fresh perspectives. - composite buffers and streams based on it There seems to be much interest on this feature avoiding buffer copy is definitely a must have +1 - killing IoBuffer Need some pointers on this discussion about the downsides of it. - fixing logging filter I like Julien's hardcoded way because log filter is a debugging tool (maybe we should rename it to DebugFilter as well) but i would add some booleans to enable/disable event logging programatically on a method basis to make it fully configurable. removing netty2 codec module (who want to use it for Mina 2.0 ?) - who is using it ? is there any advantage which is not already built-in core ? if so should we port it ? test coverage (yeah painfull at this point) +1 write traffic throttling +1 this is tricky and providing as much help on this subject will help community Doc feature : +1 to the whole doc effort state of the art release tarballs Rpms and stuff is not a priority for the 2.0 release in my own opinion too. Need to look closely to the tarballs to make structure improvements suggestions new website, clearer, and with better integration/links to subprojects like ftpserver and asyncweb Pretty simple example it's hard to find the svn repository link so it's not really a whole start over that is needed but maybe a clearer navigation Hope this helps. Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php - Message d'origine De : Emmanuel Lecharny [EMAIL PROTECTED] À : dev@mina.apache.org Envoyé le : Mardi, 26 Août 2008, 10h55mn 15s Objet : Re: 2.0 Roadmap ? Hi guys, sorry for not having replied to this mail yesturday, I was busy with personal stuff. Thanks Julien for having done this summarize. I have to add that we didn't discussed all of the items on the list with Julien, but this is a very good thing that Julien added the important items. We badly need a roadmap for 2.0, taht's for sure. Comments in line Julien Vermillard wrote: Hi, next step is to create a wiki page due to the size of the list :) Certainly. snip/ Code features : - integrating proxy patch Don't know what this is about. https://issues.apache.org/jira/browse/DIRMINA-415 Edouard big patch for supporting proxy such as simple port forwarding and SOCKS. It's somewhat a big patch to shallow. ok. We have to look it closely. - composite buffers and streams based on it I definitely want to get involved here but I need to catch up on the conversations had in the past about it. We need to discuss this item on the ML, as it will imply a hell lot of modifications. - killing IoBuffer +1 Sure, +1. - fixing logging filter +1 I will create a JIRA plus submit at least two proposals (code) - removing netty2 codec module (who want to use it for Mina 2.0 ?) +1 +1 - test coverage (yeah painfull at this point) Yeah test coverage is important but luckily MINA is not that large. Test coverage makes it easier for people to get into the code to try to add features or fix a bug while knowing their changes/fixes will not cause regressions or breakage in the behavior of the API. Plus it's the best example code to use for how to learn to use different features of MINA: I always look at test code when learning how to use a new piece of OSS since the docs may not be there or may not be totally up to date. Emmanuel said me exactly the things word for word ;) We are sharing a lot with Alex, but more important, we have
[jira] Commented: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12622025#action_12622025 ] Mark Webb commented on DIRMINA-489: --- I have checked in the code. Please take a look and let me know what you think. Many thanks to Rich as I think he did a fantastic job with the code. I only ran some sanity checks, formatted the code, javadoc'd the code and made sure it works with the latest trunk, Composite IoBuffer -- Key: DIRMINA-489 URL: https://issues.apache.org/jira/browse/DIRMINA-489 Project: MINA Issue Type: New Feature Components: Core Reporter: David M. Lloyd Assignee: Mark Webb Fix For: 2.0.0-M4 Attachments: mina-composite-20080515.patch.gz, mina-composite-20080517.patch, mina-composite-20080521-2.patch, mina-composite-20080521.patch, mina-composite-20080723-1.patch, mina-composite-20080723-2.patch Provide a way to create a large IoBuffer from several smaller IoBuffers, without copying the underlying data. It would probably be acceptable to constrain the composite buffer in various ways, for example by disallowing autoexpanding or otherwise changing the capacity, the implementation could be greatly simplified. The goal is to be able to process large messages with a minimum of copying. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Releasing MINA 2.0.0-M3
+1 On Tue, Aug 5, 2008 at 11:37 AM, Emmanuel Lecharny [EMAIL PROTECTED]wrote: Julien Vermillard wrote: [X]: +1, Release MINA 2.0.0-M3 I just created the MINA-2.0.0-M4 version in JIRA, just in case ... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Commented: (DIRMINA-519) BufferingFilter
[ https://issues.apache.org/jira/browse/DIRMINA-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12619401#action_12619401 ] Mark Webb commented on DIRMINA-519: --- These are my results on an OS X machine running Java 1.6.0_05 CPU = 2.4GHz Core 2 Duo Map type: ConcurrentHashMap Runtime:6 Number of threads: 3 Remove probability: 0.1 Ops per second: 17204.25 Map type: HashMap Runtime:6 Number of threads: 3 Remove probability: 0.1 Ops per second: 107432.133 Map type: LazyInitializedCacheMap Runtime:6 Number of threads: 3 Remove probability: 0.1 Ops per second: 55034.4334 Hope this helps BufferingFilter --- Key: DIRMINA-519 URL: https://issues.apache.org/jira/browse/DIRMINA-519 Project: MINA Issue Type: New Feature Components: Filter Reporter: Trustin Lee Assignee: Edouard De Oliveira Priority: Minor Fix For: 2.0.0-M3 Attachments: test.rar As JDK provides BufferedOutputStream, we could provide BufferingFilteer which does the same thing, which buffers encoded data and flushes it out when the buffer becomes full or the flush operation is explicitly requested. This kind of filter is sometimes useful when a session is generating very small messages too frequently and consequently generates unnecessary traffic overhead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: VmPipe Usage Question
Did you try CumulativeProtocolDecoder ? I had a very similar problem once and once I switched over to this class everything worked great. On Tue, Jul 29, 2008 at 2:08 PM, boB Gage [EMAIL PROTECTED] wrote: I have searched far and wide for an answer on this before resorting to bothering anyone... but I can't quite work this out on my own. We're using MINA classes to implement serial and socket connections to external devices and decode the data streams from these devices. I'm trying to use VmPipe classes to create a test mode that fakes an external device, using data files to define specific device behaviors. So far it's working fairly well, with one pretty major glitch.The server-side (the fake hardware device) of the VmPipe is receiving byte-by-byte data from the client-side (our normal device monitor) and can deal with it accordingly. Problem is in the other direction. The server-side uses session.write(b) to write a byte at a time to the stream (at properly faked baud rate even).But instead of those accumulated bytes feeding into our MessageDecoderAdapter descendants as incoming data would from the hardware, they are getting picked up by our IoHandlerAdapter descendant as individual Byte objects (messageReceived() method). How would I get these bytes into the proper decode chain to fully test the low-level device data decoding (as per the DemuxingProtocolCodecFactory definition from the monitor under test)??? Thanks in advance!! boB Gage eko systems, Inc.
Re: releasing 2.0.0-M3 quickly
+1 Sounds fine with me. I am still working on the composite buffer support, but I do not think that it is critical to get into a release right away. On Mon, Jul 28, 2008 at 1:15 PM, W.B. Garvelink [EMAIL PROTECTED]wrote: I'd say stick to the 72 hours. Rushing a release is seldom a good idea in my experience. I haven't yet gotten around to finishing up on DIRMINA-608, but I see no problems pushing that to M4. Barend On Mon, Jul 28, 2008 at 4:07 PM, Julien Vermillard [EMAIL PROTECTED] wrote: yep, and me to gather time and fix the distribution :) Julien On Mon, 28 Jul 2008 09:47:04 -0400 Alex Karasulu [EMAIL PROTECTED] wrote: +1 to releasing. Do we really have to cut down the 72 hrs? Might want to give some time for people to test it? Alex On Mon, Jul 28, 2008 at 5:19 AM, Emmanuel Lecharny [EMAIL PROTECTED]wrote: Julien Vermillard wrote: Hi guys, 2.0.0-M2 release is suffering some serious issues : - DIRMINA-609 a big perf regression on big message (quite common) - the tarballs are fubared, you miss half of the modules I tihkn we need to redo a release soon (M3), specially for DIRMINA-609 WDYT ? +1. You can launch a quick vote, and if the PMC aggreed on, we can even shorten the 72 hours wait to something like 24hours, as we are now on monday. That make sense for such a big regression. Otherwise, I also think that the Write issue should be addressed correctly in 2.0.0-M4 : https://issues.apache.org/jira/browse/DIRMINA-577 https://issues.apache.org/jira/browse/DIRMINA-518 (more to come) Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Assigned: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb reassigned DIRMINA-489: - Assignee: Mark Webb Composite IoBuffer -- Key: DIRMINA-489 URL: https://issues.apache.org/jira/browse/DIRMINA-489 Project: MINA Issue Type: New Feature Components: Core Reporter: David M. Lloyd Assignee: Mark Webb Fix For: 2.0.0-M3 Attachments: mina-composite-20080515.patch.gz, mina-composite-20080517.patch, mina-composite-20080521-2.patch, mina-composite-20080521.patch, mina-composite-20080723-1.patch, mina-composite-20080723-2.patch Provide a way to create a large IoBuffer from several smaller IoBuffers, without copying the underlying data. It would probably be acceptable to constrain the composite buffer in various ways, for example by disallowing autoexpanding or otherwise changing the capacity, the implementation could be greatly simplified. The goal is to be able to process large messages with a minimum of copying. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r678238 - in /mina/trunk/core/src/main/java/org/apache/mina/filter/buffer: ./ BufferedWriteFilter.java
sounds good to me. On Tue, Jul 22, 2008 at 6:19 PM, Edouard De Oliveira [EMAIL PROTECTED] wrote: So we agree on ConcurrentHashMap use : all of the conditions you wrote should be met when correctly using this filter. The uneasy parameter is MAX_THREADS. I think there's no magical value so as an API service provider we should provide default implementation and let the user provide its own params for the ConcurrentHashMap instantiation or even its own instance. I think adding the following constructor should close the debate : public BufferedWriteFilter(int bufferSize, final ConcurrentMapIoSession, IoBuffer buffersMap); WDYT ? Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php - Message d'origine De : Bogdan Ciprian Pistol [EMAIL PROTECTED] À : dev@mina.apache.org Envoyé le : Mardi, 22 Juillet 2008, 12h41mn 46s Objet : Re: Re : svn commit: r678238 - in /mina/trunk/core/src/main/java/org/apache/mina/filter/buffer: ./ BufferedWriteFilter.java From my experience ConcurrentHashMap outperforms Collections.synchronizedMap(...) only if: - you know in advance how many maximum threads (MAX_THREADS) could simultaneously modify the ConcurrentHashMap - MAX_THREADS is small compared to the number of threads that are accessing the ConcurrentHashMap (reads) - the accesses (reads) vastly outnumbers the modifications (writes) ConcurrentHashMap also consumes more memory (increases proportional with MAX_THREADS) Bogdan On Tue, Jul 22, 2008 at 2:24 AM, Edouard De Oliveira [EMAIL PROTECTED] wrote: Perfectly legitimate question Mark : Stop me if i'm not correct, but i think it would be an error using CopyOnWriteMap in this usecase as the map grows when the number of sessions grows and as buffering takes full meaning in long lived sessions, then each new session would duplicate a potentially larger map hence hitting the bad side of CopyOnWriteMap. So ConcurrentHashMap should be more appropriate. WDYT ? ps: i'm commiting right now the proposed fix and a test class on trunk to ease any further review Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php - Message d'origine De : Mark Webb [EMAIL PROTECTED] À : dev@mina.apache.org Envoyé le : Lundi, 21 Juillet 2008, 2h47mn 54s Objet : Re: svn commit: r678238 - in /mina/trunk/core/src/main/java/org/apache/mina/filter/buffer: ./ BufferedWriteFilter.java I have a question on this class. Why not use ConcurrentHashMap for this instead of synchronizing? Or CopyOnWriteMap? On Sat, Jul 19, 2008 at 7:19 PM, [EMAIL PROTECTED] wrote: Author: edeoliveira Date: Sat Jul 19 16:19:14 2008 New Revision: 678238 URL: http://svn.apache.org/viewvc?rev=678238view=rev Log: New IoFilter that implements DIRMINA-519 Added: mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/ mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java (with props) Added: mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java URL: http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java?rev=678238view=auto == --- mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java (added) +++ mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java Sat Jul 19 16:19:14 2008 @@ -0,0 +1,243 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * License); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + *http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + * + */ +package org.apache.mina.filter.buffer; + +import java.io.BufferedOutputStream; +import java.util.HashMap; +import java.util.Map; + +import org.apache.mina.core.buffer.IoBuffer; +import org.apache.mina.core.filterchain.IoFilter; +import org.apache.mina.core.filterchain.IoFilterAdapter; +import org.apache.mina.core.session.IoSession; +import org.apache.mina.core.write.DefaultWriteRequest; +import org.apache.mina.core.write.WriteRequest; +import
[jira] Commented: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615877#action_12615877 ] Mark Webb commented on DIRMINA-489: --- Rich, I have integrated the code into the version 2.0 baseline (trunk). I am working on some more tests and and trying to figure out the optimal way to create a simple CompositeByteArray containing a bunch of IoBuffers that contain strings. Here is some pseudo-code: CompositeByteArray cba = new CompositeByteArray(); IoBuffer one = IoBuffer.wrap(Hello); cba.put( one ); IoBuffer two = IoBuffer.wrap(Mina); cba.put( two ); IoBuffer three = IoBuffer.wrap(World); cba.put( three ); System.out.println( cba ); I would like to see the contents of all 3 IoBuffers printed out together. Of course this simple example would be expanded to include more testing, but I have tried a couple different scenarios on putting multiple IoBuffers into an instance of the CompositeByteArray and have been unsuccessful in getting a single buffer back out. Is maybe CompositeByteArray not the correct class? Thanks Composite IoBuffer -- Key: DIRMINA-489 URL: https://issues.apache.org/jira/browse/DIRMINA-489 Project: MINA Issue Type: New Feature Components: Core Reporter: David M. Lloyd Fix For: 2.0.0-M3 Attachments: mina-composite-20080515.patch.gz, mina-composite-20080517.patch, mina-composite-20080521-2.patch, mina-composite-20080521.patch Provide a way to create a large IoBuffer from several smaller IoBuffers, without copying the underlying data. It would probably be acceptable to constrain the composite buffer in various ways, for example by disallowing autoexpanding or otherwise changing the capacity, the implementation could be greatly simplified. The goal is to be able to process large messages with a minimum of copying. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How to use a SingleSessionIoHandler?
If you are using a NioSocketAcceptor, then check out org.apache.mina.transport.socket.nio.NioSession or another option is to create a class that implements the org.apache.mina.handler.multiton.SingleSessionIoHandlerFactory. For an example, take a look at org.apache.mina.transport.socket.nio.NioSocketSession. On Mon, Jul 21, 2008 at 2:45 AM, Geert Schuring [EMAIL PROTECTED] wrote: Looking at at classes extending AbstractIoSession doesn't clear anything up for me... am i missing something here? My question was: How do i register a SingleSessionIoHandler with the acceptor? - Original Message From: Mark Webb [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED], Geert Schuring [EMAIL PROTECTED] Subject: Re: How to use a SingleSessionIoHandler? Date: 21/07/08 04:00 Depending on what type of service you are writing, take a look at classes extending AbstractIoSession.On Thu, Jul 17, 2008 at 11:19 AM, Geert Schuring lt;[EMAIL PROTECTED]gt; wrote: Hey all, Im writing an IoHandler extending SingleSessionIoHandlerAdapter (mina 2.0.0-M2). When doing so Eclipse doesn#39;t allow me to add a no-argument constructor saying: quot;Implicit super constructor SingleSessionIoHandlerAdapter() is undefined. Must explicitly invoke another constructorquot; So i end up adding a Constructor that has an IoSession argument. Great and all, of course, but how do i add this handler to the acceptor? The acceptor has no method to add a SingleSessionIoHandler. Geert Schuring The Netherlands. Message sent using UebiMiau 2.7.10 Message sent using UebiMiau 2.7.10
Re: svn commit: r678238 - in /mina/trunk/core/src/main/java/org/apache/mina/filter/buffer: ./ BufferedWriteFilter.java
I have a question on this class.
Why not use ConcurrentHashMap for this instead of synchronizing? Or
CopyOnWriteMap?
On Sat, Jul 19, 2008 at 7:19 PM, [EMAIL PROTECTED] wrote:
Author: edeoliveira
Date: Sat Jul 19 16:19:14 2008
New Revision: 678238
URL: http://svn.apache.org/viewvc?rev=678238view=rev
Log:
New IoFilter that implements DIRMINA-519
Added:
mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/
mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java
(with props)
Added:
mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java
URL:
http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java?rev=678238view=auto
==
---
mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java
(added)
+++
mina/trunk/core/src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java
Sat Jul 19 16:19:14 2008
@@ -0,0 +1,243 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ *http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.mina.filter.buffer;
+
+import java.io.BufferedOutputStream;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.mina.core.buffer.IoBuffer;
+import org.apache.mina.core.filterchain.IoFilter;
+import org.apache.mina.core.filterchain.IoFilterAdapter;
+import org.apache.mina.core.session.IoSession;
+import org.apache.mina.core.write.DefaultWriteRequest;
+import org.apache.mina.core.write.WriteRequest;
+import org.apache.mina.filter.codec.ProtocolCodecFilter;
+
+/**
+ * An [EMAIL PROTECTED] IoFilter} implementation used to buffer outgoing
[EMAIL PROTECTED]
WriteRequest} almost
+ * like what [EMAIL PROTECTED] BufferedOutputStream} does. Using this filter
allows
to be less dependent
+ * from network latency. It is also useful when a session is generating
very small messages
+ * too frequently and consequently generating unnecessary traffic
overhead.
+ *
+ * Please note that it should always be placed before the [EMAIL PROTECTED]
ProtocolCodecFilter}
+ * as it only handles [EMAIL PROTECTED] WriteRequest}'s carrying [EMAIL
PROTECTED] IoBuffer}
objects.
+ *
+ * @author The Apache MINA Project (dev@mina.apache.org)
+ * @version $Rev: $, $Date: $
+ * @since MINA 2.0.0-M2
+ */
+public final class BufferedWriteFilter extends IoFilterAdapter {
+
+/**
+ * Default buffer size value in bytes.
+ */
+public final static int DEFAULT_BUFFER_SIZE = 8192;
+
+/**
+ * The buffer size allocated for each new session's buffer.
+ */
+private int bufferSize = DEFAULT_BUFFER_SIZE;
+
+/**
+ * The map that matches an [EMAIL PROTECTED] IoSession} and it's [EMAIL
PROTECTED] IoBuffer}
+ * buffer.
+ */
+protected MapIoSession, IoBuffer buffersMap = new HashMapIoSession,
IoBuffer();
+
+/**
+ * Default constructor. Sets buffer size to [EMAIL PROTECTED]
#DEFAULT_BUFFER_SIZE}
+ * bytes.
+ */
+public BufferedWriteFilter() {
+this(DEFAULT_BUFFER_SIZE);
+}
+
+/**
+ * Constructor which sets buffer size to codebufferSize/code.
+ *
+ * @param bufferSize the new buffer size
+ */
+public BufferedWriteFilter(int bufferSize) {
+super();
+this.bufferSize = bufferSize;
+}
+
+/**
+ * Returns buffer size.
+ */
+public int getBufferSize() {
+return bufferSize;
+}
+
+/**
+ * Sets the buffer size but only for the newly created buffers.
+ *
+ * @param bufferSize the new buffer size
+ */
+public void setBufferSize(int bufferSize) {
+this.bufferSize = bufferSize;
+}
+
+/**
+ * [EMAIL PROTECTED]
+ *
+ * @throws Exception if codewriteRequest.message/code isn't an
+ * [EMAIL PROTECTED] IoBuffer} instance.
+ */
+@Override
+public void filterWrite(NextFilter nextFilter, IoSession session,
+WriteRequest writeRequest) throws Exception {
+
+Object data =
[jira] Created: (DIRMINA-611) Move ExceptionMonitor from core to util
Move ExceptionMonitor from core to util --- Key: DIRMINA-611 URL: https://issues.apache.org/jira/browse/DIRMINA-611 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 2.0.0-M2 Environment: All Reporter: Mark Webb Assignee: Mark Webb Priority: Trivial Fix For: 2.0.0-M3, 1.0.11, 1.1.8 This was discussed in the dev mailing list. I forgot to make the change at the time, but many people agreed that this should be done just to keep with the new organization of the source code tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-611) Move ExceptionMonitor from core to util
[ https://issues.apache.org/jira/browse/DIRMINA-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb closed DIRMINA-611. - Resolution: Fixed Fix Version/s: (was: 1.1.8) (was: 1.0.11) Updated the trunk and checked in changes. Move ExceptionMonitor from core to util --- Key: DIRMINA-611 URL: https://issues.apache.org/jira/browse/DIRMINA-611 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 2.0.0-M2 Environment: All Reporter: Mark Webb Assignee: Mark Webb Priority: Trivial Fix For: 2.0.0-M3 Original Estimate: 0.08h Remaining Estimate: 0.08h This was discussed in the dev mailing list. I forgot to make the change at the time, but many people agreed that this should be done just to keep with the new organization of the source code tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615139#action_12615139 ] Mark Webb commented on DIRMINA-489: --- Rich, Thanks for the work that you have done on this. Could you please tell me if the mina-composite-20080521-2.patch is the latest version of the patch. There have been many MINA source code structure changes and want to try integrating your code. Thanks Mark Composite IoBuffer -- Key: DIRMINA-489 URL: https://issues.apache.org/jira/browse/DIRMINA-489 Project: MINA Issue Type: New Feature Components: Core Reporter: David M. Lloyd Fix For: 2.0.0-M3 Attachments: mina-composite-20080515.patch.gz, mina-composite-20080517.patch, mina-composite-20080521-2.patch, mina-composite-20080521.patch Provide a way to create a large IoBuffer from several smaller IoBuffers, without copying the underlying data. It would probably be acceptable to constrain the composite buffer in various ways, for example by disallowing autoexpanding or otherwise changing the capacity, the implementation could be greatly simplified. The goal is to be able to process large messages with a minimum of copying. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-586) Dynamic delimiter support for TextLineCodecFactory
[ https://issues.apache.org/jira/browse/DIRMINA-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615140#action_12615140 ] Mark Webb commented on DIRMINA-586: --- Please let me know if this is still an issue. I believe that if we make a change to the current functionality, it might break current implementations. This fix may require a special class, instead of changes to the current implementation. Please let me know what you think. I am considering closing this issue and marking as will not fix Dynamic delimiter support for TextLineCodecFactory -- Key: DIRMINA-586 URL: https://issues.apache.org/jira/browse/DIRMINA-586 Project: MINA Issue Type: Improvement Components: Filter Affects Versions: 2.0.0-M1 Reporter: Trustin Lee Priority: Minor Fix For: 2.0.0-M3 TextLineCodecFactory supports static delimiters only. For some cases, users need to switch the delimiter dynamically depending on context. Related discussion is found here: http://markmail.org/message/loiqoej35evt2yvv -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Is the ExceptionMonitor usefull ?
+1. Its not hurting anything being there, and unless you know what its for, you will probably not use it. On Mon, Jul 7, 2008 at 3:43 PM, Adam Fisk [EMAIL PROTECTED] wrote: I'd just like to chime in with a vote for staying focused. If this is not causing problems for people and people are using it, it should stay, so I'm also a -1 on making the change. That said, it's most importantly not a big issue and should be barely visible on the priority list. Getting 2.0 out the door should be the overarching focus of MINA right now, and things like this distract from that. I know it's always tempting to tweak code to one's liking as you make your way through it, but it's an important temptation to resist! All the Best, -Adam On Mon, Jul 7, 2008 at 1:30 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: peter royal wrote: On Jul 5, 2008, at 1:36 PM, Emmanuel Lecharny wrote: - as it's a framework, I think that exceptions, if they are to be caught, should be caught at the upper level, not down in the code. Why the hell do we have to define a generic monitor which does nothing more than logging a warning ? I don't really care to keep it into the code base, I just don't see any of the advantages it brings. I may miss something ... Can you give me a clear exemple, Peter ? the monitor would allow a user to replace the functionality with one that throws rather than logs.. we just decided that logging is the best policy. we could just make it throw. in the custom implementation i last used, - if the exception is an InterruptedException, just ignore, but set the interrupted state on the current thread - certain exception types were ignored, no logging. - certain exceptions were logged at debug - catch-all was similar to what we ship I see where you are going to. The problem to me is that the current implementation is really not good. First it's not documented correctly, or should I say, advertized, so the user have no clue what he will get if he implements the Monitor, second, it's a singleton, a very bad thing in a J2EE environment. And as MINA is a framework, I also think that it should always throw an exception, and log something. Simply logging is not, IMO, enough. In certain cases, we don't know what will happen if we use the default implementation. For instance, you may swallow a OOM exception without doing nothing but logging. Do you think it's a good way to handle such exceptions ? .. but the specifics of how i used it aside.. I agree. i think the idea that it promotes is fine. Well, I'm not on the same line :) its not a piece of the codebase that's been causing issues at all :) That, I agree. I just don't like the idea of ExceptionMonitor, at least the way it is used in MINA. It's pretty much a thread likely to be dead soon, as I don't want to argue forever about a very side element of the project. Just wanted to point out an opinion, but don't want to push it to a point we have to get a veto from someone :) As far as we get this piece of code self-explanatory in the Javadoc, it's fine... Thanks Peter ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org -- http://www.littleshoot.org Open Source, Open Standards, Open Data
Re: Is the ExceptionMonitor usefull ?
one additional note I have is that maybe it should be moved from core to util. That way the package name indicates that it is a utility class and not a core class. On Mon, Jul 7, 2008 at 7:23 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: +1. Its not hurting anything being there, and unless you know what its for, you will probably not use it. Funny :) I guess that now that I have posted the first mail, there are more people aware about this class than ever, and now the risk is that we may have to deal with it, as some may want to implement an inherited class, when remaining silent and saying nothing about it would have let this class hidden and unused forever ;) Sometime it's better to push the dust under the carpet and shut up :) Ok, I'm done with MonitorException, moving to some more useful things ! Thanks guys ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [VOTE] Release 2.0.M2
[ X]: +1, Release MINA 2.0-M1 On Fri, Jun 27, 2008 at 5:30 AM, Julien Vermillard [EMAIL PROTECTED] wrote: Hi, After a lot of package reorganisation, look like it's the moment for releasing 2.0M2. Here you can see the list of FIXED issues since M1 and the one still OPEN : https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel This release is not a stable one, some API change will probably occurs like ByteBuffers, sendFile(), but it will help to get more feed back for about last changes. Julien, Now let's vote ! [ ]: +1, Release MINA 2.0-M1 [ ]: 0, Abstain [ ]: -1, Don't release MINA 2.0-M1
Re: Java Threads are my problem.
You are right. This is not MINA-specific. Not sure what you are trying to accomplish here with MINA. On Sun, Jun 22, 2008 at 9:59 PM, Simon Funnell [EMAIL PROTECTED] wrote: Dear List, This is not exactly Mina specific, its more general, but its close to the problem Mina surrounds. I have been working on an approach to concurrency and I have come to the point where the Java Thread model is causing me problems. I would like to create my own threading model that does away with shared memory and thread memory, so there is just shared memory. My original idea was to use a single thread and implement my own threads within that thread. The difficulty with this is that there is still copying from shared memory to thread working memory (as I understand it). I would like to cut out this shared memory to thread memory and back to shared memory copying. Is this possible? Thanks for any replies. Regards, Simon
Re: [New Committer] Welcome to Rich Dougherty
Glad to have another on board !! On Fri, Jun 20, 2008 at 4:40 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: Welcome Rich ! Maarten On Fri, Jun 20, 2008 at 9:41 PM, Rich Dougherty [EMAIL PROTECTED] wrote: On Sat, Jun 21, 2008 at 3:30 AM, Julien Vermillard [EMAIL PROTECTED] wrote: Rich Dougherty was voted as a new Apache MINA committer with 7 +1 vote and no abstain nor -1. He's well know here for the MINA Scala binding and his overall interest for MINA internals. Welcome aboard Rich ! Thanks everyone, I'm pleased to join the team! Rich
Re: Some Class diagram for MINA
very nice. keep them coming. On Wed, Jun 18, 2008 at 10:08 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, I have drawn three class diagrams of basic MINA structures (IoSession and IoService, divided in Acceptor and Connector) and put them on the wiki : http://cwiki.apache.org/confluence/display/MINA/Class+Diagrams It may help those who want to get a better picture of the inheritence scheme. Have fun ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Some Class diagram for MINA
Did you do this by hand or use a tool? On Wed, Jun 18, 2008 at 11:55 AM, Alex Karasulu [EMAIL PROTECTED] wrote: On Wed, Jun 18, 2008 at 11:43 AM, Mark Webb [EMAIL PROTECTED] wrote: very nice. keep them coming. Mark and I had at one point discussed a documentation plan and looks like you beat us to the first stage. This is looking great. Thanks for taking the initiative. Alex On Wed, Jun 18, 2008 at 10:08 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, I have drawn three class diagrams of basic MINA structures (IoSession and IoService, divided in Acceptor and Connector) and put them on the wiki : http://cwiki.apache.org/confluence/display/MINA/Class+Diagrams It may help those who want to get a better picture of the inheritence scheme. Have fun ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: AbstratPollingStuff... renaming
sounds good to me. On Tue, Jun 10, 2008 at 9:44 AM, Julien Vermillard [EMAIL PROTECTED] wrote: Hi, as Emmanuel stated, the AbstractPollingIoXXX class are badly named. The polled is here because it's base classes for transport implementations using event strategy based on system calls behaving like poll() (which can be in fact poll, epoll, kqueue or select depending of the JVM/OS configuration). Those class aren't polling in a loop for checking session status, it's the law level kernel/system implementation which does it. So I we need to rename it to something making more sense and it's javadoc less, so it's an opportunity to document this important part of MINA internals ;) I propose - AbstractEventIo(Acceptor/Connector/..) - AbstractSelectIo(Acceptor/Connector/..) - AbstractAsyncIo(Acceptor/Connector/..) even the Io could be removed. WDYT ? Julien
Re: [2.0 refactoring] What about splitting mina-core ?
+1 On Mon, Jun 9, 2008 at 1:31 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I don't really have a specific view point on this topic. I would rather have more efficient and easily maintained internals. I don't know if this accomplishes that but I'm sure you guys can hash that out. Regards, Alex On Mon, Jun 9, 2008 at 1:07 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: I do not think this is a good idea. Looking at the three answers, it seems so ;) 3. We may confuse things for alot of people who may already be using 2.0. Telling users that they will have to fix their code because of a re-organization looks bad on our part IMHO. Regardless to the refactoring question, this is the kind of risk we have to consider, in any case. More than confusing the users who have based their code on the current 2.0 stack, I think it's much more important to build a coherent stack we will live with for a long time. Waiting for a 3.0 version and differing refactoring just because we have users of the current trunk is certainly not a good idea. Trunk is trunk, using it is a risk, and it's well know. Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [2.0 refactoring] What about splitting mina-core ?
I do not think this is a good idea. 1. You are assuming that everyone uses maven. 2. Based on many of the discussions that have been going on with this group, I believe that we have more important issues to consider. 3. We may confuse things for alot of people who may already be using 2.0. Telling users that they will have to fix their code because of a re-organization looks bad on our part IMHO. On Sun, Jun 8, 2008 at 3:26 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Niklas Gustavsson wrote: On Sat, Jun 7, 2008 at 2:59 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Thoughts ? My feeling is that the cons outweigh the pros. Having multiple JARs commonly turns out to confuse users, especially with a setup where you can even get the very basic functionality working without choosing your combination of JARs. With Maven, this is not really a big issue, IMHO. Consider that it's a one time burden... Now, if it degenerate to a dozens of jars, yes, I + your point. But even if we keep only one jar, I think we still have to create some new packages, because we have a big bag of classes in common, which make it quite difficult to find what are the relations between each classes. In addition, the current core JAR is about 500 kb, not huge. I didn't even mentioned the size in the pros ;) thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: chat server often deaded with mina 2.0-m1
is the system deadlocking or running out of memory? On Wed, May 28, 2008 at 10:32 AM, Owen Gu [EMAIL PROTECTED] wrote: Hi, Our chat server is deveolped with mina-2.0 m1 version, we got a very emergent problem, the chat server dead every week. The attachment contains thread dump that was generated when we made the server dead by some testing tools, I think the dead lock or out of memory problem caused the server down. Please help me to solove this problem, it's very emergent, thank you.
Re: chat server often deaded with mina 2.0-m1
I had noticed some deadlock conditions as well, but after you mentioned you ran into an out of memory error I got confused. I will take a look at this again when I get a free minute. On Wed, May 28, 2008 at 11:23 AM, Owen Gu [EMAIL PROTECTED] wrote: Please check the thread dump, it seems the NioProcessor-2 thread was blocked and lock the object 0x49958e38, and the other NioProcessor were waiting for the object 0x49958e38, I think this caused deadlock. But after I used jstack dump the thread one minutes, I saw the system alert out of memory, So I'm not sure what caused my server dead, please help me analyse the thread dump, thanks. On Wed, May 28, 2008 at 10:58 PM, Mark Webb [EMAIL PROTECTED] wrote: is the system deadlocking or running out of memory? On Wed, May 28, 2008 at 10:32 AM, Owen Gu [EMAIL PROTECTED] wrote: Hi, Our chat server is deveolped with mina-2.0 m1 version, we got a very emergent problem, the chat server dead every week. The attachment contains thread dump that was generated when we made the server dead by some testing tools, I think the dead lock or out of memory problem caused the server down. Please help me to solove this problem, it's very emergent, thank you.
Re: Could mina write the message directly before using a selector
The easiest way I know of to decrease latency is to cut down on the filters you are using. This includes thread pools as well. Have you read this page: http://mina.apache.org/configuring-thread-model.html? It might help you along... 2008/5/28 Owen Gu [EMAIL PROTECTED]: Hi, Thanks for your reply, I know a good framework will not expose the SocketChannel directly, I guess you could add some filter to solve the problem, could you tell me an approximate time I can get the low latency version, I don't want wait a long time, because it's a big problem for me:P, or could give me some hint so I can solve the problem by myself before I get the new version. On Wed, May 28, 2008 at 11:26 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: Hi Owen, It's a known issue and should be dealt with before MINA 2 RC1. However, we should not expose SocketChannel directly - we should assure low latency even without doing so. HTH, On Thu, 29 May 2008 00:15:02 +0900, Owen Gu [EMAIL PROTECTED] wrote: Hi, A lot of our users complain about the latency problem, If mina could write the message directly before using a selector to dectect whether the SocketChannel could be written and when the message counln't be sent completly, using a selector to write the remaining messages, I think the latency problem will better than now. -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: svn commit: r659372 - /mina/branches/buffer/core/src/main/java/org/apache/mina/queue/DefaultByteBufferQueue.java
since when do people on mailing lists no longer get to voice opinions? What then would be the purpose of a mailing list? On Fri, May 23, 2008 at 1:14 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Fri, May 23, 2008 at 1:04 PM, Stefano Bagnara [EMAIL PROTECTED] wrote: Emmanuel Lecharny ha scritto: Now, considering your attitude : your are sometime just behaving like a stubborn childish person. You are interpreting the ASF rules at your own advantage, with no respect for person around you. Like it or not, this is not the way it works. When I asked you to revert the code, this is because we reached a point where we have to discuss the portion of code you have committed, it was not a punishment. But you took it as if I wanted to personally insult you, and you insulted me in return. I will swallow the insult, because it's just totally irrelevant to the discussion. My opinion is that you behaved very bad too. There was a discussion in place, and there was no need to veto this until every solution was evaluated. You didn't try to understand the why, propose something different, evaluate pros/cons of what have been done and what you proposed before vetoing it. This is only my opinion as an ASF committer have only a user role in mina. No one asked for your precious opinion. You don't have a grasp of the situation at all. So stop adding to the fire. LET THE THREAD DIE! We need to move on. Alex
Re: svn commit: r659372 - /mina/branches/buffer/core/src/main/java/org/apache/mina/queue/DefaultByteBufferQueue.java
heh. how do we all feel now? Pretty embarrassing http://bill.burkecentral.com/2008/05/23/see-why-id-never-develop-at-apache/ On Fri, May 23, 2008 at 1:40 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Stefano Bagnara wrote: Alex Karasulu ha scritto: On Fri, May 23, 2008 at 1:04 PM, Stefano Bagnara [EMAIL PROTECTED] wrote: This is only my opinion as an ASF committer have only a user role in mina. No one asked for your precious opinion. You don't have a grasp of the situation at all. So stop adding to the fire. This is very community oriented ;-) I will tell another opinion from mine even if no one asked it. My opinion is that ASF is about community, and I feel part of this community, and I have the same rights to express my opinion as you do. Peace, Stefano Guys, just consider that not agree with the other one does not mean you are right. I would suggest we start another thread about Javadoc good practice, if everyone thinks it's necessary, and cut a decision in this thread. I think that everything is set now, whatever opinion everyone has. I have nothing to add, Trustin added some @inheritdoc tags, I have withdrawn my veto, end of story. Let's this thread die... Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: MINA + Grizzly discussion
Jeanfrancois, Welcome. I have been a big fan of your work and have enjoyed your blog over the years. I will say that I am one of the 'young' ASF members on the MINA team and welcome any synergies that will be created as a result of us coming together. --Mark On Wed, May 21, 2008 at 9:57 AM, Julien Vermillard [EMAIL PROTECTED] wrote: Hi, First great to hear you ! On Wed, 21 May 2008 09:44:00 -0400 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Hi, before we can have the discussion, I need to make sure every body agree (all other commiters :-)) to start a discussion on the grizzly side. So gives me a couple of days :-) No problems, we are patient/lazy peoples :) [cut] agreed. We could talk about: * the possibility of merging two projects in the future (not sure this will happen) * the regular exchange of each other's knowledge at least * and anything you want to talk about, probably except for offending each other's framework? :) +1 I will add: + Have a new JSR filled (OK, might not be the best thing for Apache right now to talk about JSR). *joker* about JSR :) Note that before the discussion start, I just want to make sure peoples here are aware how bad it when the last time we have worked on an Apache project (Tomcat), mostly because peoples mixed people working at Sun vs Sun as a company. I can't speak for my colleague, but I will not enter any feud/war with the MINA community on the usual Sun-bashing exercise. You can destroy/criticize Grizzly (and me :-)), and that one is fine. But the anti-Sun complains a lot of Apache members like sometimes to start is something I would like to avoid :-) A+ About the past you need to take in account a lot of MINA PMC/commiters are young at ASF. I think it's a great opportunity for us to avoid the parasitic ASFvsSUN heritage and try to find a common ground for collaboration. A+ Julien
Re: MINA + Grizzly discussion
Either email or IRC works for me. I am EDT (GMT-4). On Sat, May 17, 2008 at 10:30 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: I've just came to think that we might be able to make this discussion occur via e-mail exchange, by cross posting to [EMAIL PROTECTED] and grizzly dev list. It will make the conversation more transparent and let more people get involved. WDYT? PS: I'm on UTC+9 ;) On Sun, 18 May 2008 08:38:09 +0900, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Guys, last week, Trustin was in SF for Java One. He met Jean-François Arcand, and had some interesting convo there. Here is a copy of is mail about it : Hi, I met Jean-francois Arcand, the Grizzly lead last week in JavaOne, and he showed his interest in joining the effort to build better network application framework together. I suggested an IRC chat at #mina, and he agreed. We could talk about: * the possibility of merging two projects in the future (not sure this will happen) * the regular exchange of each other's knowledge at least * and anything you want to talk about, probably except for offending each other's framework? :) It would be nice if we can have this chat next week. Please let me know when you are available, so I can tell them what date and time we prefer. Cheers, As he is suggesting a chat session with JF, please fill free to tell when would be the best timing for such an IRC meeting (keep in mind that Trustin is UTC-7 and that it is really important to have him around. Just push your best timeframe, not forgetting your UTC increment/decrement. Thanks ! -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: JIRA for documentation ?
+1. Although a full-time documentation person would have a hard time keeping up. I tried for a while, but it was tough. On Thu, May 1, 2008 at 12:03 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Thu, May 1, 2008 at 10:30 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, some users (Frederic) suggested to create a dedicated JIRA for documentation. Do you think it's a good idea to have a MINA-DOC JIRA entry ? Otherwise, I went to the MINA web page looking for some information about the sources, and I found it quite difficult to find. IMHO, there should be a 'source' link in the main menu, on the left, where you can find pointers to the tarball distributions, the svn links and such. +1 I'd like to see the site documentation improve and keep up with the changes. Another alternative to consider would be to create a module for the MINA JIRA project if people are fearful of a JIRA project explosion. Alex -- Talent hits a target no one else can hit; Genius hits a target no one else can see.
Re: MINA v2.0 Quick Start Guide
ok. So we agree. We were just describing it differently. I will start working on it and see how things turn out. Thanks... On Thu, Apr 10, 2008 at 3:40 AM, Maarten Bosteels [EMAIL PROTECTED] wrote: Hi, 2008/4/10 Mark Webb [EMAIL PROTECTED]: Sorry for the mis-typing of your name no worries. The more I think about this, the more I think that each step should be a stand-alone program. Step 2 should include all the code from step 1 and the code that was introduced in step 2. For instance, in step 1 you might have : IoAcceptor acceptor = new NioSocketAcceptor(); acceptor.setHandler( new MyHandler() ); acceptor.bind( new InetSocketAddress(PORT)); Then when you introduce step 2, you will add in an ExecutorFilter to all the code above. That's what I meant: in step2 you have another main, that builds the IoFilter chain all by itself. So that would be copy-paste from step1 with an ExecutorFilter added. But I see no point, in copying for example the custom encoder/decoder from step1 to step2 ? When entire classes from step-n are reused in step-(n+1), there is IMO no reason to copy them. Then when you introduce step 3, you will add JMX code to the code that includes steps 1 and 2. So by the time you reach the end, the code in step 1 (above) will contain much more code and not be so simple and understandable and the person reading the tutorial might get confused. I agree. After adding step2, the code in step1 shouldn't have changed. That's the reason I called it step1 :-) regards, Maarten --Mark On Wed, Apr 9, 2008 at 4:23 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: Hello Mark, Great to hear you will have some time to work on the examples. 2008/4/9 Mark Webb [EMAIL PROTECTED]: I hit the send button much too quickly. Maartin, what is your plan for how the codebase will look? I see that in the examples subproject there is a package called imagine.step1. For step 2, will you take a copy of all the code from step 1 and add more functionality (like ExecutorFilter)? I think most of the code from step1 can be reused by step2 etc, so there would be no need to copy code. IMO, the imagine.step2 package should only contain the code that needs to be added or changed compared to step1. Probably only the main method where the filterChain is built. But feel free to disagree :-) regards, Maarten (not Maartin) How do you see all this coming together? --Mark 2008/4/9 Mark Webb [EMAIL PROTECTED]: I have some free time coming up. I will give it a shot. On Wed, Apr 9, 2008 at 1:29 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 6:08 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: I think it's good time for someone to write a MINA curriculum and revamp all examples to follow the curriculum. Maarten once started an 'imagine' example but he ended up with stage1. He might have something in his mind about setting up the MINA curriculum. ;) :-) Yes, my plan was to build upon the ImageServer and add extra functionality step-by-step * step1: what is now in the protocol-codec tutorial (and in svn) * step2 : add an ExecutorFilter * step3 : add some JMX stuff * step4 : show how to cleanly shut down the server * step5 : add a throttle filter ... (the order doesn't really matter) Unfortunately, until now I didn't get further than step1 ... I still have the intention though, just can't promise when I will find that scarce resource called time. I'd welcome anyone who wants to work on this. Maarten Cheers, Mark Webb wrote: that is the funniest description of one's software I ever heard. bravo... On Wed, Apr 9, 2008 at 10:25 AM, Niklas Gustavsson [EMAIL PROTECTED] wrote: 2008/4/9 Mark Webb [EMAIL PROTECTED]: sounds like that is the direction we want to go. My only concern is that we start getting apps in the examples directory that overlap. There is currently a chat program in examples, but maybe your's is more feature-rich or more robust. One think I do like about the current chat example is that it is the only example that uses Spring. No it's certainly not more feature rich, it's probably the stupidest chat server ever built. The purpose was to make it as simple as possible to be able to communicate it during a talk. /niklas -- Trustin
Re: MINA v2.0 Quick Start Guide
Niall, Thanks for pointing this out to me. I have updated the wiki and also placed the code into my sandbox. You may access the code at: http://svn.apache.org/repos/asf/mina/sandbox/mwebb/mina/src/main/java/org/apache/mina/gettingstarted/timeserver/ --Mark On Wed, Apr 9, 2008 at 5:19 AM, Niall Pemberton [EMAIL PROTECTED] wrote: The MINA v2.0 Quick Start Guide needs updating for the current API http://mina.apache.org/mina-v20-quick-start-guide.html In the last MinaTimeServer code snippet it has... acceptor.setLocalAddress( new InetSocketAddress(PORT) ); acceptor.bind(); ...but setLocalAddress() doesn't exist (in Mina 2.0.0-M1) - should be changed to setDefaultLocalAddress() or replace those lines with acceptor.bind(new InetSocketAddress(PORT)); The other thing is the lines added in the 3rd MinaTimeServer code snippet have been dropped from the 4th(last) code snippet, i.e. acceptor.getSessionConfig().setReadBufferSize( 2048 ); acceptor.getSessionConfig().setIdleTime( IdleStatus.BOTH_IDLE, 10 ); Niall -- Talent hits a target no one else can hit; Genius hits a target no one else can see.
Re: MINA v2.0 Quick Start Guide
will do... On Wed, Apr 9, 2008 at 8:59 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: Why don't you include it into the trunk? There's an example module already. Cheers, Mark Webb wrote: Niall, Thanks for pointing this out to me. I have updated the wiki and also placed the code into my sandbox. You may access the code at: http://svn.apache.org/repos/asf/mina/sandbox/mwebb/mina/src/main/java/org/apache/mina/gettingstarted/timeserver/ --Mark On Wed, Apr 9, 2008 at 5:19 AM, Niall Pemberton [EMAIL PROTECTED] wrote: The MINA v2.0 Quick Start Guide needs updating for the current API http://mina.apache.org/mina-v20-quick-start-guide.html In the last MinaTimeServer code snippet it has... acceptor.setLocalAddress( new InetSocketAddress(PORT) ); acceptor.bind(); ...but setLocalAddress() doesn't exist (in Mina 2.0.0-M1) - should be changed to setDefaultLocalAddress() or replace those lines with acceptor.bind(new InetSocketAddress(PORT)); The other thing is the lines added in the 3rd MinaTimeServer code snippet have been dropped from the 4th(last) code snippet, i.e. acceptor.getSessionConfig().setReadBufferSize( 2048 ); acceptor.getSessionConfig().setIdleTime( IdleStatus.BOTH_IDLE, 10 ); Niall -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/ -- Talent hits a target no one else can hit; Genius hits a target no one else can see.
