[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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=12577686#action_12577686 ] Mark Webb commented on DIRMINA-258: --- I have the code compiling and running with the 2.0 baseline. I have checked it into my sandbox and will migrate it over to the examples after I go through the code one more time. Here is the link to the code: http://svn.apache.org/repos/asf/mina/sandbox/mwebb/mina/src/main/java/org/apache/mina/example/xml/ 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.
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576998#action_12576998 ] Mark Webb commented on DIRMINA-527: --- What is the purpose of the MINIMUM_CONNECT_TIMEOUT field? If it can be changed via a call to setConnectTimeoutMillis(long), then why have it? Trustin mentions in the TODO: Make this configurable and automatically adjusted if the timeout a user specified is smaller than the current minimum connect timeout. So if the minimum connection timeout and connection timeout can both be configured, why not just have one field? The only way this makes sense to me is that if you try and set the connection timeout to be lower than the minimum we should throw an exception. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-514) Session closing problem on Mac OS X
[ https://issues.apache.org/jira/browse/DIRMINA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577133#action_12577133 ] Mark Webb commented on DIRMINA-514: --- I was just posting the output of tcpdump. I did not analyze the results too well. The JDK1.6 that I am using is a developer release from Apple. I will look deeper into this tonight. Session closing problem on Mac OS X --- Key: DIRMINA-514 URL: https://issues.apache.org/jira/browse/DIRMINA-514 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M1 Environment: Mac OS X 10.4 with Java 1.5.0_07 -87 Reporter: Matteo Merli Fix For: 2.0.0-M2 Attachments: Echo1_1.java, Echo2_0.java A call to session.close() does not send a FIN packet althought MINA will considers the session as closed. I've attached two test cases, one that works with MINA 1.1 (and works fine) and other with MINA 2.0 that doesn't close connections. This is a simple echo server that receives a message, writes it back to the client and (should) close the connection. This problem is *NOT* ocurring on Linux where the same test case works fine. It only shows up on Mac OS X. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-514) Session closing problem on Mac OS X
[ https://issues.apache.org/jira/browse/DIRMINA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577280#action_12577280 ] Mark Webb commented on DIRMINA-514: --- OK. I run the Echo2_0 class. In a terminal I do the following: - elihusmails$ telnet localhost 9090 Trying ::1... Connected to localhost. Escape character is '^]'. hello hello Connection closed by foreign host. - As soon as I type in hello, I get the Connection closed by foreign host. I get this with Java 6, but not in Java 5. So I think this is a problem with Java 5. Session closing problem on Mac OS X --- Key: DIRMINA-514 URL: https://issues.apache.org/jira/browse/DIRMINA-514 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M1 Environment: Mac OS X 10.4 with Java 1.5.0_07 -87 Reporter: Matteo Merli Fix For: 2.0.0-M2 Attachments: Echo1_1.java, Echo2_0.java A call to session.close() does not send a FIN packet althought MINA will considers the session as closed. I've attached two test cases, one that works with MINA 1.1 (and works fine) and other with MINA 2.0 that doesn't close connections. This is a simple echo server that receives a message, writes it back to the client and (should) close the connection. This problem is *NOT* ocurring on Linux where the same test case works fine. It only shows up on Mac OS X. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577284#action_12577284 ] Mark Webb commented on DIRMINA-527: --- I have checked in an update that makes the minimum timeout field configurable. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb resolved DIRMINA-527. --- Resolution: Fixed checked in an update that makes the minimum connection timeout field configurable should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577287#action_12577287 ] Mark Webb commented on DIRMINA-527: --- Nothing is really jumping out to me on this one so your idea is fine with me. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-534) AbstractIoSession's getId()
[ https://issues.apache.org/jira/browse/DIRMINA-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576844#action_12576844 ] Mark Webb commented on DIRMINA-534: --- Should this issue be closed then and not fixed? AbstractIoSession's getId() --- Key: DIRMINA-534 URL: https://issues.apache.org/jira/browse/DIRMINA-534 Project: MINA Issue Type: Improvement Affects Versions: 2.0.0-M2 Reporter: Roger Kapsi Priority: Minor Fix For: 2.0.0-M2 I would use System.identityHashCode(this) instead of hashCode() in AbstractIoSession.getId() and you'd have to no longer override equals hashCode() (I assume that's the reason why both methods are overridden final). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb reassigned DIRMINA-527: - Assignee: Mark Webb should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576850#action_12576850 ] Mark Webb commented on DIRMINA-527: --- I have applied the patch associated with this issue. I will go ahead and mark this issue as fixed. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb resolved DIRMINA-527. --- Resolution: Fixed Fix Version/s: 2.0.0-M2 I applied the associated patch after reviewing the patch. This only adds to the precision of the timeout. The methods that dealt with getting and setting the connection timeout in seconds have been deprecated and a note in the javadoc says that the millisecond-based methods should be used. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-514) Session closing problem on Mac OS X
[ https://issues.apache.org/jira/browse/DIRMINA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576854#action_12576854 ] Mark Webb commented on DIRMINA-514: --- This is what I get on my iMac (OS X 10.5.2) java -version java version 1.6.0_04-dp Java(TM) SE Runtime Environment (build 1.6.0_04-dp-b06-110) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_04-b12-45-optimized, mixed mode) 23:38:27.969274 IP6 localhost.64788 localhost.websm: S 3411499079:3411499079(0) win 65535 mss 16324,nop,wscale 2,nop,nop,timestamp 33588472 0,sackOK,eol 23:38:27.969313 IP6 localhost.websm localhost.64788: S 1775328828:1775328828(0) ack 3411499080 win 65535 mss 16324,nop,wscale 3,nop,nop,timestamp 33588472 33588472,sackOK,eol 23:38:27.969322 IP6 localhost.64788 localhost.websm: . ack 1 win 65535 nop,nop,timestamp 33588472 33588472 23:38:27.969331 IP6 localhost.websm localhost.64788: . ack 1 win 65535 nop,nop,timestamp 33588472 33588472 23:38:29.805900 IP6 localhost.64788 localhost.websm: P 1:8(7) ack 1 win 65535 nop,nop,timestamp 33588491 33588472 23:38:29.805926 IP6 localhost.websm localhost.64788: . ack 8 win 65534 nop,nop,timestamp 33588491 33588491 23:38:29.806421 IP6 localhost.websm localhost.64788: P 1:8(7) ack 8 win 65534 nop,nop,timestamp 33588491 33588491 23:38:29.806437 IP6 localhost.64788 localhost.websm: . ack 8 win 65535 nop,nop,timestamp 33588491 33588491 23:38:29.806478 IP6 localhost.websm localhost.64788: F 8:8(0) ack 8 win 65534 nop,nop,timestamp 33588491 33588491 23:38:29.806490 IP6 localhost.64788 localhost.websm: . ack 9 win 65535 nop,nop,timestamp 33588491 33588491 23:38:29.806608 IP6 localhost.64788 localhost.websm: F 8:8(0) ack 9 win 65535 nop,nop,timestamp 33588491 33588491 23:38:29.806623 IP6 localhost.websm localhost.64788: . ack 9 win 65534 nop,nop,timestamp 33588491 33588491 Session closing problem on Mac OS X --- Key: DIRMINA-514 URL: https://issues.apache.org/jira/browse/DIRMINA-514 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M1 Environment: Mac OS X 10.4 with Java 1.5.0_07 -87 Reporter: Matteo Merli Fix For: 2.0.0-M2 Attachments: Echo1_1.java, Echo2_0.java A call to session.close() does not send a FIN packet althought MINA will considers the session as closed. I've attached two test cases, one that works with MINA 1.1 (and works fine) and other with MINA 2.0 that doesn't close connections. This is a simple echo server that receives a message, writes it back to the client and (should) close the connection. This problem is *NOT* ocurring on Linux where the same test case works fine. It only shows up on Mac OS X. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-536) TextLineDecoder throws an IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/DIRMINA-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576484#action_12576484
]
Mark Webb commented on DIRMINA-536:
---
Where does the class TestDecoderOutput come from?
TextLineDecoder throws an IndexOutOfBoundsException
---
Key: DIRMINA-536
URL: https://issues.apache.org/jira/browse/DIRMINA-536
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.0.9, 1.1.6, 2.0.0-M1
Environment: All versions in any environnement
Reporter: Edouard De Oliveira
Fix For: 2.0.0-M2
Original Estimate: 0.25h
Remaining Estimate: 0.25h
Adding the following test to the TextLineDecoderTest JUNIT test class will
raise the bug.
It's due to an incomplete match being incorrectly rewinded that causes the
IndexOutOfBoundsException
public void testSMTPDataBounds() throws Exception {
TextLineDecoder decoder = new
TextLineDecoder(Charset.forName(ISO-8859-1),
new LineDelimiter(\r\n.\r\n));
CharsetEncoder encoder = Charset.forName(ISO-8859-1).newEncoder();
IoSession session = new DummySession();
TestDecoderOutput out = new TestDecoderOutput();
ByteBuffer in = ByteBuffer.allocate(16).setAutoExpand(true);
in.putString(\r\n, encoder).flip().mark();
decoder.decode(session, in.reset().mark(), out);
Assert.assertEquals(0, out.getMessageQueue().size());
in.putString(Body\r\n.\r\n, encoder).flip().mark();
decoder.decode(session, in.reset().mark(), out);
Assert.assertEquals(1, out.getMessageQueue().size());
}
--
To solve the issue, a simple patch is to replace the following line in
org.apache.mina.filter.codec.textline.TextLineDecoder.java :
in.position(in.position()-matchCount);
by
in.position(Math.max(0, in.position()-matchCount));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-534) AbstractIoSession's getId()
[ https://issues.apache.org/jira/browse/DIRMINA-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576023#action_12576023 ] Mark Webb commented on DIRMINA-534: --- I would have to agree with Roger's logic. Looking at the Javadoc for the System.identityHashCode(Object) : Returns the same hash code for the given object as would be returned by the default method hashCode(), whether or not the given object's class overrides hashCode(). The hash code for the null reference is zero. I am not sure that it bothers anything by the AbstractIoSession overriding equals() and hashCode() though... AbstractIoSession's getId() --- Key: DIRMINA-534 URL: https://issues.apache.org/jira/browse/DIRMINA-534 Project: MINA Issue Type: Improvement Affects Versions: 2.0.0-M2 Reporter: Roger Kapsi Priority: Minor Fix For: 2.0.0-M2 I would use System.identityHashCode(this) instead of hashCode() in AbstractIoSession.getId() and you'd have to no longer override equals hashCode() (I assume that's the reason why both methods are overridden final). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-389) Create a Connection Throttle Filter
[ https://issues.apache.org/jira/browse/DIRMINA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576032#action_12576032 ] Mark Webb commented on DIRMINA-389: --- Maybe this could be solved using an ExpiringHashMap. The expiration time would be the length of time that a host cannot have more than one connection. Create a Connection Throttle Filter --- Key: DIRMINA-389 URL: https://issues.apache.org/jira/browse/DIRMINA-389 Project: MINA Issue Type: New Feature Components: Filter Environment: All Reporter: Mark Webb Assignee: Mark Webb Priority: Minor Create a filter that will throttle connections. This filter will monitor newly created sessions and if new connections from the same IP address come in too fast, drop the connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-516) Provide IoHandler.sessionCreating() method
[ https://issues.apache.org/jira/browse/DIRMINA-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561410#action_12561410 ] Mark Webb commented on DIRMINA-516: --- I have a few comments... 1. What logic would go into the sessionCreating() method that would ensure that it completes before sessionCreated() or messageReceived()? I guess whatever logic you are looking to put into the sessionCreated() method would go into your own IoHandler's sessionCreated() method. 2. There are filters that can help you with this problem already. If you cannot find the exact filter, writing a new one is very easy. ..my 2 cents Mark Provide IoHandler.sessionCreating() method -- Key: DIRMINA-516 URL: https://issues.apache.org/jira/browse/DIRMINA-516 Project: MINA Issue Type: Improvement Components: Core Environment: All Reporter: chenliangde is better IoHandler provides a sessionCreating Method, reasons: 1. to take care the things have to be done before session created. Some times messageReceived() is called before sessionCreated() returned. 2. To stop session creation. If the connection count limitation is reached , or the connection comes from blocked IP, the server can prevent the session creation to save resource. Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-516) Provide IoHandler.sessionCreating() method
[ https://issues.apache.org/jira/browse/DIRMINA-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561440#action_12561440 ] Mark Webb commented on DIRMINA-516: --- Why not write a variant of the BlacklistFilter? This should stop the session creation and data reading in time. http://mina.apache.org/report/trunk/xref/org/apache/mina/filter/firewall/BlacklistFilter.html Provide IoHandler.sessionCreating() method -- Key: DIRMINA-516 URL: https://issues.apache.org/jira/browse/DIRMINA-516 Project: MINA Issue Type: Improvement Components: Core Environment: All Reporter: chenliangde is better IoHandler provides a sessionCreating Method, reasons: 1. to take care the things have to be done before session created. Some times messageReceived() is called before sessionCreated() returned. 2. To stop session creation. If the connection count limitation is reached , or the connection comes from blocked IP, the server can prevent the session creation to save resource. Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-478) GzipFilter
[ https://issues.apache.org/jira/browse/DIRMINA-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542944 ] Mark Webb commented on DIRMINA-478: --- Trustin, If you prefer, I can take a look at the code and make sure it meets standards and then check it in. --Mark GzipFilter -- Key: DIRMINA-478 URL: https://issues.apache.org/jira/browse/DIRMINA-478 Project: MINA Issue Type: New Feature Components: Filter Affects Versions: 1.1.4 Reporter: Matthew Giedt Priority: Trivial Attachments: gzip.zip.rename Hi Matt, On Nov 14, 2007 4:47 AM, mgiedt [EMAIL PROTECTED] wrote: I did some poking around and couldn't find a protocol handler for GZip so I created this one. Would very much welcome the communities feedback; MINA team the code is yours to do whatever you wish. (rename the file to 'gzip.zip', bob's your uncle.) Thank you very much for your contribution first of all! :D However, would you mind if you can create a JIRA issue and attach that file there? You have to grant license to the ASF for your work (gzip.zip) when you attach a file. I know it's pain in the butt, but that's the way how legal stuff works. Thanks in advance and best regards, Trustin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-478) GzipFilter
[ https://issues.apache.org/jira/browse/DIRMINA-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542949 ] Mark Webb commented on DIRMINA-478: --- I have only been looking at the code since I posted my previous message, but I would say that this code will require some changes. Like you say, the first thing I noticed was that he is using byte arrays and I think IoBuffers would be better suited for this. I will keep investigating, but not sure about this yet. Another note is that Matt actually wrote this as a CodecFactory and not an IoFilter. It would be my opinion that we keep only the CompressionFilter. Not sure we need a second manner in which to compress/decompress data in MINA. ..my 2 cents GzipFilter -- Key: DIRMINA-478 URL: https://issues.apache.org/jira/browse/DIRMINA-478 Project: MINA Issue Type: New Feature Components: Filter Affects Versions: 1.1.4 Reporter: Matthew Giedt Priority: Trivial Attachments: gzip.zip.rename Hi Matt, On Nov 14, 2007 4:47 AM, mgiedt [EMAIL PROTECTED] wrote: I did some poking around and couldn't find a protocol handler for GZip so I created this one. Would very much welcome the communities feedback; MINA team the code is yours to do whatever you wish. (rename the file to 'gzip.zip', bob's your uncle.) Thank you very much for your contribution first of all! :D However, would you mind if you can create a JIRA issue and attach that file there? You have to grant license to the ASF for your work (gzip.zip) when you attach a file. I know it's pain in the butt, but that's the way how legal stuff works. Thanks in advance and best regards, Trustin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-389) Create a Connection Throttle Filter
[ https://issues.apache.org/jira/browse/DIRMINA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533570 ] Mark Webb commented on DIRMINA-389: --- Couldn't we just change the call to System.currentTimeMillis() to System.nanoTime() http://java.sun.com/javase/6/docs/api/java/lang/System.html#nanoTime() Create a Connection Throttle Filter --- Key: DIRMINA-389 URL: https://issues.apache.org/jira/browse/DIRMINA-389 Project: MINA Issue Type: New Feature Components: Filter Affects Versions: 2.0.0-M1 Environment: All Reporter: Mark Webb Assignee: Mark Webb Priority: Minor Fix For: 2.0.0-M1 Create a filter that will throttle connections. This filter will monitor newly created sessions and if new connections from the same IP address come in too fast, drop the connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-453) Multiple NioSocketAcceptors for one java.nio.Selector
Multiple NioSocketAcceptors for one java.nio.Selector - Key: DIRMINA-453 URL: https://issues.apache.org/jira/browse/DIRMINA-453 Project: MINA Issue Type: New Feature Components: Core Affects Versions: 2.0.0-M1 Environment: All Reporter: Mark Webb Please see the discussion: http://www.nabble.com/multiple-handlers-per-IoService-t4481513s16868.html#a12779214 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-453) Multiple IoServices for one java.nio.Selector
[ https://issues.apache.org/jira/browse/DIRMINA-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb updated DIRMINA-453: -- Description: Please see the discussion: http://www.nabble.com/multiple-handlers-per-IoService-t4481513s16868.html#a12779214 Based on discussions with Trustin, this is functionality that will be in the 2.0 release. It seems to be inefficient to create a new selector/thread for each IoService. This means that an application that is listening on 2 ports, would need two java.nio.Selectors, two Selector worker threads and each have a pool of workers. Not only does this create much duplication, but more threads will be created than may be necessary. was: Please see the discussion: http://www.nabble.com/multiple-handlers-per-IoService-t4481513s16868.html#a12779214 Summary: Multiple IoServices for one java.nio.Selector (was: Multiple NioSocketAcceptors for one java.nio.Selector) Multiple IoServices for one java.nio.Selector - Key: DIRMINA-453 URL: https://issues.apache.org/jira/browse/DIRMINA-453 Project: MINA Issue Type: New Feature Components: Core Affects Versions: 2.0.0-M1 Environment: All Reporter: Mark Webb Please see the discussion: http://www.nabble.com/multiple-handlers-per-IoService-t4481513s16868.html#a12779214 Based on discussions with Trustin, this is functionality that will be in the 2.0 release. It seems to be inefficient to create a new selector/thread for each IoService. This means that an application that is listening on 2 ports, would need two java.nio.Selectors, two Selector worker threads and each have a pool of workers. Not only does this create much duplication, but more threads will be created than may be necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-317) add supporting statistical methods to IoService
[ https://issues.apache.org/jira/browse/DIRMINA-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb closed DIRMINA-317. - All looks good. I updated StatsCollector with some more javadoc information and closed the JIRA entry add supporting statistical methods to IoService --- Key: DIRMINA-317 URL: https://issues.apache.org/jira/browse/DIRMINA-317 Project: MINA Issue Type: New Feature Components: Core Environment: Linux, Java 1.5 Reporter: Mark Webb Assignee: Trustin Lee Priority: Minor Fix For: 2.0.0-M1 Attachments: getCreationTime.patch I was looking at the IoService class and noticed that there are some fields that would be nice to have: long getCreationTime(); long getReadBytes(); long getWrittenBytes(); long getReadMessages(); long getWrittenMessages(); These methods are in the IoSession interface, and thought it would make sense to also have them in the IoService interface. The last 4 might be a little tougher to implement, but it would be nice for times in which we need some performance numbers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-444) IoAcceptor listening on multiple ports and using multiple IoHandlers
IoAcceptor listening on multiple ports and using multiple IoHandlers Key: DIRMINA-444 URL: https://issues.apache.org/jira/browse/DIRMINA-444 Project: MINA Issue Type: New Feature Components: Core Affects Versions: 2.0.0-M1 Environment: All Reporter: Mark Webb Fix For: 2.0.0-M1 I am interested in having one IoAcceptor listen on multiple ports. This acceptor will have one Selector and based on the incoming connection/data, the proper handler will be triggered. So for each port, you will have an associated handler but this will all go through a common Selector. The goal here is to keep the number of threads at a minimum. I am building a system that may be listening on many different ports and each port will get different types of data. The number of ports could be over 20. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-376) Fine-grained logging control in LoggingFilter
[ https://issues.apache.org/jira/browse/DIRMINA-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514943 ] Mark Webb commented on DIRMINA-376: --- Not sure yet, but I thought that if we write a CopyOnWriteMap, we should have a matching CopyOnReadMap. I will investigate this further and let you know. Fine-grained logging control in LoggingFilter - Key: DIRMINA-376 URL: https://issues.apache.org/jira/browse/DIRMINA-376 Project: MINA Issue Type: New Feature Components: Filter Reporter: Trustin Lee Priority: Minor Fix For: 2.0.0-M1 LoggingFilter of MINA 1.0 has limited usability because there's no way to disable certain log messages. For example, you can't: * disable logging for certain event type (e.g. exceptionCaught, which is often logged again in IoHandler.exceptionCaught()). * log only certain type of received messages Category filtering feature provided by logging frameworks will solve this problem somewhat, but it's very coarse-grained and won't work as expected because LoggingFilter gets the logger instance using the IoHandler implementation class and therefore affect logging messages in an IoHandler implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-376) Fine-grained logging control in LoggingFilter
[ https://issues.apache.org/jira/browse/DIRMINA-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515138 ] Mark Webb commented on DIRMINA-376: --- Here is a first shot at a CopyOnWriteMap. https://svn.apache.org/repos/asf/mina/sandbox/mwebb/mina/src/main/java/org/apache/mina/util/CopyOnWriteMap.java Fine-grained logging control in LoggingFilter - Key: DIRMINA-376 URL: https://issues.apache.org/jira/browse/DIRMINA-376 Project: MINA Issue Type: New Feature Components: Filter Reporter: Trustin Lee Assignee: Mark Webb Priority: Minor Fix For: 2.0.0-M1 LoggingFilter of MINA 1.0 has limited usability because there's no way to disable certain log messages. For example, you can't: * disable logging for certain event type (e.g. exceptionCaught, which is often logged again in IoHandler.exceptionCaught()). * log only certain type of received messages Category filtering feature provided by logging frameworks will solve this problem somewhat, but it's very coarse-grained and won't work as expected because LoggingFilter gets the logger instance using the IoHandler implementation class and therefore affect logging messages in an IoHandler implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-376) Fine-grained logging control in LoggingFilter
[ https://issues.apache.org/jira/browse/DIRMINA-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514839 ] Mark Webb commented on DIRMINA-376: --- I am going to check in this code, and use the Collections.synchronizedMap(MapV,K) method for creating the java.util.Map that holds the settings. I will open a new JIRA entry for adding a CopyOnWriteMap and CopyOnReadMap. This way the new LoggingFilter can begin the review process by other developers. Fine-grained logging control in LoggingFilter - Key: DIRMINA-376 URL: https://issues.apache.org/jira/browse/DIRMINA-376 Project: MINA Issue Type: New Feature Components: Filter Reporter: Trustin Lee Priority: Minor Fix For: 2.0.0-M1 LoggingFilter of MINA 1.0 has limited usability because there's no way to disable certain log messages. For example, you can't: * disable logging for certain event type (e.g. exceptionCaught, which is often logged again in IoHandler.exceptionCaught()). * log only certain type of received messages Category filtering feature provided by logging frameworks will solve this problem somewhat, but it's very coarse-grained and won't work as expected because LoggingFilter gets the logger instance using the IoHandler implementation class and therefore affect logging messages in an IoHandler implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-24) Performance profiler filter
[ https://issues.apache.org/jira/browse/DIRMINA-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb closed DIRMINA-24. Resolution: Fixed Fix Version/s: 2.0.0-M1 Assignee: Mark Webb as per previous comments, this will now be closed. Performance profiler filter --- Key: DIRMINA-24 URL: https://issues.apache.org/jira/browse/DIRMINA-24 Project: MINA Issue Type: New Feature Components: Filter Affects Versions: 0.7.0, 0.8.0 Reporter: Trustin Lee Assignee: Mark Webb Fix For: 2.0.0-M1 We could profile event handler methods of ProtocolHandler to find bottleneck in runtime. It will be very useful because filters can be added and removed on the fly in runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-388) I try mina with a ftp client, it's sampe codes.
[ https://issues.apache.org/jira/browse/DIRMINA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513121 ] Mark Webb commented on DIRMINA-388: --- It would be great if the code was not as complex. Examples are usually viewed by people who are just learning about MINA and I think if our examples become too complex, people will lose sight of the MINA portions of the example. I try mina with a ftp client, it's sampe codes. --- Key: DIRMINA-388 URL: https://issues.apache.org/jira/browse/DIRMINA-388 Project: MINA Issue Type: Test Components: Example Affects Versions: 1.1.0 Reporter: xiangqinxian Priority: Trivial Attachments: minftpclient.jar Hi, I try mina with ftp client. maybe its a simple example for mina using. noted apache ftpserver project use block socket connection as ftp data channel. but I dont think its a good idea. sorry no comments, If need, please notify me, I would do adding. just do run: $ ant run it will download welcome.msg to current directory. Test code just reside in Controller.java main. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-313) LoggingFilter logs exceptionCaught events on error level but uses isInfoEnabled in the if-statement
[
https://issues.apache.org/jira/browse/DIRMINA-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513126
]
Mark Webb commented on DIRMINA-313:
---
Since we now have IoEventType in the trunk, I propose we change LoggingFilter
to use a MapIoEventType,LogLevel in order to keep the settings for each event
separate. I think that this would become more manageable and easier to
maintain. If a user wants to change the log level just make the call:
loggingFilter.setEventLogLevel( IoEventType.MESSAGE_RECEIVED, LogLevel.DEBUG );
If the user wants to stop logging for an event the call would be:
loggingFilter.setEventLogLevel( IoEventType.SESSION_CREATED, LogLevel.NONE );
We would of course need to create a LogLevel type of NONE.
WDYT??
LoggingFilter logs exceptionCaught events on error level but uses
isInfoEnabled in the if-statement
---
Key: DIRMINA-313
URL: https://issues.apache.org/jira/browse/DIRMINA-313
Project: MINA
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Niklas Therning
Assignee: Niklas Therning
Priority: Minor
Fix For: 1.0.1
Here's the relevant piece of code:
if( SessionLog.isInfoEnabled( session ) )
{
SessionLog.error( session, EXCEPTION:, cause );
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-24) Performance profiler filter
[ https://issues.apache.org/jira/browse/DIRMINA-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512843 ] Mark Webb commented on DIRMINA-24: -- Added 2 classes that will measure the time it takes to execute a method that is in the IoFilterAdapter class. The precision of time is either nanoseconds, milliseconds or seconds. The classes are in org.apache.mina.filters, their names are ProfilerTimerFilter and ProfilerTimerUnit. The classes are fully javadoc'd. Performance profiler filter --- Key: DIRMINA-24 URL: https://issues.apache.org/jira/browse/DIRMINA-24 Project: MINA Issue Type: New Feature Components: Filter Affects Versions: 0.7.0, 0.8.0 Reporter: Trustin Lee We could profile event handler methods of ProtocolHandler to find bottleneck in runtime. It will be very useful because filters can be added and removed on the fly in runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-397) Add convenience constructor for specifying linedelimiter in TextLineCodecFactory
[
https://issues.apache.org/jira/browse/DIRMINA-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Webb closed DIRMINA-397.
-
Resolution: Fixed
Fix Version/s: 2.0.0-M1
Assignee: Mark Webb
Added the constructor that was requested. Also updated the javadoc for the
constructor that takes in a Charset object.
Add convenience constructor for specifying linedelimiter in
TextLineCodecFactory
Key: DIRMINA-397
URL: https://issues.apache.org/jira/browse/DIRMINA-397
Project: MINA
Issue Type: Improvement
Components: Filter
Reporter: Eero Nevalainen
Assignee: Mark Webb
Priority: Minor
Fix For: 2.0.0-M1
Change the following
public TextLineCodecFactory( Charset charset )
{
encoder = new TextLineEncoder( charset, LineDelimiter.UNIX );
decoder = new TextLineDecoder( charset, LineDelimiter.AUTO );
}
to
public TextLineCodecFactory( Charset charset )
{
this( charset, LineDelimiter.UNIX, LineDelimiter.AUTO );
}
public TextLineCodecFactory( Charset charset, LineDelimiter
encodingDelimiter, LineDelimiter decodingDelimiter )
{
encoder = new TextLineEncoder( charset, encodingDelimiter );
decoder = new TextLineDecoder( charset, decodingDelimiter );
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-364) Include Runtime.getRuntime().availableProcessors() into the constructors of SocketAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Webb closed DIRMINA-364.
-
..closed
Include Runtime.getRuntime().availableProcessors() into the constructors of
SocketAcceptor
--
Key: DIRMINA-364
URL: https://issues.apache.org/jira/browse/DIRMINA-364
Project: MINA
Issue Type: Improvement
Components: Transport
Affects Versions: 2.0.0-M1
Reporter: im-james
Priority: Trivial
Fix For: 2.0.0-M1
I propose to change the default constructor of SocketAcceptor for this :
public SocketAcceptor() {
this(Runtime.getRuntime().availableProcessors(), new
NewThreadExecutor());
}
And to add a new constructor:
public SocketAcceptor(Executor executor) {
this(Runtime.getRuntime().availableProcessors(), executor);
}
The objective is to maximize the performance of MINA in the usual cases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-24) Performance profiler filter
[ https://issues.apache.org/jira/browse/DIRMINA-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb updated DIRMINA-24: - Component/s: Filter Performance profiler filter --- Key: DIRMINA-24 URL: https://issues.apache.org/jira/browse/DIRMINA-24 Project: MINA Issue Type: New Feature Components: Filter Affects Versions: 0.7.0, 0.8.0 Reporter: Trustin Lee We could profile event handler methods of ProtocolHandler to find bottleneck in runtime. It will be very useful because filters can be added and removed on the fly in runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-389) Create a Connection Throttle Filter
[ https://issues.apache.org/jira/browse/DIRMINA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507755 ] Mark Webb commented on DIRMINA-389: --- After performing some more tests, I think I now disagree. I have created a test case where I make 2 nearly simultaneous connections to a server using the ConnectionThrottleFilter and they both pass. Seeing that this is our worst case scenario (malicious client blasting the server), I think we may need to either: 1. speed up the logic in the filter to prevent thread interleavnig 2. use a synchronized map I vote for #2 to be safe. In order to support this change, I have made the clients Map in ConnectionThrottleFilter a synchronized Map using the Collections class and things work better in my test code. I can post the test code if you are interested. -- ..Cheers Mark Create a Connection Throttle Filter --- Key: DIRMINA-389 URL: https://issues.apache.org/jira/browse/DIRMINA-389 Project: MINA Issue Type: New Feature Components: Filter Affects Versions: 2.0.0-M1 Environment: All Reporter: Mark Webb Assignee: Mark Webb Priority: Minor Fix For: 2.0.0-M1 Create a filter that will throttle connections. This filter will monitor newly created sessions and if new connections from the same IP address come in too fast, drop the connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DIRMINA-389) Create a Connection Throttle Filter
[
https://issues.apache.org/jira/browse/DIRMINA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Webb reopened DIRMINA-389:
---
- SERVER CODE -
public class ConnFilterServer extends IoHandlerAdapter {
protected static final int PORT = 5678;
public ConnFilterServer() throws IOException{
IoAcceptor acceptor = new SocketAcceptor();
ConnectionThrottleFilter ctFilter = new
ConnectionThrottleFilter();
acceptor.getFilterChain().addLast(ConnThrottle, ctFilter);
acceptor.setHandler( this );
acceptor.setLocalAddress( new InetSocketAddress(PORT));
acceptor.bind();
System.out.println(Connection Filter Server running...);
}
public void sessionClosed(IoSession session) throws Exception {
SessionLog.info( session, The session has been closed );
}
public static void main(String[] args) throws IOException {
new ConnFilterServer();
}
}
--- END SERVER CODE
---CLIENT CODE---
public class ConnFilterClient extends IoHandlerAdapter implements
IoFutureListener {
public ConnFilterClient(){
makeConnection( localhost, ConnFilterServer.PORT );
makeConnection( localhost, ConnFilterServer.PORT );
}
private void makeConnection( String host, int port){
IoConnector connector = new SocketConnector();
connector.setHandler( this );
ConnectFuture connFuture = connector.connect( new
InetSocketAddress(host,port));
connFuture.addListener( this );
}
public void operationComplete(IoFuture future) {
if( future instanceof ConnectFuture ){
ConnectFuture connFuture = (ConnectFuture)future;
if( connFuture.isConnected() ){
System.out.println(Connected...);
IoSession session = connFuture.getSession();
session.write( ByteBuffer.wrap(Hello
World.getBytes()) );
}
}
}
public static void main(String[] args) {
new ConnFilterClient();
}
}
--- END CLIENT CODE ---
Create a Connection Throttle Filter
---
Key: DIRMINA-389
URL: https://issues.apache.org/jira/browse/DIRMINA-389
Project: MINA
Issue Type: New Feature
Components: Filter
Affects Versions: 2.0.0-M1
Environment: All
Reporter: Mark Webb
Assignee: Mark Webb
Priority: Minor
Fix For: 2.0.0-M1
Create a filter that will throttle connections. This filter will monitor
newly created sessions and if new connections from the same IP address come
in too fast, drop the connections.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRMINA-389) Create a Connection Throttle Filter
[ https://issues.apache.org/jira/browse/DIRMINA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb resolved DIRMINA-389. --- Resolution: Fixed Checked in the code. org.apache.mina.filter.ConnectionThrottleFilter Create a Connection Throttle Filter --- Key: DIRMINA-389 URL: https://issues.apache.org/jira/browse/DIRMINA-389 Project: MINA Issue Type: New Feature Components: Filter Affects Versions: 2.0.0-M1 Environment: All Reporter: Mark Webb Assignee: Mark Webb Priority: Minor Fix For: 2.0.0-M1 Create a filter that will throttle connections. This filter will monitor newly created sessions and if new connections from the same IP address come in too fast, drop the connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (DIRMINA-389) Create a Connection Throttle Filter
[ https://issues.apache.org/jira/browse/DIRMINA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on DIRMINA-389 started by Mark Webb. Create a Connection Throttle Filter --- Key: DIRMINA-389 URL: https://issues.apache.org/jira/browse/DIRMINA-389 Project: MINA Issue Type: New Feature Components: Filter Affects Versions: 2.0.0-M1 Environment: All Reporter: Mark Webb Assignee: Mark Webb Priority: Minor Fix For: 2.0.0-M1 Create a filter that will throttle connections. This filter will monitor newly created sessions and if new connections from the same IP address come in too fast, drop the connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-389) Create a Connection Throttle Filter
[ https://issues.apache.org/jira/browse/DIRMINA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb closed DIRMINA-389. - Code has been checked in. Create a Connection Throttle Filter --- Key: DIRMINA-389 URL: https://issues.apache.org/jira/browse/DIRMINA-389 Project: MINA Issue Type: New Feature Components: Filter Affects Versions: 2.0.0-M1 Environment: All Reporter: Mark Webb Assignee: Mark Webb Priority: Minor Fix For: 2.0.0-M1 Create a filter that will throttle connections. This filter will monitor newly created sessions and if new connections from the same IP address come in too fast, drop the connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-317) add supporting statistical methods to IoService
[ https://issues.apache.org/jira/browse/DIRMINA-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496453 ] Mark Webb commented on DIRMINA-317: --- to make this patch easier, I think it makes the most sense to place the code in the BaseIoService class. Thoughts? add supporting statistical methods to IoService --- Key: DIRMINA-317 URL: https://issues.apache.org/jira/browse/DIRMINA-317 Project: MINA Issue Type: New Feature Components: Core Environment: Linux, Java 1.5 Reporter: Mark Webb Priority: Minor Fix For: 2.0.0-M1 Attachments: getCreationTime.patch I was looking at the IoService class and noticed that there are some fields that would be nice to have: long getCreationTime(); long getReadBytes(); long getWrittenBytes(); long getReadMessages(); long getWrittenMessages(); These methods are in the IoSession interface, and thought it would make sense to also have them in the IoService interface. The last 4 might be a little tougher to implement, but it would be nice for times in which we need some performance numbers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-364) Include Runtime.getRuntime().availableProcessors() into the constructors of SocketAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496180
]
Mark Webb commented on DIRMINA-364:
---
I will add this in to the 2.0 baseline...
Include Runtime.getRuntime().availableProcessors() into the constructors of
SocketAcceptor
--
Key: DIRMINA-364
URL: https://issues.apache.org/jira/browse/DIRMINA-364
Project: MINA
Issue Type: Improvement
Components: Transport
Affects Versions: 2.0.0-M1
Reporter: im-james
Priority: Trivial
Fix For: 2.0.0-M1
I propose to change the default constructor of SocketAcceptor for this :
public SocketAcceptor() {
this(Runtime.getRuntime().availableProcessors(), new
NewThreadExecutor());
}
And to add a new constructor:
public SocketAcceptor(Executor executor) {
this(Runtime.getRuntime().availableProcessors(), executor);
}
The objective is to maximize the performance of MINA in the usual cases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-364) Include Runtime.getRuntime().availableProcessors() into the constructors of SocketAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496189
]
Mark Webb commented on DIRMINA-364:
---
I have added the following constructor:
public SocketAcceptor(Executor executor)
{
this(Runtime.getRuntime().availableProcessors(), executor);
}
Additionally, I have updated the default constructor to the following:
public SocketAcceptor()
{
this( new NewThreadExecutor() );
}
Include Runtime.getRuntime().availableProcessors() into the constructors of
SocketAcceptor
--
Key: DIRMINA-364
URL: https://issues.apache.org/jira/browse/DIRMINA-364
Project: MINA
Issue Type: Improvement
Components: Transport
Affects Versions: 2.0.0-M1
Reporter: im-james
Priority: Trivial
Fix For: 2.0.0-M1
I propose to change the default constructor of SocketAcceptor for this :
public SocketAcceptor() {
this(Runtime.getRuntime().availableProcessors(), new
NewThreadExecutor());
}
And to add a new constructor:
public SocketAcceptor(Executor executor) {
this(Runtime.getRuntime().availableProcessors(), executor);
}
The objective is to maximize the performance of MINA in the usual cases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-317) add supporting statistical methods to IoService
add supporting statistical methods to IoService --- Key: DIRMINA-317 URL: http://issues.apache.org/jira/browse/DIRMINA-317 Project: MINA Issue Type: New Feature Components: Core Affects Versions: 2.0 Environment: Linux, Java 1.5 Reporter: Mark Webb Priority: Minor I was looking at the IoService class and noticed that there are some fields that would be nice to have: long getCreationTime(); long getReadBytes(); long getWrittenBytes(); long getReadMessages(); long getWrittenMessages(); These methods are in the IoSession interface, and thought it would make sense to also have them in the IoService interface. The last 4 might be a little tougher to implement, but it would be nice for times in which we need some performance numbers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DIRMINA-317) add supporting statistical methods to IoService
[ http://issues.apache.org/jira/browse/DIRMINA-317?page=all ] Mark Webb updated DIRMINA-317: -- Attachment: getCreationTime.patch This patch adds creation time support to IoService. add supporting statistical methods to IoService --- Key: DIRMINA-317 URL: http://issues.apache.org/jira/browse/DIRMINA-317 Project: MINA Issue Type: New Feature Components: Core Affects Versions: 2.0 Environment: Linux, Java 1.5 Reporter: Mark Webb Priority: Minor Attachments: getCreationTime.patch I was looking at the IoService class and noticed that there are some fields that would be nice to have: long getCreationTime(); long getReadBytes(); long getWrittenBytes(); long getReadMessages(); long getWrittenMessages(); These methods are in the IoSession interface, and thought it would make sense to also have them in the IoService interface. The last 4 might be a little tougher to implement, but it would be nice for times in which we need some performance numbers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
