[jira] Created: (DIRMINA-427) Creating a common EventType enum

[Emmanuel Lecharny (JIRA)]

Creating a common  EventType enum
-

 Key: DIRMINA-427
 URL: https://issues.apache.org/jira/browse/DIRMINA-427
 Project: MINA
  Issue Type: Improvement
Affects Versions: 1.1.2
Reporter: Emmanuel Lecharny
Priority: Minor


I have migrated the EventType class found in VmPipeFilterChain and 
ExecutorFilter to core/src/main/java/org/apache/mina/common/EventType.java, and 
it's now an enum. It is easier to use, as you don't have to do a cascade 
if/then/else in the ExecutorFilter and VmPipeFilterChain classes, they are 
replaced by a switch( eventType ).

See the diff attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-427) Creating a common EventType enum

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-427:
--

Attachment: mina-with-enum.diff

EventType as an enum and externalized in its own file.

> Creating a common  EventType enum
> -
>
> Key: DIRMINA-427
> URL: https://issues.apache.org/jira/browse/DIRMINA-427
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 1.1.2
>Reporter: Emmanuel Lecharny
>Priority: Minor
> Attachments: mina-with-enum.diff
>
>
> I have migrated the EventType class found in VmPipeFilterChain and 
> ExecutorFilter to core/src/main/java/org/apache/mina/common/EventType.java, 
> and it's now an enum. It is easier to use, as you don't have to do a cascade 
> if/then/else in the ExecutorFilter and VmPipeFilterChain classes, they are 
> replaced by a switch( eventType ).
> See the diff attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DIRMINA-427) Creating a common EventType enum

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny closed DIRMINA-427.
-


definitively already done ... Doh !

> Creating a common  EventType enum
> -
>
> Key: DIRMINA-427
> URL: https://issues.apache.org/jira/browse/DIRMINA-427
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 1.1.2
>Reporter: Emmanuel Lecharny
>Priority: Minor
> Attachments: mina-with-enum.diff
>
>
> I have migrated the EventType class found in VmPipeFilterChain and 
> ExecutorFilter to core/src/main/java/org/apache/mina/common/EventType.java, 
> and it's now an enum. It is easier to use, as you don't have to do a cascade 
> if/then/else in the ExecutorFilter and VmPipeFilterChain classes, they are 
> replaced by a switch( eventType ).
> See the diff attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-445) SessionLog improvement

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529886
 ] 

Emmanuel Lecharny commented on DIRMINA-445:
---

I have looked at the trunk. It seems that SessionLog has been moved to a 
IoSessionLogger, but Vincent proposal is still valid.

The code looks like :
public static void trace(Logger log, IoSession session, String message) {
if (log.isTraceEnabled()) {
log.trace(String.valueOf(getPrefix(session)) + message);
}
}

Two remarks there :
1) using the Marker mechanism, it could be written like  :
public static void trace(Logger log, IoSession session, String message) {
if (log.isTraceEnabled()) {
log.trace( "{} {}", getPrefix(session), message); // No need to 
call the String.valueOf( getPrefix()), getprefix already returns a String
} 
}

2) As soon as you encapsulate the log method in such a wrapper, then suddenly 
you can pass an Object instead of a String, and transform the methods to looks 
like :
public static void trace(Logger log, IoSession session, Object message) {
if (log.isTraceEnabled()) {
log.trace( "{} {}", getPrefix(session), message);
} 
}

It comes at no cost, and will save a lot of CPU


Regarding 1.1.2, we have almost the same code :
public static void debug(IoSession session, String message) {
Logger log = getLogger(session);
if (log.isDebugEnabled()) {
log.debug(String.valueOf(session.getAttribute(PREFIX)) + message);
}
}

which can be written like :
public static void debug(IoSession session, Object message) {
Logger log = getLogger(session);
if (log.isDebugEnabled()) {
log.debug( "{} {}", session.getAttribute(PREFIX), message); // No 
need either to call String.valueOf(), slf4j will handle the object itself.
} 
}




> SessionLog improvement
> --
>
> Key: DIRMINA-445
> URL: https://issues.apache.org/jira/browse/DIRMINA-445
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.1.3, 2.0.0-M1
> Environment: Use Object instead of String inSessionLog logging method 
> to allow for massive perfs improvement on production running instances (when 
> logs filtering is used).
>Reporter: vincent bourdaraud
>Priority: Minor
>
> SessionLog.debug(IoSession,String), info(IoSession,String), 
> warn(IoSession,String) and error(IoSession,String) should be changed to 
> SessionLog.debug(IoSession,Object), info(IoSession,Object), 
> warn(IoSession,Object) and error(IoSession,Object), as in log4j.
> The reason for this is that if passing Objects instead of String allow to 
> delay the composition of the logging message (.toString() call) until really 
> needed and that could greatly improve performance. This kind of feature is 
> needed to build SW able to be turned in debug while in production using 
> NDC/MDC filters (using log4j e.g.).
> Some code snippet the illustrate this:
> public void messageReceived(IoSession session, Object o) throws Exception
> {
>MyProtocolRequest req = (MyProtocolRequest) o;
>NDC.put(req.getUserId());
>SessionLog.debug(session, new RequestDumper(req));
>NDC.pop();
> }
>
> class RequestDumper()
> {
> public RequestDumper(MyProtocolRequest req)
> {
> this.req = req;
> }
> 
> public String toString()
> {
> return req.toString();
> }
> 
> private MyProtocolRequest req;
> }
> In that snippet, the cost of converting MyProtocolRequest to a String is not 
> paied when SessionLog.debug() is called, but when the underlying logging 
> framework needs the string for logging. The perf improvement could be massive 
> if the underlying protocol uses some kind of filtering to filter-out most 
> debug logs; in that example, the logging framework would be configured to 
> filter-in only logs with a NDC set to a specific user.
> With this feature, we could enable debug in production for some few users 
> only, without killing the overall performances.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-445) SessionLog improvement

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529952
 ] 

Emmanuel Lecharny commented on DIRMINA-445:
---

Hmmm... Not sure I understand the potential negative impact of this change, 
when the event is not filtered... Do you mean if log is not activated, for 
instance?

> SessionLog improvement
> --
>
> Key: DIRMINA-445
> URL: https://issues.apache.org/jira/browse/DIRMINA-445
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.1.3, 2.0.0-M1
> Environment: Use Object instead of String inSessionLog logging method 
> to allow for massive perfs improvement on production running instances (when 
> logs filtering is used).
>Reporter: vincent bourdaraud
>Assignee: Maarten Bosteels
>Priority: Minor
>
> SessionLog.debug(IoSession,String), info(IoSession,String), 
> warn(IoSession,String) and error(IoSession,String) should be changed to 
> SessionLog.debug(IoSession,Object), info(IoSession,Object), 
> warn(IoSession,Object) and error(IoSession,Object), as in log4j.
> The reason for this is that if passing Objects instead of String allow to 
> delay the composition of the logging message (.toString() call) until really 
> needed and that could greatly improve performance. This kind of feature is 
> needed to build SW able to be turned in debug while in production using 
> NDC/MDC filters (using log4j e.g.).
> Some code snippet the illustrate this:
> public void messageReceived(IoSession session, Object o) throws Exception
> {
>MyProtocolRequest req = (MyProtocolRequest) o;
>NDC.put(req.getUserId());
>SessionLog.debug(session, new RequestDumper(req));
>NDC.pop();
> }
>
> class RequestDumper()
> {
> public RequestDumper(MyProtocolRequest req)
> {
> this.req = req;
> }
> 
> public String toString()
> {
> return req.toString();
> }
> 
> private MyProtocolRequest req;
> }
> In that snippet, the cost of converting MyProtocolRequest to a String is not 
> paied when SessionLog.debug() is called, but when the underlying logging 
> framework needs the string for logging. The perf improvement could be massive 
> if the underlying protocol uses some kind of filtering to filter-out most 
> debug logs; in that example, the logging framework would be configured to 
> filter-in only logs with a NDC set to a specific user.
> With this feature, we could enable debug in production for some few users 
> only, without killing the overall performances.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-575) Add the missing Javadoc, add some comments

[Emmanuel Lecharny (JIRA)]

Add the missing Javadoc, add some comments
--

 Key: DIRMINA-575
 URL: https://issues.apache.org/jira/browse/DIRMINA-575
 Project: MINA
  Issue Type: Improvement
Affects Versions: 2.0.0-M2, 1.0.11, 1.1.8
Reporter: Emmanuel Lecharny
Priority: Blocker
 Fix For: 2.0.0-M2, 1.0.11, 1.1.8


If we except the interfaces, the code lacks of javadoc and comments, which make 
it complicated for new committers to get into it.

We need to add those missing javadocs, and comments where it's necessary.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-379) setKeepAlive/setTcpNoDelay and exceptions in Windows Vista

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592097#action_12592097
 ] 

Emmanuel Lecharny commented on DIRMINA-379:
---

May it be connected to this description : ?

http://communitygrids.blogspot.com/2007/09/windows-vista-sockets-java-nio-and.html

> setKeepAlive/setTcpNoDelay and exceptions in Windows Vista
> --
>
> Key: DIRMINA-379
> URL: https://issues.apache.org/jira/browse/DIRMINA-379
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.3, 1.1.0, 2.0.0-M1
> Environment: Windows Vista Home Premium Italian
> Java SE 1.5.0_11, Java SE 1.6 Update 1, Java SE 1.4.2_12
>Reporter: Stefano Bagnara
>Assignee: Trustin Lee
>
> When I ran my application under Vista I get this exception:
> Exception in thread "Thread-4" org.apache.mina.common.RuntimeIOException: 
> java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
>   at 
> org.apache.mina.transport.socket.nio.SocketSessionImpl$SessionConfigImpl.setKeepAlive(SocketSessionImpl.java:252)
>   at 
> org.apache.mina.transport.socket.nio.SocketSessionImpl.(SocketSessionImpl.java:94)
>   at 
> org.apache.mina.transport.socket.nio.SocketConnector.newSession(SocketConnector.java:350)
>   at 
> org.apache.mina.transport.socket.nio.SocketConnector.processSessions(SocketConnector.java:290)
>   at 
> org.apache.mina.transport.socket.nio.SocketConnector.access$900(SocketConnector.java:53)
>   at 
> org.apache.mina.transport.socket.nio.SocketConnector$Worker.run(SocketConnector.java:395)
>   at 
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:43)
>   at java.lang.Thread.run(Thread.java:595)
> Caused by: java.net.SocketException: Invalid argument: 
> sun.nio.ch.Net.setIntOption
>   at sun.nio.ch.Net.setIntOption0(Native Method)
>   at sun.nio.ch.Net.setIntOption(Net.java:152)
>   at sun.nio.ch.SocketChannelImpl$1.setInt(SocketChannelImpl.java:372)
>   at sun.nio.ch.SocketOptsImpl.setBoolean(SocketOptsImpl.java:38)
>   at sun.nio.ch.SocketOptsImpl.keepAlive(SocketOptsImpl.java:92)
>   at sun.nio.ch.OptionAdaptor.setKeepAlive(OptionAdaptor.java:139)
>   at sun.nio.ch.SocketAdaptor.setKeepAlive(SocketAdaptor.java:322)
>   at 
> org.apache.mina.transport.socket.nio.SocketSessionImpl$SessionConfigImpl.setKeepAlive(SocketSessionImpl.java:248)
>   ... 7 more
> I had to remove the following lines from the SocketSessionImpl constructor:
> this.config.setKeepAlive( cfg.isKeepAlive() );
> this.config.setTcpNoDelay( cfg.isTcpNoDelay() );
> and now it works.
> No matter if I change the configuration to let them return true or false, I 
> keep getting the exception if I don't remove the call at all.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-379) setKeepAlive/setTcpNoDelay and exceptions in Windows Vista

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592171#action_12592171
 ] 

Emmanuel Lecharny commented on DIRMINA-379:
---

Tanks guys !

Seems that we are progressing in the good direction :)

FYI, generating a diff is just as simple as typing this command :

svn diff > diff.txt

You have to be on the root of the MINA source directory (ie, if you did a svn 
co http://svn...(blah)/mina/trunk mina-2.0.0-M1, you have to be into 
mina-2.0.0-M1 directory to pass the command, so that the complete path will be 
stored into the diff file).

Thanks !

> setKeepAlive/setTcpNoDelay and exceptions in Windows Vista
> --
>
> Key: DIRMINA-379
> URL: https://issues.apache.org/jira/browse/DIRMINA-379
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.3, 1.1.0, 2.0.0-M1
> Environment: Windows Vista Home Premium Italian
> Java SE 1.5.0_11, Java SE 1.6 Update 1, Java SE 1.4.2_12
>Reporter: Stefano Bagnara
>Assignee: Trustin Lee
>
> When I ran my application under Vista I get this exception:
> Exception in thread "Thread-4" org.apache.mina.common.RuntimeIOException: 
> java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
>   at 
> org.apache.mina.transport.socket.nio.SocketSessionImpl$SessionConfigImpl.setKeepAlive(SocketSessionImpl.java:252)
>   at 
> org.apache.mina.transport.socket.nio.SocketSessionImpl.(SocketSessionImpl.java:94)
>   at 
> org.apache.mina.transport.socket.nio.SocketConnector.newSession(SocketConnector.java:350)
>   at 
> org.apache.mina.transport.socket.nio.SocketConnector.processSessions(SocketConnector.java:290)
>   at 
> org.apache.mina.transport.socket.nio.SocketConnector.access$900(SocketConnector.java:53)
>   at 
> org.apache.mina.transport.socket.nio.SocketConnector$Worker.run(SocketConnector.java:395)
>   at 
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:43)
>   at java.lang.Thread.run(Thread.java:595)
> Caused by: java.net.SocketException: Invalid argument: 
> sun.nio.ch.Net.setIntOption
>   at sun.nio.ch.Net.setIntOption0(Native Method)
>   at sun.nio.ch.Net.setIntOption(Net.java:152)
>   at sun.nio.ch.SocketChannelImpl$1.setInt(SocketChannelImpl.java:372)
>   at sun.nio.ch.SocketOptsImpl.setBoolean(SocketOptsImpl.java:38)
>   at sun.nio.ch.SocketOptsImpl.keepAlive(SocketOptsImpl.java:92)
>   at sun.nio.ch.OptionAdaptor.setKeepAlive(OptionAdaptor.java:139)
>   at sun.nio.ch.SocketAdaptor.setKeepAlive(SocketAdaptor.java:322)
>   at 
> org.apache.mina.transport.socket.nio.SocketSessionImpl$SessionConfigImpl.setKeepAlive(SocketSessionImpl.java:248)
>   ... 7 more
> I had to remove the following lines from the SocketSessionImpl constructor:
> this.config.setKeepAlive( cfg.isKeepAlive() );
> this.config.setTcpNoDelay( cfg.isTcpNoDelay() );
> and now it works.
> No matter if I change the configuration to let them return true or false, I 
> keep getting the exception if I don't remove the call at all.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-577) Implement a Selector pool

[Emmanuel Lecharny (JIRA)]

Implement a Selector pool 
--

 Key: DIRMINA-577
 URL: https://issues.apache.org/jira/browse/DIRMINA-577
 Project: MINA
  Issue Type: Improvement
Affects Versions: 2.0.0-M1
Reporter: Emmanuel Lecharny
 Fix For: 2.0.0-M2


There is an interesting post from Jean-François Arcand : 
http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html
where he explains that we may use more than one single Selector to manage the 
incoming and outgoing events. 

Separating OP_READ, OP_WRITE and OP_ACCEPT selectors may lead to some 
improvement, depending on which kind of server you want to build.

It seems interesting to implement these ideas in MINA.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-575) Add the missing Javadoc, add some comments

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598168#action_12598168
 ] 

Emmanuel Lecharny commented on DIRMINA-575:
---

For a 2.0, it will be a blocker. If we have to have a 2.0.0-M3, this is not a 
blocker.

The thing is that we can't say a JIRA issue is a blocker for a future version.

About what has to be added, a complete code review should be done, or at least, 
using a tool like Enerjy on eclipse of any other tool can tell you where the 
Javadoc is missing. This is actually what we are doing on Directory : using 
such a tool to add missing javadoc.

I know this is painfull, but it's a no brainer, and a good thing to do when 
tired, as it does not need to be very efficient. I usually do that when it's 
late at night or when commuting, as it needs no brain power.

> Add the missing Javadoc, add some comments
> --
>
> Key: DIRMINA-575
> URL: https://issues.apache.org/jira/browse/DIRMINA-575
> Project: MINA
>  Issue Type: Task
>  Components: Web Site / Documentation
>Reporter: Emmanuel Lecharny
>
> If we except the interfaces, the code lacks of javadoc and comments, which 
> make it complicated for new committers to get into it.
> We need to add those missing javadocs, and comments where it's necessary.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-575) Add the missing Javadoc, add some comments

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598260#action_12598260
 ] 

Emmanuel Lecharny commented on DIRMINA-575:
---

Yeah, exactly : it's a blocker for a RC or even a GA. Milestones are just work 
in progress, and documentation has to follow. However, it's way better to write 
doco while writing ocde for two reasons : 
- it's fresh in your mind
- doco is a part of the code

To be very clear : it's all about progress. We may not have a complete 
documentation, or a perfect one for 2.0, but at least, it should be enough for 
our users.

> Add the missing Javadoc, add some comments
> --
>
> Key: DIRMINA-575
> URL: https://issues.apache.org/jira/browse/DIRMINA-575
> Project: MINA
>  Issue Type: Task
>  Components: Web Site / Documentation
>Reporter: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-RC1
>
>
> If we except the interfaces, the code lacks of javadoc and comments, which 
> make it complicated for new committers to get into it.
> We need to add those missing javadocs, and comments where it's necessary.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-590) dev list problem

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599671#action_12599671
 ] 

Emmanuel Lecharny commented on DIRMINA-590:
---

Are you using a web-mail which append some kind of commercial at the end ?

> dev list problem
> 
>
> Key: DIRMINA-590
> URL: https://issues.apache.org/jira/browse/DIRMINA-590
> Project: MINA
>  Issue Type: Wish
>Reporter: Frederic Bregier
>Priority: Trivial
>
> I try to send a simple mail on the dev list of Mina and I got every time, 
> even on very short mail the following :
> 
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
> For further assistance, please send mail to 
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
> The Postfix program
> : host mx1.eu.apache.org[192.87.106.230] said: 552 spam
> score (6.2) exceeded threshold (in reply to end of DATA command)
> =
> I don't find another way to inform the comunity of this problem...
> Sorry to open a Jira for this since I don't think it is the good way.
> I will close it soon after.
> Frederic

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-599) Lack of ASL 2.0 license header, and generally speaking, Javadoc lacking

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602061#action_12602061
 ] 

Emmanuel Lecharny commented on DIRMINA-599:
---

ASF headers added :
http://svn.apache.org/viewvc?rev=662873&view=rev

> Lack of ASL 2.0 license header, and generally speaking, Javadoc lacking
> ---
>
> Key: DIRMINA-599
> URL: https://issues.apache.org/jira/browse/DIRMINA-599
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M2
>Reporter: Emmanuel Lecharny
>Priority: Blocker
>
> Some files added back in 2007 have been committed without any header, 
> javadoc, comment, nothing.
> Here is an exemple :
> http://svn.apache.org/repos/asf/mina/tags/2.0.0-M1/transport-apr/src/main/java/org/apache/mina/transport/socket/apr/AprDatagramSession.java
> Basically, after having auditing the seven first classes in common, the total 
> lack of Javadoc and comment make it really difficult to help users if you 
> didn't wrote the code. Typically, almost all the protected methods are 
> javadoc-less, and pretty much no fields are documented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-599) Lack of ASL 2.0 license header, and generally speaking, Javadoc lacking

[Emmanuel Lecharny (JIRA)]

Lack of ASL 2.0 license header, and generally speaking, Javadoc lacking
---

 Key: DIRMINA-599
 URL: https://issues.apache.org/jira/browse/DIRMINA-599
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M2
Reporter: Emmanuel Lecharny
Priority: Blocker


Some files added back in 2007 have been committed without any header, javadoc, 
comment, nothing.

Here is an exemple :

http://svn.apache.org/repos/asf/mina/tags/2.0.0-M1/transport-apr/src/main/java/org/apache/mina/transport/socket/apr/AprDatagramSession.java

Basically, after having auditing the seven first classes in common, the total 
lack of Javadoc and comment make it really difficult to help users if you 
didn't wrote the code. Typically, almost all the protected methods are 
javadoc-less, and pretty much no fields are documented.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-591) Javadoc & documentation for org/apache/mina/filter/codec/statemachine/

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603299#action_12603299
 ] 

Emmanuel Lecharny commented on DIRMINA-591:
---

Thanks a lot Niklas !!

This portion of the code (state machine) is not, by far, the less documented 
one in MINA. I went through all the classes in MINA, adding some TODO tags in 
all the class headers, and this sub-project was clean (there are 90 files out 
of 476 without headers ...).

This is a very valuable effort, even if it seems to be obscur, and painfull, 
but this make the project much better !

Julien, you may consider closing the issue.

> Javadoc & documentation for org/apache/mina/filter/codec/statemachine/
> --
>
> Key: DIRMINA-591
> URL: https://issues.apache.org/jira/browse/DIRMINA-591
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter, Web Site / Documentation
>Affects Versions: 2.0.0-M1
>Reporter: Julien Vermillard
> Fix For: 2.0.0-M2
>
>
> The statemachine codec utilities (used in Asyncweb codec) isn't documented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-415) Proxy support

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609551#action_12609551
 ] 

Emmanuel Lecharny commented on DIRMINA-415:
---

Great !!!

This seems to be a tremendous piece of work ! I wish RATP have as much 
commitment to do their job as you do ;)

> Proxy support
> -
>
> Key: DIRMINA-415
> URL: https://issues.apache.org/jira/browse/DIRMINA-415
> Project: MINA
>  Issue Type: New Feature
>  Components: Transport
>Reporter: Trustin Lee
> Fix For: 2.0.0-M2
>
> Attachments: mina-connector-proxy-1.1.0-mina2.zip, 
> mina-connector-proxy-1.1.0.zip, minaproxy-2.0.0-M1.zip
>
>
> There has been enourmous demand for supporting proxy such as simple port 
> forwarding and SOCKS.  We need to investigate what the best way is to provide 
> an extension point for proxies.
> IoFilters are not adequate for proxies because proxies needs changes in the 
> socket addresses (both local and remote) of IoSession.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-415) Proxy support

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609559#action_12609559
 ] 

Emmanuel Lecharny commented on DIRMINA-415:
---

A MINA-2.0.0-M2 is currently under work, so I see those proposals as perfect 
candidate for a 2.0.0-M3.

> Proxy support
> -
>
> Key: DIRMINA-415
> URL: https://issues.apache.org/jira/browse/DIRMINA-415
> Project: MINA
>  Issue Type: New Feature
>  Components: Transport
>Reporter: Trustin Lee
> Fix For: 2.0.0-M2
>
> Attachments: mina-connector-proxy-1.1.0-mina2.zip, 
> mina-connector-proxy-1.1.0.zip, minaproxy-2.0.0-M1.zip
>
>
> There has been enourmous demand for supporting proxy such as simple port 
> forwarding and SOCKS.  We need to investigate what the best way is to provide 
> an extension point for proxies.
> IoFilters are not adequate for proxies because proxies needs changes in the 
> socket addresses (both local and remote) of IoSession.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-606) Downloaded file signatures are incorrect

[Emmanuel Lecharny (JIRA)]

Downloaded file signatures are incorrect


 Key: DIRMINA-606
 URL: https://issues.apache.org/jira/browse/DIRMINA-606
 Project: MINA
  Issue Type: Bug
Affects Versions: 1.1.7, 1.0.10, 2.0.0-M1
Reporter: Emmanuel Lecharny
Priority: Blocker


The asc files does not match the downloaded files :

Visit the Mina download site: http://mina.apache.org/downloads
right-click and save mina-2.0.0-M1.tar.bz2.  Now do the same for the
"asc" file just to the right.  In another window run gpg on the asc
file, and it will inform you: BAD signature from "Mike Heath
<[EMAIL PROTECTED]>"

Here are the links that I see from the home page (right-click
copy-link-location for both the .bz2 and the .asc files):

 http://mina.apache.org/dyn/closer.cgi/mina/2.0.0-M1/mina-2.0.0-M1.tar.bz2
 http://www.apache.org/dist/mina/2.0.0-M1/mina-2.0.0-M1.tar.bz2.asc



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-607) Running tests leave files in /tmp

[Emmanuel Lecharny (JIRA)]

Running tests leave files in /tmp
-

 Key: DIRMINA-607
 URL: https://issues.apache.org/jira/browse/DIRMINA-607
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M2
Reporter: Emmanuel Lecharny
 Fix For: 2.0.0-M3


When running mvn test, some files are created on /tmp, but never deleted. 

This is a real problem as the file being created are quite huge (4 Mb)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DIRMINA-607) Running tests leave files in /tmp

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny resolved DIRMINA-607.
---

Resolution: Fixed

Fixed in http://svn.apache.org/viewvc?rev=674856&view=rev

> Running tests leave files in /tmp
> -
>
> Key: DIRMINA-607
> URL: https://issues.apache.org/jira/browse/DIRMINA-607
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M2
>Reporter: Emmanuel Lecharny
> Fix For: 2.0.0-M3
>
>
> When running mvn test, some files are created on /tmp, but never deleted. 
> This is a real problem as the file being created are quite huge (4 Mb)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DIRMINA-607) Running tests leave files in /tmp

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny closed DIRMINA-607.
-


Fixed

> Running tests leave files in /tmp
> -
>
> Key: DIRMINA-607
> URL: https://issues.apache.org/jira/browse/DIRMINA-607
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M2
>Reporter: Emmanuel Lecharny
> Fix For: 2.0.0-M3
>
>
> When running mvn test, some files are created on /tmp, but never deleted. 
> This is a real problem as the file being created are quite huge (4 Mb)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-608) Move stats out of the IoService API

[Emmanuel Lecharny (JIRA)]

Move stats out of the IoService API
---

 Key: DIRMINA-608
 URL: https://issues.apache.org/jira/browse/DIRMINA-608
 Project: MINA
  Issue Type: Improvement
Affects Versions: 2.0.0-M2
Reporter: Emmanuel Lecharny
Priority: Minor
 Fix For: 2.0.0-M3


The statictic informations contained into the IoService API could be put in 
some specific class, and made available through a call to a dedicated getter :

IoServiceStatistics getStatistics()

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-605) Add documentation for using and building serial port connection

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613755#action_12613755
 ] 

Emmanuel Lecharny commented on DIRMINA-605:
---

svn co http://svn.apache.org/repos/asf/mina/trunk

This is the place where we develop MINA-2.0.0-M3

> Add documentation for using and building serial port connection
> ---
>
> Key: DIRMINA-605
> URL: https://issues.apache.org/jira/browse/DIRMINA-605
> Project: MINA
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 2.0.0-M1
> Environment: Windows XP
>Reporter: john wang
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M3
>
>
> Add the documentation for building serial-transport and use it in your MINA 
> application

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DIRMINA-608) Move stats out of the IoService API

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny reassigned DIRMINA-608:
-

Assignee: Emmanuel Lecharny

> Move stats out of the IoService API
> ---
>
> Key: DIRMINA-608
> URL: https://issues.apache.org/jira/browse/DIRMINA-608
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 2.0.0-M2
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>Priority: Minor
> Fix For: 2.0.0-M3
>
> Attachments: IoServiceStatistics.patch
>
>
> The statictic informations contained into the IoService API could be put in 
> some specific class, and made available through a call to a dedicated getter :
> IoServiceStatistics getStatistics()

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-608) Move stats out of the IoService API

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614331#action_12614331
 ] 

Emmanuel Lecharny commented on DIRMINA-608:
---

Patch applied.

One more thing would be valuabe : atm, the getStatistics() method return 
'this', which means all the methods are included into the AbstractIoService 
class. It would be much more preferable that the statistics were implemented 
into a separated class, so that the getStatistics() method returns a reference 
to this class. The AbstractIoService would then be much more light.

That also means we won't have to implement IoServiceStatistics in 
AbstractIoService. A simpler IoStatistics interface with a getStatistics() 
method would be enough.

wdyt ?

> Move stats out of the IoService API
> ---
>
> Key: DIRMINA-608
> URL: https://issues.apache.org/jira/browse/DIRMINA-608
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 2.0.0-M2
>Reporter: Emmanuel Lecharny
>Priority: Minor
> Fix For: 2.0.0-M3
>
> Attachments: IoServiceStatistics.patch
>
>
> The statictic informations contained into the IoService API could be put in 
> some specific class, and made available through a call to a dedicated getter :
> IoServiceStatistics getStatistics()

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-608) Move stats out of the IoService API

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614735#action_12614735
 ] 

Emmanuel Lecharny commented on DIRMINA-608:
---

Hi Barend,

I know realize that I have committed your patch but that you didn't checked the 
licensing checkbox.

Is it possible that you check it so I don't have to revert the patch ? 

Thanks !

> Move stats out of the IoService API
> ---
>
> Key: DIRMINA-608
> URL: https://issues.apache.org/jira/browse/DIRMINA-608
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 2.0.0-M2
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>Priority: Minor
> Fix For: 2.0.0-M3
>
> Attachments: IoServiceStatistics.patch
>
>
> The statictic informations contained into the IoService API could be put in 
> some specific class, and made available through a call to a dedicated getter :
> IoServiceStatistics getStatistics()

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-619) Mark easymock as test dependency in maven pom.xml

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628277#action_12628277
 ] 

Emmanuel Lecharny commented on DIRMINA-619:
---

Hey,

this was certainly not noise ! We really appreciate those kind of reports. This 
is the way to go, definitively : we can quickly check if it's a real bug or 
not, and if not, we simply close the JIRA. It's a 5 minutes process, and it's 
asynchronous, compared to a mail which must be processed quick immediatly, or 
forgetten for ever...

Thanks !

> Mark easymock as test dependency in maven pom.xml
> -
>
> Key: DIRMINA-619
> URL: https://issues.apache.org/jira/browse/DIRMINA-619
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.0-M3
>Reporter: syvalta
>
> Currently Maven pom.xml for core includes following dependencies:
> 
>   org.easymock
>   easymock
> 
> 
> 
>   org.easymock
>   easymockclassextension
> 
> I would assume that they are test dependencies, so adding test 
> to them would be good to prevent them to be included in wars etc. Unless I'm 
> mistaken and they really are needed at runtime, which I find highly unlikely. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DIRMINA-621) DOAP file has syntax error

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny reassigned DIRMINA-621:
-

Assignee: Emmanuel Lecharny

> DOAP file has syntax error
> --
>
> Key: DIRMINA-621
> URL: https://issues.apache.org/jira/browse/DIRMINA-621
> Project: MINA
>  Issue Type: Bug
>  Components: Web Site / Documentation
> Environment: 
> http://svn.apache.org/viewvc/mina/metadata/doap.rdf?r1=684665&r2=684664&pathrev=684665
>Reporter: Sebb
>Assignee: Emmanuel Lecharny
>Priority: Blocker
>
> Spot the missing line in the following change?
> --- mina/metadata/doap.rdf2008/08/11 08:02:00 684664
> +++ mina/metadata/doap.rdf2008/08/11 08:16:23 684665
> @@ -30,6 +30,10 @@
>  
>
>  Apache MINA
> +2008-08-11
> +2.0.0-M3
> +  
> +Apache MINA
>  2008-07-08
>  2.0.0-M2
>
> ... there's no closing .

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DIRMINA-621) DOAP file has syntax error

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny resolved DIRMINA-621.
---

Resolution: Fixed

Fixed in :
http://svn.apache.org/viewvc?rev=694238&view=rev

Thanks Seb !

> DOAP file has syntax error
> --
>
> Key: DIRMINA-621
> URL: https://issues.apache.org/jira/browse/DIRMINA-621
> Project: MINA
>  Issue Type: Bug
>  Components: Web Site / Documentation
> Environment: 
> http://svn.apache.org/viewvc/mina/metadata/doap.rdf?r1=684665&r2=684664&pathrev=684665
>Reporter: Sebb
>Assignee: Emmanuel Lecharny
>Priority: Blocker
>
> Spot the missing line in the following change?
> --- mina/metadata/doap.rdf2008/08/11 08:02:00 684664
> +++ mina/metadata/doap.rdf2008/08/11 08:16:23 684665
> @@ -30,6 +30,10 @@
>  
>
>  Apache MINA
> +2008-08-11
> +2.0.0-M3
> +  
> +Apache MINA
>  2008-07-08
>  2.0.0-M2
>
> ... there's no closing .

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-624) Message handlers selection is not efficient in the DemuxingIoHandler

[Emmanuel Lecharny (JIRA)]

Message handlers selection is not efficient in the DemuxingIoHandler


 Key: DIRMINA-624
 URL: https://issues.apache.org/jira/browse/DIRMINA-624
 Project: MINA
  Issue Type: Improvement
Affects Versions: 2.0.0-M3
Reporter: Emmanuel Lecharny


The way we are selecting a message handler in the DemuxingIoHandler is far from 
being optimal. The problem is that we are registering a handler without 
checking its inheritence scheme, but we do so when receiving a message.

It would be much more efficient to do the inheritence discovering while 
registering a handler, avoiding such a discovery when receiving a message.

There is only one tricky issue we have to take care of : as we can associate a 
handler with one of it's inherited class or implemented interface, if there is 
another handler associated with those classes/interfaces added later, this 
should override the default association. So we must flag the automatically 
added handlers in order to be able to replace them if needed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-625) How to use the function awaitUninterruptibly or await

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635513#action_12635513
 ] 

Emmanuel Lecharny commented on DIRMINA-625:
---

Can you be a little bit more specific? It's pretty hard to read between so few 
lines ...

> How to use the function awaitUninterruptibly or await
> -
>
> Key: DIRMINA-625
> URL: https://issues.apache.org/jira/browse/DIRMINA-625
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M3
>Reporter: ben
>
> Always reported abnormal DEAD LOCK, How to use it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-625) How to use the function awaitUninterruptibly or await

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635710#action_12635710
 ] 

Emmanuel Lecharny commented on DIRMINA-625:
---

What thread model are you using ? An orderedThreadPoolExecutor or an 
UnorderedthreadPoolExecutor ?

> How to use the function awaitUninterruptibly or await
> -
>
> Key: DIRMINA-625
> URL: https://issues.apache.org/jira/browse/DIRMINA-625
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M3
>Reporter: ben
>
> Always reported abnormal DEAD LOCK, How to use it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-574) ClassCastException when a message is written on a closed session.

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638840#action_12638840
 ] 

Emmanuel Lecharny commented on DIRMINA-574:
---

The Worker does not check if the Selected key is valid or not. In this case, if 
the connection has been closed, the SelectedKey will be invalid, thus should 
not be processed. As it's not checked, it is processed, leading to the problem.

We should always check if the selected key is valid _before_ doing any kind of 
processing, but that mean a deep refactoring of the selectedHandles() method. 

> ClassCastException when a message is written on a closed session.
> -
>
> Key: DIRMINA-574
> URL: https://issues.apache.org/jira/browse/DIRMINA-574
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.10, 1.1.7, 2.0.0-M1
>Reporter: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M4
>
>
> 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.
> A possible workaround is just to ignore the exception, but we need to provide 
> a correct fix for this issue.
> The following is the stack trace that explains this scenario:
> 25151 [SocketAcceptorIoProcessor-0.4] WARN  ServerPortSessionHandler  -
> > [/127.0.0.1:57120 ]
> > java.lang.ClassCastException:
> > org.apache.mina.filter.codec.ProtocolCodecFilter$MessageByteBuffer
> > incompatible with com.daishin.eai.adapter.socket.message.Por
> > tMessage
> > at
> > com.daishin.eai.adapter.socket.handler.ServerPortSessionHandler.messageSent(ServerPortSessionHandler.java:80)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageSent(AbstractIoFilterChain.java:579)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:53)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageSent(AbstractIoFilterChain.java:653)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageSent(AbstractIoFilterChain.java:504)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.fireMessageSent(AbstractIoFilterChain.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.releaseWriteBuffers(SocketIoProcessor.java:359)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProcessor.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoProcessor.java:45)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:488)
> > at
> > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> > at java.lang.Thread.run(Thread.java:810)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-629) The IoServiceStatistics methods are called for every new session creation

[Emmanuel Lecharny (JIRA)]

The IoServiceStatistics methods are called for every new session creation
-

 Key: DIRMINA-629
 URL: https://issues.apache.org/jira/browse/DIRMINA-629
 Project: MINA
  Issue Type: Bug
Reporter: Emmanuel Lecharny
Priority: Minor


When a session is established, some methods of the IoServiceStatistics class 
are called :

protected final void finishSessionInitialization(IoSession session, 
IoFuture future, IoSessionInitializer sessionInitializer) {
if (stats.getLastReadTime() == 0) {
((IoServiceStatistics)stats).setLastReadTime(getActivationTime());

There are two problems with this approach :
- first, many of the members of this classes are not thread safe, leading to 
some random value potentially be put into the stats instance for the service
- second, if we protect those members using some synchronization (or volatile 
data), it might slow down the connection initialization.

The IoServiceStatistics class should be thread safe, and these statistics 
should not be updated if the user don't want them, ie, it should be optionnal 
(the Configuration object should take care of this)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-629) The IoServiceStatistics methods are called for every new session creation

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-629:
--

Affects Version/s: 2.0.0-M3
Fix Version/s: 2.0.0-M4

> The IoServiceStatistics methods are called for every new session creation
> -
>
> Key: DIRMINA-629
> URL: https://issues.apache.org/jira/browse/DIRMINA-629
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Priority: Minor
> Fix For: 2.0.0-M4
>
>
> When a session is established, some methods of the IoServiceStatistics class 
> are called :
> protected final void finishSessionInitialization(IoSession session, 
> IoFuture future, IoSessionInitializer sessionInitializer) {
> if (stats.getLastReadTime() == 0) {
> ((IoServiceStatistics)stats).setLastReadTime(getActivationTime());
> There are two problems with this approach :
> - first, many of the members of this classes are not thread safe, leading to 
> some random value potentially be put into the stats instance for the service
> - second, if we protect those members using some synchronization (or volatile 
> data), it might slow down the connection initialization.
> The IoServiceStatistics class should be thread safe, and these statistics 
> should not be updated if the user don't want them, ie, it should be optionnal 
> (the Configuration object should take care of this)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-574) ClassCastException when a message is written on a closed session.

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-574:
--

Priority: Blocker  (was: Minor)

raised to blocker, as the underlaying logic used to handle selected keys is 
flawed.

> ClassCastException when a message is written on a closed session.
> -
>
> Key: DIRMINA-574
> URL: https://issues.apache.org/jira/browse/DIRMINA-574
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.10, 1.1.7, 2.0.0-M1
>Reporter: Trustin Lee
>Priority: Blocker
> Fix For: 2.0.0-M4
>
>
> 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.
> A possible workaround is just to ignore the exception, but we need to provide 
> a correct fix for this issue.
> The following is the stack trace that explains this scenario:
> 25151 [SocketAcceptorIoProcessor-0.4] WARN  ServerPortSessionHandler  -
> > [/127.0.0.1:57120 ]
> > java.lang.ClassCastException:
> > org.apache.mina.filter.codec.ProtocolCodecFilter$MessageByteBuffer
> > incompatible with com.daishin.eai.adapter.socket.message.Por
> > tMessage
> > at
> > com.daishin.eai.adapter.socket.handler.ServerPortSessionHandler.messageSent(ServerPortSessionHandler.java:80)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageSent(AbstractIoFilterChain.java:579)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:53)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageSent(AbstractIoFilterChain.java:653)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageSent(AbstractIoFilterChain.java:504)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.fireMessageSent(AbstractIoFilterChain.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.releaseWriteBuffers(SocketIoProcessor.java:359)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProcessor.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoProcessor.java:45)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:488)
> > at
> > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> > at java.lang.Thread.run(Thread.java:810)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FTPSERVER-195) Some boolean properties of FtpFile are not accessibile with the JavaBean isFoo()

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/FTPSERVER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639205#action_12639205
 ] 

Emmanuel Lecharny commented on FTPSERVER-195:
-

Makes sense !

Can you provide a patch for such a modification ? When it's obvious, simply 
applying a patch is certainly faster than modifying the code

> Some boolean properties of FtpFile are not accessibile with the JavaBean 
> isFoo()
> 
>
> Key: FTPSERVER-195
> URL: https://issues.apache.org/jira/browse/FTPSERVER-195
> Project: FtpServer
>  Issue Type: Bug
>Reporter: Andrea Francia
>
> We have three properties that do not follow the JavaBean convention:
> public interface FtpFile {
> boolean hasReadPermission();
> boolean hasWritePermission();
> boolean hasDeletePermission();
> ...
> }
> They could be renamed as 
> public interface FtpFile {
> boolean isReadable();
> boolean isWritable();
> boolean isRemovable();
> ...
> }
> Using the JavaBean convetion for properties allow interoperability with code 
> that uses bean introspection to access to object classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DIRMINA-626) Compilation Error in org.apache.mina.transport.serial.DefaultSerialSessionConfig

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny resolved DIRMINA-626.
---

Resolution: Fixed

atm, I just removed the @override annotations. I don't think they are useful, 
but if so, we can improve the code as suiggested.

> Compilation Error in 
> org.apache.mina.transport.serial.DefaultSerialSessionConfig
> 
>
> Key: DIRMINA-626
> URL: https://issues.apache.org/jira/browse/DIRMINA-626
> Project: MINA
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 2.0.0-M4, 2.0.0-RC1
>Reporter: Edwin Lee
>Priority: Blocker
> Fix For: 2.0.0-M4, 2.0.0-RC1
>
> Attachments: AbstractSerialSessionConfig.java, 
> DefaultSerialSessionConfig.java
>
>
> The public accessor/mutator methods in 
> org.apache.mina.transport.serial.DefaultSerialSessionConfig are annotated 
> with @Override, but its superclass 
> (org.apache.mina.core.session.AbstractIoSessionConfig) does not have those 
> methods declared.
> Propose to:
> 1. Add a new abstract class 
> org.apache.mina.transport.serial.AbstractSerialSessionConfig which extends 
> org.apache.mina.core.session.AbstractIoSessionConfig and implements 
> org.apache.mina.transport.serial.SerialSessionConfig.
> 2. The new abstract class declares the methods which 
> org.apache.mina.transport.serial.DefaultSerialSessionConfig @OverrideS.
> 3. org.apache.mina.transport.serial.DefaultSerialSessionConfig extends 
> org.apache.mina.transport.serial.AbstractSerialSessionConfig instead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-633) ProrocolCodecFilter does not swallow the complete received buffer

[Emmanuel Lecharny (JIRA)]

ProrocolCodecFilter does not swallow the complete received buffer
-

 Key: DIRMINA-633
 URL: https://issues.apache.org/jira/browse/DIRMINA-633
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M3
Reporter: Emmanuel Lecharny
Priority: Blocker
 Fix For: 2.0.0-M4


This is a major bug :
when handling a buffer and calling the decoder, we may perfectly not use all 
the buffer. In this case, the current loop is exited, when it should be 
continued.

If we have more than one protocol message in the buffer (something I'm 
currently experimenting with the LDAP protocol), we are losing some of them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DIRMINA-633) ProrocolCodecFilter does not swallow the complete received buffer

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny resolved DIRMINA-633.
---

Resolution: Fixed

Fixed with :
http://svn.apache.org/viewvc?rev=709044&view=rev

The 'break' has been removed.

> ProrocolCodecFilter does not swallow the complete received buffer
> -
>
> Key: DIRMINA-633
> URL: https://issues.apache.org/jira/browse/DIRMINA-633
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4
>
>
> This is a major bug :
> when handling a buffer and calling the decoder, we may perfectly not use all 
> the buffer. In this case, the current loop is exited, when it should be 
> continued.
> If we have more than one protocol message in the buffer (something I'm 
> currently experimenting with the LDAP protocol), we are losing some of them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DIRMINA-633) ProrocolCodecFilter does not swallow the complete received buffer

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny closed DIRMINA-633.
-


> ProrocolCodecFilter does not swallow the complete received buffer
> -
>
> Key: DIRMINA-633
> URL: https://issues.apache.org/jira/browse/DIRMINA-633
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4
>
>
> This is a major bug :
> when handling a buffer and calling the decoder, we may perfectly not use all 
> the buffer. In this case, the current loop is exited, when it should be 
> continued.
> If we have more than one protocol message in the buffer (something I'm 
> currently experimenting with the LDAP protocol), we are losing some of them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DIRMINA-574) ClassCastException when a message is written on a closed session.

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny reassigned DIRMINA-574:
-

Assignee: Emmanuel Lecharny

> ClassCastException when a message is written on a closed session.
> -
>
> Key: DIRMINA-574
> URL: https://issues.apache.org/jira/browse/DIRMINA-574
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.10, 1.1.7, 2.0.0-M1
>Reporter: Trustin Lee
>Assignee: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4
>
>
> 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.
> A possible workaround is just to ignore the exception, but we need to provide 
> a correct fix for this issue.
> The following is the stack trace that explains this scenario:
> 25151 [SocketAcceptorIoProcessor-0.4] WARN  ServerPortSessionHandler  -
> > [/127.0.0.1:57120 ]
> > java.lang.ClassCastException:
> > org.apache.mina.filter.codec.ProtocolCodecFilter$MessageByteBuffer
> > incompatible with com.daishin.eai.adapter.socket.message.Por
> > tMessage
> > at
> > com.daishin.eai.adapter.socket.handler.ServerPortSessionHandler.messageSent(ServerPortSessionHandler.java:80)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageSent(AbstractIoFilterChain.java:579)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:53)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageSent(AbstractIoFilterChain.java:653)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageSent(AbstractIoFilterChain.java:504)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.fireMessageSent(AbstractIoFilterChain.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.releaseWriteBuffers(SocketIoProcessor.java:359)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProcessor.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoProcessor.java:45)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:488)
> > at
> > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> > at java.lang.Thread.run(Thread.java:810)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-574) ClassCastException when a message is written on a closed session.

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646418#action_12646418
 ] 

Emmanuel Lecharny commented on DIRMINA-574:
---

The best way to fix this issue is to avoid emitting this totally useless 
MessageSent event. I don't know why it has been created, but in any case, it 
will be a relief to get rid of it, as it generates problems and does not help 
at all...

> ClassCastException when a message is written on a closed session.
> -
>
> Key: DIRMINA-574
> URL: https://issues.apache.org/jira/browse/DIRMINA-574
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.10, 1.1.7, 2.0.0-M1
>Reporter: Trustin Lee
>Assignee: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4
>
>
> 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.
> A possible workaround is just to ignore the exception, but we need to provide 
> a correct fix for this issue.
> The following is the stack trace that explains this scenario:
> 25151 [SocketAcceptorIoProcessor-0.4] WARN  ServerPortSessionHandler  -
> > [/127.0.0.1:57120 ]
> > java.lang.ClassCastException:
> > org.apache.mina.filter.codec.ProtocolCodecFilter$MessageByteBuffer
> > incompatible with com.daishin.eai.adapter.socket.message.Por
> > tMessage
> > at
> > com.daishin.eai.adapter.socket.handler.ServerPortSessionHandler.messageSent(ServerPortSessionHandler.java:80)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageSent(AbstractIoFilterChain.java:579)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:53)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageSent(AbstractIoFilterChain.java:653)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageSent(AbstractIoFilterChain.java:504)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.fireMessageSent(AbstractIoFilterChain.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.releaseWriteBuffers(SocketIoProcessor.java:359)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProcessor.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoProcessor.java:45)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:488)
> > at
> > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> > at java.lang.Thread.run(Thread.java:810)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-635) The IoFilter.preAdd method should take an IoSession argument

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646583#action_12646583
 ] 

Emmanuel Lecharny commented on DIRMINA-635:
---

The preAdd method takes a IoFilterChain as a first argument, which has a 
getSession() method, so there is no need to pass a IoSession.

It will then be easy to modify the preAdd method to initialize the encoder and 
decoder there, instead of doing so in the sessionCreated() method.

Also we have to do it in both case, as the preAdd method is not called when the 
filter is added in the chain outside of the session.

> The IoFilter.preAdd method should take an IoSession argument
> 
>
> Key: DIRMINA-635
> URL: https://issues.apache.org/jira/browse/DIRMINA-635
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>
> When injected an ProtocolCodecFilter in a chain when a session is already 
> created, the encoder and decoder are never injected into the session's 
> attribute, leading to NPE.
> This could be fixed if we create those objects during the preAdd() phase, but 
> we need to pass the session to this preAdd method. Anyway, it makes sense, as 
> we may want to update some session's attribute during the addition, just in 
> case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DIRMINA-635) The IoFilter.preAdd method should take an IoSession argument

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny reassigned DIRMINA-635:
-

Assignee: Emmanuel Lecharny

> The IoFilter.preAdd method should take an IoSession argument
> 
>
> Key: DIRMINA-635
> URL: https://issues.apache.org/jira/browse/DIRMINA-635
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>
> When injected an ProtocolCodecFilter in a chain when a session is already 
> created, the encoder and decoder are never injected into the session's 
> attribute, leading to NPE.
> This could be fixed if we create those objects during the preAdd() phase, but 
> we need to pass the session to this preAdd method. Anyway, it makes sense, as 
> we may want to update some session's attribute during the addition, just in 
> case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-636) The ProtocolDecoderOutput class initialization will fail if some filter is added after the codec

[Emmanuel Lecharny (JIRA)]

The ProtocolDecoderOutput class initialization will fail if some filter is 
added after the codec


 Key: DIRMINA-636
 URL: https://issues.apache.org/jira/browse/DIRMINA-636
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M3
Reporter: Emmanuel Lecharny


The way this class is initialized is wrong : it takes the nextFilter as a 
parameter, which means we can't add a filter after the codec without having a 
broken chain.

Here is the method which initialize this object :

private ProtocolDecoderOutput getDecoderOut(IoSession session,
NextFilter nextFilter) {
ProtocolDecoderOutput out = (ProtocolDecoderOutput) 
session.getAttribute(DECODER_OUT);
if (out == null) {
out = new ProtocolDecoderOutputImpl(session, nextFilter);  <= 
This is WRONG
session.setAttribute(DECODER_OUT, out);
}
return out;
}

It would be way better not to pass the  to the 
constructor, but passing them to the flush() method, avoiding any potential 
problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DIRMINA-635) The IoFilter.preAdd method should take an IoSession argument

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny resolved DIRMINA-635.
---

Resolution: Fixed

Fixed with : http://svn.apache.org/viewvc?rev=713125&view=rev

> The IoFilter.preAdd method should take an IoSession argument
> 
>
> Key: DIRMINA-635
> URL: https://issues.apache.org/jira/browse/DIRMINA-635
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>
> When injected an ProtocolCodecFilter in a chain when a session is already 
> created, the encoder and decoder are never injected into the session's 
> attribute, leading to NPE.
> This could be fixed if we create those objects during the preAdd() phase, but 
> we need to pass the session to this preAdd method. Anyway, it makes sense, as 
> we may want to update some session's attribute during the addition, just in 
> case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DIRMINA-635) The IoFilter.preAdd method should take an IoSession argument

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny closed DIRMINA-635.
-


> The IoFilter.preAdd method should take an IoSession argument
> 
>
> Key: DIRMINA-635
> URL: https://issues.apache.org/jira/browse/DIRMINA-635
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>
> When injected an ProtocolCodecFilter in a chain when a session is already 
> created, the encoder and decoder are never injected into the session's 
> attribute, leading to NPE.
> This could be fixed if we create those objects during the preAdd() phase, but 
> we need to pass the session to this preAdd method. Anyway, it makes sense, as 
> we may want to update some session's attribute during the addition, just in 
> case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DIRMINA-636) The ProtocolDecoderOutput class initialization will fail if some filter is added after the codec

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny reassigned DIRMINA-636:
-

Assignee: Emmanuel Lecharny

> The ProtocolDecoderOutput class initialization will fail if some filter is 
> added after the codec
> 
>
> Key: DIRMINA-636
> URL: https://issues.apache.org/jira/browse/DIRMINA-636
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>
> The way this class is initialized is wrong : it takes the nextFilter as a 
> parameter, which means we can't add a filter after the codec without having a 
> broken chain.
> Here is the method which initialize this object :
> private ProtocolDecoderOutput getDecoderOut(IoSession session,
> NextFilter nextFilter) {
> ProtocolDecoderOutput out = (ProtocolDecoderOutput) 
> session.getAttribute(DECODER_OUT);
> if (out == null) {
> out = new ProtocolDecoderOutputImpl(session, nextFilter);  <= 
> This is WRONG
> session.setAttribute(DECODER_OUT, out);
> }
> return out;
> }
> It would be way better not to pass the  to the 
> constructor, but passing them to the flush() method, avoiding any potential 
> problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DIRMINA-636) The ProtocolDecoderOutput class initialization will fail if some filter is added after the codec

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny closed DIRMINA-636.
-


> The ProtocolDecoderOutput class initialization will fail if some filter is 
> added after the codec
> 
>
> Key: DIRMINA-636
> URL: https://issues.apache.org/jira/browse/DIRMINA-636
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>
> The way this class is initialized is wrong : it takes the nextFilter as a 
> parameter, which means we can't add a filter after the codec without having a 
> broken chain.
> Here is the method which initialize this object :
> private ProtocolDecoderOutput getDecoderOut(IoSession session,
> NextFilter nextFilter) {
> ProtocolDecoderOutput out = (ProtocolDecoderOutput) 
> session.getAttribute(DECODER_OUT);
> if (out == null) {
> out = new ProtocolDecoderOutputImpl(session, nextFilter);  <= 
> This is WRONG
> session.setAttribute(DECODER_OUT, out);
> }
> return out;
> }
> It would be way better not to pass the  to the 
> constructor, but passing them to the flush() method, avoiding any potential 
> problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DIRMINA-636) The ProtocolDecoderOutput class initialization will fail if some filter is added after the codec

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny resolved DIRMINA-636.
---

Resolution: Fixed

Fixed with : http://svn.apache.org/viewvc?rev=713125&view=rev

> The ProtocolDecoderOutput class initialization will fail if some filter is 
> added after the codec
> 
>
> Key: DIRMINA-636
> URL: https://issues.apache.org/jira/browse/DIRMINA-636
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>
> The way this class is initialized is wrong : it takes the nextFilter as a 
> parameter, which means we can't add a filter after the codec without having a 
> broken chain.
> Here is the method which initialize this object :
> private ProtocolDecoderOutput getDecoderOut(IoSession session,
> NextFilter nextFilter) {
> ProtocolDecoderOutput out = (ProtocolDecoderOutput) 
> session.getAttribute(DECODER_OUT);
> if (out == null) {
> out = new ProtocolDecoderOutputImpl(session, nextFilter);  <= 
> This is WRONG
> session.setAttribute(DECODER_OUT, out);
> }
> return out;
> }
> It would be way better not to pass the  to the 
> constructor, but passing them to the flush() method, avoiding any potential 
> problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-635) The IoFilter.preAdd method should take an IoSession argument

[Emmanuel Lecharny (JIRA)]

The IoFilter.preAdd method should take an IoSession argument


 Key: DIRMINA-635
 URL: https://issues.apache.org/jira/browse/DIRMINA-635
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M3
Reporter: Emmanuel Lecharny


When injected an ProtocolCodecFilter in a chain when a session is already 
created, the encoder and decoder are never injected into the session's 
attribute, leading to NPE.

This could be fixed if we create those objects during the preAdd() phase, but 
we need to pass the session to this preAdd method. Anyway, it makes sense, as 
we may want to update some session's attribute during the addition, just in 
case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-596) Sessions generated by NioSocketConnector cannot be closed in time (within MINA2.0 M1,M2)

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647575#action_12647575
 ] 

Emmanuel Lecharny commented on DIRMINA-596:
---

A fully working sample would help to analyze the situation. The drops of code 
we currently have are not enough ...

Thanks !

> Sessions generated by NioSocketConnector cannot be closed in time (within 
> MINA2.0 M1,M2)
> 
>
> Key: DIRMINA-596
> URL: https://issues.apache.org/jira/browse/DIRMINA-596
> Project: MINA
>  Issue Type: Bug
>  Components: Core, Transport
>Affects Versions: 2.0.0-M1, 2.0.0-M2
> Environment: MINA:mina-core-2.0.0-M2-20080427.091119-1.jar
> JDK: java version "1.5.0_05"
> Plat: Windows XP
>Reporter: Silver
>
> I use MINA 2.0.0 M1 and M2 to build my application.
> When I use one NioSocketConnector to generate 10 sessions and then close them 
> in the messageReceived event of each session, only 5 or 6 sessions(that is to 
> say, not of all sessions)  can be closed correctly, others cannot, but I can 
> receive the sessionClosed event. The number of the closed sessions varies 
> from 2-6 during my experiments.
> Another intersting event will occur:
>Since the rest sessions cannot be closed, I tried to generate a new 
> session by the same NioSocketConnector, then all of the 10 "old" sessions 
> were closed as one might expect, except the last new session.
> the main method:
> public static void main(String[] args)
> {
> NioSocketConnector acceptor = new NioSocketConnector();
> acceptor.setDefaultRemoteAddress(new InetSocketAddress("127.0.0.1", 
> 2361));
> acceptor.getFilterChain().addLast( "executor", new 
> ExecutorFilter(100) );
> acceptor.setHandler( new TimeServerHandler() );
> for(int i=0; i<10; i++)
> acceptor.connect();
> }
> the messageReceived method in TimeServerHandler class:
> public void messageReceived(IoSession session, Object message)
> throws Exception
> {
> System.out.println(((IoBuffer) 
> message).getString(Charset.forName("UTF-8")
> .newDecoder()));
> session.close();
> }
> the log of the test server:
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3211>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3212>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3213>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3214>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3215>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3216>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3217>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3218>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3219>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3220>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3211>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3213>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3214>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3212>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3216>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3215>
> 2008-5-27 17:09:37 Connected 127.0.0.1 / 3221>
> 2008-5-27 17:09:37 Disconnected ---127.0.0.1 / 3217>
> 2008-5-27 17:09:37 Disconnected ---127.0.0.1 / 3218>
> 2008-5-27 17:09:37 Disconnected ---127.0.0.1 / 3219>
> 2008-5-27 17:09:37 Disconnected ---127.0.0.1 / 3220>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-625) How to use the function awaitUninterruptibly or await

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647646#action_12647646
 ] 

Emmanuel Lecharny commented on DIRMINA-625:
---

Can you post a sample of code we can test ?

Thanks !

> How to use the function awaitUninterruptibly or await
> -
>
> Key: DIRMINA-625
> URL: https://issues.apache.org/jira/browse/DIRMINA-625
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M3
>Reporter: ben
>
> Always reported abnormal DEAD LOCK, How to use it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-629) The IoServiceStatistics methods are called for every new session creation

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-629:
--

Issue Type: Improvement  (was: Bug)

Not  really a bug ...

> The IoServiceStatistics methods are called for every new session creation
> -
>
> Key: DIRMINA-629
> URL: https://issues.apache.org/jira/browse/DIRMINA-629
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Priority: Minor
> Fix For: 2.0.0-M4
>
>
> When a session is established, some methods of the IoServiceStatistics class 
> are called :
> protected final void finishSessionInitialization(IoSession session, 
> IoFuture future, IoSessionInitializer sessionInitializer) {
> if (stats.getLastReadTime() == 0) {
> ((IoServiceStatistics)stats).setLastReadTime(getActivationTime());
> There are two problems with this approach :
> - first, many of the members of this classes are not thread safe, leading to 
> some random value potentially be put into the stats instance for the service
> - second, if we protect those members using some synchronization (or volatile 
> data), it might slow down the connection initialization.
> The IoServiceStatistics class should be thread safe, and these statistics 
> should not be updated if the user don't want them, ie, it should be optionnal 
> (the Configuration object should take care of this)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-638) DefaultSocketSessionConfig creates some connection to itself.

[Emmanuel Lecharny (JIRA)]

DefaultSocketSessionConfig creates some connection to itself.
-

 Key: DIRMINA-638
 URL: https://issues.apache.org/jira/browse/DIRMINA-638
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M3
Reporter: Emmanuel Lecharny
Priority: Blocker
 Fix For: 2.0.0-M4


For some unknown reason, the DefaultSocketSessionConfig class is creating a 
ServerSocket, and create a connection  :

static {
initializeTestAddresses();

boolean success = false;
for (Entry e : 
TEST_ADDRESSES.entrySet()) {
success = initializeDefaultSocketParameters(e.getKey(), 
e.getValue());
if (success) {
break;
}
}

private static void initializeTestAddresses() {
try {
TEST_ADDRESSES.put(new InetSocketAddress(0), 
InetAddress.getByAddress(new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 0, 
0, 1 }));
TEST_ADDRESSES.put(new InetSocketAddress(0), 
InetAddress.getByAddress(new byte[] { 127, 0, 0, 1 }));
} catch (UnknownHostException e) {
ExceptionMonitor.getInstance().exceptionCaught(e);
}
}


private static boolean initializeDefaultSocketParameters(InetSocketAddress 
bindAddress, InetAddress connectAddress) {
ServerSocket ss = null;
Socket socket = null;

try {
ss = new ServerSocket();
ss.bind(bindAddress);
socket = new Socket();

socket.connect(new InetSocketAddress(connectAddress, 
ss.getLocalPort()), 1);

initializeDefaultSocketParameters(socket);
return true;
} catch (IOException ioe) {
return false;
} finally {
if (socket != null) {
try {
socket.close();
} catch (IOException e) {
ExceptionMonitor.getInstance().exceptionCaught(e);
}
}

if (ss != null) {
try {
ss.close();
} catch (IOException e) {
ExceptionMonitor.getInstance().exceptionCaught(e);
}
}
   }
}

The _only_ reason why this code exists is to setup the default values for the 
socket configuration. 

Not only is this bad code, but also a totally wrong thing to do : in many 
environment, creating sockets this way will lead to breakages (Applet, etc).

It as to be fixed urgently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-638) DefaultSocketSessionConfig creates some connection to itself.

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-638:
--

Affects Version/s: 1.1.7
Fix Version/s: 1.1.8

It affects also 1.1.7, and the Datagram support.

> DefaultSocketSessionConfig creates some connection to itself.
> -
>
> Key: DIRMINA-638
> URL: https://issues.apache.org/jira/browse/DIRMINA-638
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 1.1.7, 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4, 1.1.8
>
>
> For some unknown reason, the DefaultSocketSessionConfig class is creating a 
> ServerSocket, and create a connection  :
> static {
> initializeTestAddresses();
> boolean success = false;
> for (Entry e : 
> TEST_ADDRESSES.entrySet()) {
> success = initializeDefaultSocketParameters(e.getKey(), 
> e.getValue());
> if (success) {
> break;
> }
> }
> private static void initializeTestAddresses() {
> try {
> TEST_ADDRESSES.put(new InetSocketAddress(0), 
> InetAddress.getByAddress(new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 
> 0, 0, 1 }));
> TEST_ADDRESSES.put(new InetSocketAddress(0), 
> InetAddress.getByAddress(new byte[] { 127, 0, 0, 1 }));
> } catch (UnknownHostException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> private static boolean 
> initializeDefaultSocketParameters(InetSocketAddress bindAddress, InetAddress 
> connectAddress) {
> ServerSocket ss = null;
> Socket socket = null;
> try {
> ss = new ServerSocket();
> ss.bind(bindAddress);
> socket = new Socket();
> socket.connect(new InetSocketAddress(connectAddress, 
> ss.getLocalPort()), 1);
> initializeDefaultSocketParameters(socket);
> return true;
> } catch (IOException ioe) {
> return false;
> } finally {
> if (socket != null) {
> try {
> socket.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> if (ss != null) {
> try {
> ss.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
>}
> }
> The _only_ reason why this code exists is to setup the default values for the 
> socket configuration. 
> Not only is this bad code, but also a totally wrong thing to do : in many 
> environment, creating sockets this way will lead to breakages (Applet, etc).
> It as to be fixed urgently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-628) Windows Firewall security issue when configuring socket

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-628:
--

Affects Version/s: 2.0.0-M3
Fix Version/s: 1.1.8
   2.0.0-M4

Will affect 2.0.0-M3 too

> Windows Firewall security issue when configuring socket
> ---
>
> Key: DIRMINA-628
> URL: https://issues.apache.org/jira/browse/DIRMINA-628
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.7, 2.0.0-M3
> Environment: Windows Vista 32 and 64-bit
>Reporter: Mauritz Lovgren
>Priority: Critical
> Fix For: 2.0.0-M4, 1.1.8
>
>
> When upgrading to MINA 1.1.7, we suddenly get Windows Firewall dialog 
> complaining about our software trying to perform an operation that needs to 
> be blocked / unblocked before continuing.
> This does NOT happen with MINA 1.1.5.
> Tried to identify where in MINA this happens, but no exceptions are thrown by 
> the Java code and the application continues without errors after Windows 
> Firewall dialog has been closed, either by allowing the application to 
> continue by unblocking it, or by blocking the offending operation.
> This might not seem to be a big problem, since after unblocking the 
> application once the firewall security dialog is avoided in subsequent 
> application startups, but for a restricted Vista user (as most of our 
> customer clients are), the dialog will appear at every application startup 
> since a restricted user does not have the permission to unblock the 
> application.
> Our client application only starts one outbound (client) connection towards 
> our server application and should not at any sircumstance start a listening 
> socket on the client machine.
> The problem can be verified by removing any existing Vista firewall rules for 
> all Java processes and start a MINA client that creates one outbound client 
> socket towards another machine. A windows firewall security dialog should 
> appear on the client machine. Try the same thing with MINA 1.1.5 and no 
> security dialog appears.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-638) DefaultSocketSessionConfig creates some connection to itself.

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648419#action_12648419
 ] 

Emmanuel Lecharny commented on DIRMINA-638:
---

Yeah, I just created a lonk on it.

It may be reliable, but the problem is that when used in an Applet, it will 
simply not work. We are 'happy' that Alexander not only have had the problem, 
but was clever enough to dig it and found what was the problem ! I was totally 
unaware that this class was doing such a socket connection...

> DefaultSocketSessionConfig creates some connection to itself.
> -
>
> Key: DIRMINA-638
> URL: https://issues.apache.org/jira/browse/DIRMINA-638
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 1.1.7, 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4, 1.1.8
>
>
> For some unknown reason, the DefaultSocketSessionConfig class is creating a 
> ServerSocket, and create a connection  :
> static {
> initializeTestAddresses();
> boolean success = false;
> for (Entry e : 
> TEST_ADDRESSES.entrySet()) {
> success = initializeDefaultSocketParameters(e.getKey(), 
> e.getValue());
> if (success) {
> break;
> }
> }
> private static void initializeTestAddresses() {
> try {
> TEST_ADDRESSES.put(new InetSocketAddress(0), 
> InetAddress.getByAddress(new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 
> 0, 0, 1 }));
> TEST_ADDRESSES.put(new InetSocketAddress(0), 
> InetAddress.getByAddress(new byte[] { 127, 0, 0, 1 }));
> } catch (UnknownHostException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> private static boolean 
> initializeDefaultSocketParameters(InetSocketAddress bindAddress, InetAddress 
> connectAddress) {
> ServerSocket ss = null;
> Socket socket = null;
> try {
> ss = new ServerSocket();
> ss.bind(bindAddress);
> socket = new Socket();
> socket.connect(new InetSocketAddress(connectAddress, 
> ss.getLocalPort()), 1);
> initializeDefaultSocketParameters(socket);
> return true;
> } catch (IOException ioe) {
> return false;
> } finally {
> if (socket != null) {
> try {
> socket.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> if (ss != null) {
> try {
> ss.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
>}
> }
> The _only_ reason why this code exists is to setup the default values for the 
> socket configuration. 
> Not only is this bad code, but also a totally wrong thing to do : in many 
> environment, creating sockets this way will lead to breakages (Applet, etc).
> It as to be fixed urgently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DIRMINA-638) DefaultSocketSessionConfig creates some connection to itself.

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny reassigned DIRMINA-638:
-

Assignee: Emmanuel Lecharny

> DefaultSocketSessionConfig creates some connection to itself.
> -
>
> Key: DIRMINA-638
> URL: https://issues.apache.org/jira/browse/DIRMINA-638
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 1.1.7, 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4, 1.1.8
>
>
> For some unknown reason, the DefaultSocketSessionConfig class is creating a 
> ServerSocket, and create a connection  :
> static {
> initializeTestAddresses();
> boolean success = false;
> for (Entry e : 
> TEST_ADDRESSES.entrySet()) {
> success = initializeDefaultSocketParameters(e.getKey(), 
> e.getValue());
> if (success) {
> break;
> }
> }
> private static void initializeTestAddresses() {
> try {
> TEST_ADDRESSES.put(new InetSocketAddress(0), 
> InetAddress.getByAddress(new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 
> 0, 0, 1 }));
> TEST_ADDRESSES.put(new InetSocketAddress(0), 
> InetAddress.getByAddress(new byte[] { 127, 0, 0, 1 }));
> } catch (UnknownHostException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> private static boolean 
> initializeDefaultSocketParameters(InetSocketAddress bindAddress, InetAddress 
> connectAddress) {
> ServerSocket ss = null;
> Socket socket = null;
> try {
> ss = new ServerSocket();
> ss.bind(bindAddress);
> socket = new Socket();
> socket.connect(new InetSocketAddress(connectAddress, 
> ss.getLocalPort()), 1);
> initializeDefaultSocketParameters(socket);
> return true;
> } catch (IOException ioe) {
> return false;
> } finally {
> if (socket != null) {
> try {
> socket.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> if (ss != null) {
> try {
> ss.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
>}
> }
> The _only_ reason why this code exists is to setup the default values for the 
> socket configuration. 
> Not only is this bad code, but also a totally wrong thing to do : in many 
> environment, creating sockets this way will lead to breakages (Applet, etc).
> It as to be fixed urgently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DIRMINA-628) Windows Firewall security issue when configuring socket

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny reassigned DIRMINA-628:
-

Assignee: Emmanuel Lecharny

> Windows Firewall security issue when configuring socket
> ---
>
> Key: DIRMINA-628
> URL: https://issues.apache.org/jira/browse/DIRMINA-628
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.7, 2.0.0-M3
> Environment: Windows Vista 32 and 64-bit
>Reporter: Mauritz Lovgren
>Assignee: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M4, 1.1.8
>
>
> When upgrading to MINA 1.1.7, we suddenly get Windows Firewall dialog 
> complaining about our software trying to perform an operation that needs to 
> be blocked / unblocked before continuing.
> This does NOT happen with MINA 1.1.5.
> Tried to identify where in MINA this happens, but no exceptions are thrown by 
> the Java code and the application continues without errors after Windows 
> Firewall dialog has been closed, either by allowing the application to 
> continue by unblocking it, or by blocking the offending operation.
> This might not seem to be a big problem, since after unblocking the 
> application once the firewall security dialog is avoided in subsequent 
> application startups, but for a restricted Vista user (as most of our 
> customer clients are), the dialog will appear at every application startup 
> since a restricted user does not have the permission to unblock the 
> application.
> Our client application only starts one outbound (client) connection towards 
> our server application and should not at any sircumstance start a listening 
> socket on the client machine.
> The problem can be verified by removing any existing Vista firewall rules for 
> all Java processes and start a MINA client that creates one outbound client 
> socket towards another machine. A windows firewall security dialog should 
> appear on the client machine. Try the same thing with MINA 1.1.5 and no 
> security dialog appears.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-638) DefaultSocketSessionConfig creates some connection to itself.

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648623#action_12648623
 ] 

Emmanuel Lecharny commented on DIRMINA-638:
---

It should be fixed in 2.0.0-M3-SNAPSHOT

> DefaultSocketSessionConfig creates some connection to itself.
> -
>
> Key: DIRMINA-638
> URL: https://issues.apache.org/jira/browse/DIRMINA-638
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 1.1.7, 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4, 1.1.8
>
>
> For some unknown reason, the DefaultSocketSessionConfig class is creating a 
> ServerSocket, and create a connection  :
> static {
> initializeTestAddresses();
> boolean success = false;
> for (Entry e : 
> TEST_ADDRESSES.entrySet()) {
> success = initializeDefaultSocketParameters(e.getKey(), 
> e.getValue());
> if (success) {
> break;
> }
> }
> private static void initializeTestAddresses() {
> try {
> TEST_ADDRESSES.put(new InetSocketAddress(0), 
> InetAddress.getByAddress(new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 
> 0, 0, 1 }));
> TEST_ADDRESSES.put(new InetSocketAddress(0), 
> InetAddress.getByAddress(new byte[] { 127, 0, 0, 1 }));
> } catch (UnknownHostException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> private static boolean 
> initializeDefaultSocketParameters(InetSocketAddress bindAddress, InetAddress 
> connectAddress) {
> ServerSocket ss = null;
> Socket socket = null;
> try {
> ss = new ServerSocket();
> ss.bind(bindAddress);
> socket = new Socket();
> socket.connect(new InetSocketAddress(connectAddress, 
> ss.getLocalPort()), 1);
> initializeDefaultSocketParameters(socket);
> return true;
> } catch (IOException ioe) {
> return false;
> } finally {
> if (socket != null) {
> try {
> socket.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> if (ss != null) {
> try {
> ss.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
>}
> }
> The _only_ reason why this code exists is to setup the default values for the 
> socket configuration. 
> Not only is this bad code, but also a totally wrong thing to do : in many 
> environment, creating sockets this way will lead to breakages (Applet, etc).
> It as to be fixed urgently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-628) Windows Firewall security issue when configuring socket

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648624#action_12648624
 ] 

Emmanuel Lecharny commented on DIRMINA-628:
---

It should be fixed in 2.0 trunk :
http://svn.apache.org/viewvc?rev=718595&view=rev

> Windows Firewall security issue when configuring socket
> ---
>
> Key: DIRMINA-628
> URL: https://issues.apache.org/jira/browse/DIRMINA-628
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.7, 2.0.0-M3
> Environment: Windows Vista 32 and 64-bit
>Reporter: Mauritz Lovgren
>Assignee: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M4, 1.1.8
>
>
> When upgrading to MINA 1.1.7, we suddenly get Windows Firewall dialog 
> complaining about our software trying to perform an operation that needs to 
> be blocked / unblocked before continuing.
> This does NOT happen with MINA 1.1.5.
> Tried to identify where in MINA this happens, but no exceptions are thrown by 
> the Java code and the application continues without errors after Windows 
> Firewall dialog has been closed, either by allowing the application to 
> continue by unblocking it, or by blocking the offending operation.
> This might not seem to be a big problem, since after unblocking the 
> application once the firewall security dialog is avoided in subsequent 
> application startups, but for a restricted Vista user (as most of our 
> customer clients are), the dialog will appear at every application startup 
> since a restricted user does not have the permission to unblock the 
> application.
> Our client application only starts one outbound (client) connection towards 
> our server application and should not at any sircumstance start a listening 
> socket on the client machine.
> The problem can be verified by removing any existing Vista firewall rules for 
> all Java processes and start a MINA client that creates one outbound client 
> socket towards another machine. A windows firewall security dialog should 
> appear on the client machine. Try the same thing with MINA 1.1.5 and no 
> security dialog appears.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-628) Windows Firewall security issue when configuring socket

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-628:
--

Affects Version/s: (was: 2.0.0-M3)
Fix Version/s: (was: 2.0.0-M4)

Fixed on 2.0.0-M4

> Windows Firewall security issue when configuring socket
> ---
>
> Key: DIRMINA-628
> URL: https://issues.apache.org/jira/browse/DIRMINA-628
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.7
> Environment: Windows Vista 32 and 64-bit
>Reporter: Mauritz Lovgren
>Assignee: Emmanuel Lecharny
>Priority: Critical
> Fix For: 1.1.8
>
>
> When upgrading to MINA 1.1.7, we suddenly get Windows Firewall dialog 
> complaining about our software trying to perform an operation that needs to 
> be blocked / unblocked before continuing.
> This does NOT happen with MINA 1.1.5.
> Tried to identify where in MINA this happens, but no exceptions are thrown by 
> the Java code and the application continues without errors after Windows 
> Firewall dialog has been closed, either by allowing the application to 
> continue by unblocking it, or by blocking the offending operation.
> This might not seem to be a big problem, since after unblocking the 
> application once the firewall security dialog is avoided in subsequent 
> application startups, but for a restricted Vista user (as most of our 
> customer clients are), the dialog will appear at every application startup 
> since a restricted user does not have the permission to unblock the 
> application.
> Our client application only starts one outbound (client) connection towards 
> our server application and should not at any sircumstance start a listening 
> socket on the client machine.
> The problem can be verified by removing any existing Vista firewall rules for 
> all Java processes and start a MINA client that creates one outbound client 
> socket towards another machine. A windows firewall security dialog should 
> appear on the client machine. Try the same thing with MINA 1.1.5 and no 
> security dialog appears.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-638) DefaultSocketSessionConfig creates some connection to itself.

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-638:
--

Affects Version/s: (was: 2.0.0-M3)
Fix Version/s: (was: 2.0.0-M4)

Just kept 1.1.7 as the problem is fixed for 2.0.0-M3 (hopefully)

> DefaultSocketSessionConfig creates some connection to itself.
> -
>
> Key: DIRMINA-638
> URL: https://issues.apache.org/jira/browse/DIRMINA-638
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 1.1.7
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 1.1.8
>
>
> For some unknown reason, the DefaultSocketSessionConfig class is creating a 
> ServerSocket, and create a connection  :
> static {
> initializeTestAddresses();
> boolean success = false;
> for (Entry e : 
> TEST_ADDRESSES.entrySet()) {
> success = initializeDefaultSocketParameters(e.getKey(), 
> e.getValue());
> if (success) {
> break;
> }
> }
> private static void initializeTestAddresses() {
> try {
> TEST_ADDRESSES.put(new InetSocketAddress(0), 
> InetAddress.getByAddress(new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 
> 0, 0, 1 }));
> TEST_ADDRESSES.put(new InetSocketAddress(0), 
> InetAddress.getByAddress(new byte[] { 127, 0, 0, 1 }));
> } catch (UnknownHostException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> private static boolean 
> initializeDefaultSocketParameters(InetSocketAddress bindAddress, InetAddress 
> connectAddress) {
> ServerSocket ss = null;
> Socket socket = null;
> try {
> ss = new ServerSocket();
> ss.bind(bindAddress);
> socket = new Socket();
> socket.connect(new InetSocketAddress(connectAddress, 
> ss.getLocalPort()), 1);
> initializeDefaultSocketParameters(socket);
> return true;
> } catch (IOException ioe) {
> return false;
> } finally {
> if (socket != null) {
> try {
> socket.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> if (ss != null) {
> try {
> ss.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
>}
> }
> The _only_ reason why this code exists is to setup the default values for the 
> socket configuration. 
> Not only is this bad code, but also a totally wrong thing to do : in many 
> environment, creating sockets this way will lead to breakages (Applet, etc).
> It as to be fixed urgently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny reassigned DIRMINA-539:
-

Assignee: Emmanuel Lecharny  (was: Julien Vermillard)

> NioDatagramConnector doesn't takes the TrafficClass value set to his 
> DatagramSessionConfig 
> ---
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
>Reporter: martin krivosik
>Assignee: Emmanuel Lecharny
> Fix For: 2.0.0-M4
>
>   Original Estimate: 0.33h
>  Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the 
> config, so the ToS byte is not set in the packet sent from client.
> client code:
>   NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
>   DatagramSessionConfig dcfg = 
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
>   dcfg.setTrafficClass(tosByte);
>   InetSocketAddress bindAddrPort  = new InetSocketAddress(originatingIP, 
> port);
>   acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not 
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in 
> the packet.
> (the same problem may be in the socket, i have to check it)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648684#action_12648684
 ] 

Emmanuel Lecharny commented on DIRMINA-539:
---

I think that all those checks (can we set/get traffic class on a 
socket/datagram) is totally useless. Either you can, or you can't, but in the 
second case, it simply does nothing.

Now, the current implementation is totally FU, because we do things like :

public void setTrafficClass(int trafficClass) {
if (DefaultDatagramSessionConfig.isSetTrafficClassAvailable()) {
try {
c.socket().setTrafficClass(trafficClass);
...

with :
public static boolean isSetTrafficClassAvailable() {
return SET_TRAFFIC_CLASS_AVAILABLE;
}

and, ultimately :

private static final boolean SET_TRAFFIC_CLASS_AVAILABLE = false;

This is a dead end : the isSetTrafficClassAvailable() will always return false.

Here is what I suggest : we simply get rid of all those controls, and let the 
user set/get the traffic class at will. If the underlaying network does not 
support it, well, it's fine, no harm.



> NioDatagramConnector doesn't takes the TrafficClass value set to his 
> DatagramSessionConfig 
> ---
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
>Reporter: martin krivosik
>Assignee: Emmanuel Lecharny
> Fix For: 2.0.0-M4
>
>   Original Estimate: 0.33h
>  Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the 
> config, so the ToS byte is not set in the packet sent from client.
> client code:
>   NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
>   DatagramSessionConfig dcfg = 
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
>   dcfg.setTrafficClass(tosByte);
>   InetSocketAddress bindAddrPort  = new InetSocketAddress(originatingIP, 
> port);
>   acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not 
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in 
> the packet.
> (the same problem may be in the socket, i have to check it)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648692#action_12648692
 ] 

Emmanuel Lecharny commented on DIRMINA-539:
---

What we can do is something like :

boolean isSetTrafficClassAvailable(Socket socket) {
  try {
int tc = socket.getTrafficClass();
socket.setTrafficClass((~tc)&0x001E);
boolean supported = (tc != socket.getTrafficClass());
socket.setTrafficClass(tc);
return supported;
  } catch (Exception e) {
return false;
  }
}

but it seems a bit overkilling...

> NioDatagramConnector doesn't takes the TrafficClass value set to his 
> DatagramSessionConfig 
> ---
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
>Reporter: martin krivosik
>Assignee: Emmanuel Lecharny
> Fix For: 2.0.0-M4
>
>   Original Estimate: 0.33h
>  Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the 
> config, so the ToS byte is not set in the packet sent from client.
> client code:
>   NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
>   DatagramSessionConfig dcfg = 
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
>   dcfg.setTrafficClass(tosByte);
>   InetSocketAddress bindAddrPort  = new InetSocketAddress(originatingIP, 
> port);
>   acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not 
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in 
> the packet.
> (the same problem may be in the socket, i have to check it)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648780#action_12648780
 ] 

Emmanuel Lecharny commented on DIRMINA-539:
---

Well, itwon't work :
- first, you don't pass a new traffic class
- second, I don't think that it's necessary anyway.

The contract is pretty clear :
"As the underlying network implementation may ignore this  value applications 
should consider it a hint.   "

http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#setTrafficClass(int)

Let's do simple things, and when it becomes complicated, just think twice 
before injected convoluted code.

> NioDatagramConnector doesn't takes the TrafficClass value set to his 
> DatagramSessionConfig 
> ---
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
>Reporter: martin krivosik
>Assignee: Emmanuel Lecharny
> Fix For: 2.0.0-M4
>
>   Original Estimate: 0.33h
>  Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the 
> config, so the ToS byte is not set in the packet sent from client.
> client code:
>   NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
>   DatagramSessionConfig dcfg = 
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
>   dcfg.setTrafficClass(tosByte);
>   InetSocketAddress bindAddrPort  = new InetSocketAddress(originatingIP, 
> port);
>   acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not 
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in 
> the packet.
> (the same problem may be in the socket, i have to check it)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648934#action_12648934
 ] 

Emmanuel Lecharny commented on DIRMINA-539:
---

The question is : do we really need this method in 2.0 (ie, 
isSetTrafficClassAvailable). The main problem is that we need an open socket in 
order to check that, and we have to set the traffic class, and reset it, to be 
sure that it's possible. As the Traffic Class is absolutely not guaranteed to 
be used by the underlying network layer, I think it's a lot of effort for a 
small improvement.

Now, this can be discussed. I understand that, from the user POV, masking all 
this complexity is good, but when a user tries to manipulate such advanced 
features, I think that it should be explicit.

> NioDatagramConnector doesn't takes the TrafficClass value set to his 
> DatagramSessionConfig 
> ---
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
>Reporter: martin krivosik
>Assignee: Emmanuel Lecharny
> Fix For: 2.0.0-M4
>
>   Original Estimate: 0.33h
>  Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the 
> config, so the ToS byte is not set in the packet sent from client.
> client code:
>   NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
>   DatagramSessionConfig dcfg = 
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
>   dcfg.setTrafficClass(tosByte);
>   InetSocketAddress bindAddrPort  = new InetSocketAddress(originatingIP, 
> port);
>   acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not 
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in 
> the packet.
> (the same problem may be in the socket, i have to check it)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-23) New transport type: non-NIO sockets

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648935#action_12648935
 ] 

Emmanuel Lecharny commented on DIRMINA-23:
--

Let's keep it open, with no fix version.

> New transport type: non-NIO sockets
> ---
>
> Key: DIRMINA-23
> URL: https://issues.apache.org/jira/browse/DIRMINA-23
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 0.7.0, 0.8.0
>Reporter: Trustin Lee
>
> Current NIO implementation doesn't outperform non-NIO sockets, and doesn't 
> support multicasting.  We could complement this gap by adding transport type 
> support for non-NIO sockets.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-637) SSLEngine output buffer seems to be too small

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-637:
--

Fix Version/s: 1.1.8

We should check if it also affects 2.0.0

> SSLEngine output buffer seems to be too small
> -
>
> Key: DIRMINA-637
> URL: https://issues.apache.org/jira/browse/DIRMINA-637
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 1.1.1, 1.1.7
>Reporter: Dan Mihai Dumitriu
>Assignee: Emmanuel Lecharny
> Fix For: 1.1.8
>
>
> the code below is in SSLHandler.java.  it makes the assumption that the size 
> of the output will never be larger than 2x the size of the input.  that 
> assumption appears to not hold up.  It looks like this code has been fixed in 
> trunk, but not in 1.1.7.  we only see an error for VERY specific content, 
> i.e. almost never.
> public void encrypt(ByteBuffer src) throws SSLException {
> if (!initialHandshakeComplete) {
> throw new IllegalStateException();
> }
> // The data buffer is (must be) empty, we can reuse the entire
> // buffer.
> outNetBuffer.clear();
> // Loop until there is no more data in src
> while (src.hasRemaining()) {
> if (src.remaining() > ((outNetBuffer.capacity() - outNetBuffer
> .position()) / 2)) {
> // We have to expand outNetBuffer
> // Note: there is no way to know the exact size required, but 
> enrypted data
> // shouln't need to be larger than twice the source data size?
> outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer, 
> src
> .capacity() * 2);
> if (SessionLog.isDebugEnabled(session)) {
> SessionLog.debug(session, " expanded outNetBuffer:"
> + outNetBuffer);
> }
> }
> SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
> if (SessionLog.isDebugEnabled(session)) {
> SessionLog.debug(session, " Wrap res:" + result);
> }
> if (result.getStatus() == SSLEngineResult.Status.OK) {
> if (result.getHandshakeStatus() == 
> SSLEngineResult.HandshakeStatus.NEED_TASK) {
> doTasks();
> }
> } else {
> throw new SSLException("SSLEngine error during encrypt: "
> + result.getStatus() + " src: " + src
> + "outNetBuffer: " + outNetBuffer);
> }
> }
> outNetBuffer.flip();
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DIRMINA-637) SSLEngine output buffer seems to be too small

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny reassigned DIRMINA-637:
-

Assignee: Emmanuel Lecharny

> SSLEngine output buffer seems to be too small
> -
>
> Key: DIRMINA-637
> URL: https://issues.apache.org/jira/browse/DIRMINA-637
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 1.1.1, 1.1.7
>Reporter: Dan Mihai Dumitriu
>Assignee: Emmanuel Lecharny
> Fix For: 1.1.8
>
>
> the code below is in SSLHandler.java.  it makes the assumption that the size 
> of the output will never be larger than 2x the size of the input.  that 
> assumption appears to not hold up.  It looks like this code has been fixed in 
> trunk, but not in 1.1.7.  we only see an error for VERY specific content, 
> i.e. almost never.
> public void encrypt(ByteBuffer src) throws SSLException {
> if (!initialHandshakeComplete) {
> throw new IllegalStateException();
> }
> // The data buffer is (must be) empty, we can reuse the entire
> // buffer.
> outNetBuffer.clear();
> // Loop until there is no more data in src
> while (src.hasRemaining()) {
> if (src.remaining() > ((outNetBuffer.capacity() - outNetBuffer
> .position()) / 2)) {
> // We have to expand outNetBuffer
> // Note: there is no way to know the exact size required, but 
> enrypted data
> // shouln't need to be larger than twice the source data size?
> outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer, 
> src
> .capacity() * 2);
> if (SessionLog.isDebugEnabled(session)) {
> SessionLog.debug(session, " expanded outNetBuffer:"
> + outNetBuffer);
> }
> }
> SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
> if (SessionLog.isDebugEnabled(session)) {
> SessionLog.debug(session, " Wrap res:" + result);
> }
> if (result.getStatus() == SSLEngineResult.Status.OK) {
> if (result.getHandshakeStatus() == 
> SSLEngineResult.HandshakeStatus.NEED_TASK) {
> doTasks();
> }
> } else {
> throw new SSLException("SSLEngine error during encrypt: "
> + result.getStatus() + " src: " + src
> + "outNetBuffer: " + outNetBuffer);
> }
> }
> outNetBuffer.flip();
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-637) SSLEngine output buffer seems to be too small

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649005#action_12649005
 ] 

Emmanuel Lecharny commented on DIRMINA-637:
---

Ok, so we are safe in 2.0 :) That's a good news !

> SSLEngine output buffer seems to be too small
> -
>
> Key: DIRMINA-637
> URL: https://issues.apache.org/jira/browse/DIRMINA-637
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 1.1.1, 1.1.7
>Reporter: Dan Mihai Dumitriu
>Assignee: Emmanuel Lecharny
> Fix For: 1.1.8
>
>
> the code below is in SSLHandler.java.  it makes the assumption that the size 
> of the output will never be larger than 2x the size of the input.  that 
> assumption appears to not hold up.  It looks like this code has been fixed in 
> trunk, but not in 1.1.7.  we only see an error for VERY specific content, 
> i.e. almost never.
> public void encrypt(ByteBuffer src) throws SSLException {
> if (!initialHandshakeComplete) {
> throw new IllegalStateException();
> }
> // The data buffer is (must be) empty, we can reuse the entire
> // buffer.
> outNetBuffer.clear();
> // Loop until there is no more data in src
> while (src.hasRemaining()) {
> if (src.remaining() > ((outNetBuffer.capacity() - outNetBuffer
> .position()) / 2)) {
> // We have to expand outNetBuffer
> // Note: there is no way to know the exact size required, but 
> enrypted data
> // shouln't need to be larger than twice the source data size?
> outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer, 
> src
> .capacity() * 2);
> if (SessionLog.isDebugEnabled(session)) {
> SessionLog.debug(session, " expanded outNetBuffer:"
> + outNetBuffer);
> }
> }
> SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
> if (SessionLog.isDebugEnabled(session)) {
> SessionLog.debug(session, " Wrap res:" + result);
> }
> if (result.getStatus() == SSLEngineResult.Status.OK) {
> if (result.getHandshakeStatus() == 
> SSLEngineResult.HandshakeStatus.NEED_TASK) {
> doTasks();
> }
> } else {
> throw new SSLException("SSLEngine error during encrypt: "
> + result.getStatus() + " src: " + src
> + "outNetBuffer: " + outNetBuffer);
> }
> }
> outNetBuffer.flip();
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-637) SSLEngine output buffer seems to be too small

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649045#action_12649045
 ] 

Emmanuel Lecharny commented on DIRMINA-637:
---

Acn you do a svn diff, and attach the result in this JIRA ? It will be easier 
to inject in trunk.

Thanks !

> SSLEngine output buffer seems to be too small
> -
>
> Key: DIRMINA-637
> URL: https://issues.apache.org/jira/browse/DIRMINA-637
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 1.1.1, 1.1.7
>Reporter: Dan Mihai Dumitriu
>Assignee: Emmanuel Lecharny
> Fix For: 1.1.8
>
>
> the code below is in SSLHandler.java.  it makes the assumption that the size 
> of the output will never be larger than 2x the size of the input.  that 
> assumption appears to not hold up.  It looks like this code has been fixed in 
> trunk, but not in 1.1.7.  we only see an error for VERY specific content, 
> i.e. almost never.
> public void encrypt(ByteBuffer src) throws SSLException {
> if (!initialHandshakeComplete) {
> throw new IllegalStateException();
> }
> // The data buffer is (must be) empty, we can reuse the entire
> // buffer.
> outNetBuffer.clear();
> // Loop until there is no more data in src
> while (src.hasRemaining()) {
> if (src.remaining() > ((outNetBuffer.capacity() - outNetBuffer
> .position()) / 2)) {
> // We have to expand outNetBuffer
> // Note: there is no way to know the exact size required, but 
> enrypted data
> // shouln't need to be larger than twice the source data size?
> outNetBuffer = SSLByteBufferPool.expandBuffer(outNetBuffer, 
> src
> .capacity() * 2);
> if (SessionLog.isDebugEnabled(session)) {
> SessionLog.debug(session, " expanded outNetBuffer:"
> + outNetBuffer);
> }
> }
> SSLEngineResult result = sslEngine.wrap(src, outNetBuffer);
> if (SessionLog.isDebugEnabled(session)) {
> SessionLog.debug(session, " Wrap res:" + result);
> }
> if (result.getStatus() == SSLEngineResult.Status.OK) {
> if (result.getHandshakeStatus() == 
> SSLEngineResult.HandshakeStatus.NEED_TASK) {
> doTasks();
> }
> } else {
> throw new SSLException("SSLEngine error during encrypt: "
> + result.getStatus() + " src: " + src
> + "outNetBuffer: " + outNetBuffer);
> }
> }
> outNetBuffer.flip();
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-639) WriteFuture are never updated after a session.write()

[Emmanuel Lecharny (JIRA)]

WriteFuture are never updated after a session.write()
-

 Key: DIRMINA-639
 URL: https://issues.apache.org/jira/browse/DIRMINA-639
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M3
Reporter: Emmanuel Lecharny
Priority: Blocker
 Fix For: 2.0.0-M4


While expecting the writeFuture to be updated when the write has been done, 
it's never done. This is a major problem as you can't rely on this to bail a 
connection based on a slow client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-639) WriteFuture are updated long after a session.write() is done

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-639:
--

Description: 
While expecting the writeFuture to be updated when the write has been done, 
it's done only when we get out of the chain. This is a major problem as you 
can't rely on this to bail a connection based on a slow client. Typically, we 
may stack thousands of message into the writeQueuebuffer, as the flush is only 
done when we have gone though the whole chain, and back.

The only way to get the data be blushed immediately is to add an executorFilter 
on the WRITE eventType, in order to create a new thread to handle this flush, 
otherwise we have to wait for the current processor to be done with the chain 
processing.

  was:While expecting the writeFuture to be updated when the write has been 
done, it's never done. This is a major problem as you can't rely on this to 
bail a connection based on a slow client.

Summary: WriteFuture are updated long after a session.write() is done  
(was: WriteFuture are never updated after a session.write())

> WriteFuture are updated long after a session.write() is done
> 
>
> Key: DIRMINA-639
> URL: https://issues.apache.org/jira/browse/DIRMINA-639
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4
>
>
> While expecting the writeFuture to be updated when the write has been done, 
> it's done only when we get out of the chain. This is a major problem as you 
> can't rely on this to bail a connection based on a slow client. Typically, we 
> may stack thousands of message into the writeQueuebuffer, as the flush is 
> only done when we have gone though the whole chain, and back.
> The only way to get the data be blushed immediately is to add an 
> executorFilter on the WRITE eventType, in order to create a new thread to 
> handle this flush, otherwise we have to wait for the current processor to be 
> done with the chain processing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-577) Implement a Selector pool

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-577:
--

Fix Version/s: (was: 2.0.0-M4)
   3.0.0-M1

Postponed

> Implement a Selector pool 
> --
>
> Key: DIRMINA-577
> URL: https://issues.apache.org/jira/browse/DIRMINA-577
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 2.0.0-M1
>Reporter: Emmanuel Lecharny
> Fix For: 3.0.0-M1
>
>
> There is an interesting post from Jean-François Arcand : 
> http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html
> where he explains that we may use more than one single Selector to manage the 
> incoming and outgoing events. 
> Separating OP_READ, OP_WRITE and OP_ACCEPT selectors may lead to some 
> improvement, depending on which kind of server you want to build.
> It seems interesting to implement these ideas in MINA.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-574) ClassCastException when a message is written on a closed session.

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-574:
--

Fix Version/s: (was: 2.0.0-M4)
   3.0.0-M1

Will be fixed when the MessageSent message will be removed, something that 
can't be done for 2.0

> ClassCastException when a message is written on a closed session.
> -
>
> Key: DIRMINA-574
> URL: https://issues.apache.org/jira/browse/DIRMINA-574
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.10, 1.1.7, 2.0.0-M1
>Reporter: Trustin Lee
>Assignee: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 3.0.0-M1
>
>
> 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.
> A possible workaround is just to ignore the exception, but we need to provide 
> a correct fix for this issue.
> The following is the stack trace that explains this scenario:
> 25151 [SocketAcceptorIoProcessor-0.4] WARN  ServerPortSessionHandler  -
> > [/127.0.0.1:57120 ]
> > java.lang.ClassCastException:
> > org.apache.mina.filter.codec.ProtocolCodecFilter$MessageByteBuffer
> > incompatible with com.daishin.eai.adapter.socket.message.Por
> > tMessage
> > at
> > com.daishin.eai.adapter.socket.handler.ServerPortSessionHandler.messageSent(ServerPortSessionHandler.java:80)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageSent(AbstractIoFilterChain.java:579)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:53)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageSent(AbstractIoFilterChain.java:653)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageSent(AbstractIoFilterChain.java:504)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.fireMessageSent(AbstractIoFilterChain.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.releaseWriteBuffers(SocketIoProcessor.java:359)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProcessor.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoProcessor.java:45)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:488)
> > at
> > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> > at java.lang.Thread.run(Thread.java:810)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-477) Update page about differences between 1.x and 2.x

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-477:
--

Fix Version/s: (was: 2.0.0-M4)
   2.0.0-RC1

Documentation will be fixed for 2.0-RC1

> Update page about differences between 1.x and 2.x
> -
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
>  Issue Type: Task
>  Components: Web Site / Documentation
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-RC1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing 
> to 1.x.  We need to carefully put all changes together there so people can 
> migrate more easily.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-605) Add documentation for using and building serial port connection

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-605:
--

Fix Version/s: (was: 2.0.0-M4)
   2.0.0-RC1

Documentation will be fixed for 2.0-RC1

> Add documentation for using and building serial port connection
> ---
>
> Key: DIRMINA-605
> URL: https://issues.apache.org/jira/browse/DIRMINA-605
> Project: MINA
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 2.0.0-M1
> Environment: Windows XP
>Reporter: john wang
>Assignee: Julien Vermillard
> Fix For: 2.0.0-RC1
>
>
> Add the documentation for building serial-transport and use it in your MINA 
> application

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-593) Javadoc & documentation for org/apache/mina/filter/reqres

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-593:
--

Fix Version/s: (was: 2.0.0-M4)
   2.0.0-RC1

Documentation will be fixed for 2.0-RC1

> Javadoc & documentation for org/apache/mina/filter/reqres
> -
>
> Key: DIRMINA-593
> URL: https://issues.apache.org/jira/browse/DIRMINA-593
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter, Web Site / Documentation
>Affects Versions: 2.0.0-M1
>Reporter: Julien Vermillard
> Fix For: 2.0.0-RC1
>
>
> no javadoc nor doc on the request/response filter, it need some examples too

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-612) Add documentation on SingleSessionIohandler

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-612:
--

Fix Version/s: (was: 2.0.0-M4)
   2.0.0-RC1

Documentation will be fixed for 2.0-RC1

> Add documentation on SingleSessionIohandler
> ---
>
> Key: DIRMINA-612
> URL: https://issues.apache.org/jira/browse/DIRMINA-612
> Project: MINA
>  Issue Type: Task
>  Components: Web Site / Documentation
>Affects Versions: 2.0.0-M2
>Reporter: Geert Schuring
>Priority: Minor
> Fix For: 2.0.0-RC1
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> A normal multi-session IoHandler can be added to the acceptor using the 
> "addHandler" method. However, when writing a single-session IoHandler I can't 
> find any information about how to register it with the acceptor. The 
> "addHandler" method doesn't accept single-session IoHandlers.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-489) Composite IoBuffer

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-489:
--

Fix Version/s: (was: 2.0.0-M4)
   3.0.0-M1

This is a major improvement, but it will be done in 3.0

> 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] Updated: (DIRMINA-594) Javadoc & documentation for APR transport

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-594:
--

Fix Version/s: (was: 2.0.0-M4)
   2.0.0-RC1

Documentation will be fixed for 2.0-RC1

> Javadoc & documentation for APR transport
> -
>
> Key: DIRMINA-594
> URL: https://issues.apache.org/jira/browse/DIRMINA-594
> Project: MINA
>  Issue Type: Improvement
>  Components: Transport, Web Site / Documentation
>Affects Versions: 2.0.0-M1
>Reporter: Julien Vermillard
> Fix For: 2.0.0-RC1
>
>
> The APR transport module is javadoc less and probably need a like 
> documentation in the wiki (instalation of APR & jni bindings)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-639) WriteFuture are updated long after a session.write() is done

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-639:
--

Fix Version/s: (was: 2.0.0-M4)
   3.0.0-M1

Postponed to 3.0. It's not possible to fix this without rethinking the chain 
completely

> WriteFuture are updated long after a session.write() is done
> 
>
> Key: DIRMINA-639
> URL: https://issues.apache.org/jira/browse/DIRMINA-639
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 3.0.0-M1
>
>
> While expecting the writeFuture to be updated when the write has been done, 
> it's done only when we get out of the chain. This is a major problem as you 
> can't rely on this to bail a connection based on a slow client. Typically, we 
> may stack thousands of message into the writeQueuebuffer, as the flush is 
> only done when we have gone though the whole chain, and back.
> The only way to get the data be blushed immediately is to add an 
> executorFilter on the WRITE eventType, in order to create a new thread to 
> handle this flush, otherwise we have to wait for the current processor to be 
> done with the chain processing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-629) The IoServiceStatistics methods are called for every new session creation

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-629:
--

Fix Version/s: (was: 2.0.0-M4)
   3.0.0-M1

Not urgent either... 3.0

> The IoServiceStatistics methods are called for every new session creation
> -
>
> Key: DIRMINA-629
> URL: https://issues.apache.org/jira/browse/DIRMINA-629
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Priority: Minor
> Fix For: 3.0.0-M1
>
>
> When a session is established, some methods of the IoServiceStatistics class 
> are called :
> protected final void finishSessionInitialization(IoSession session, 
> IoFuture future, IoSessionInitializer sessionInitializer) {
> if (stats.getLastReadTime() == 0) {
> ((IoServiceStatistics)stats).setLastReadTime(getActivationTime());
> There are two problems with this approach :
> - first, many of the members of this classes are not thread safe, leading to 
> some random value potentially be put into the stats instance for the service
> - second, if we protect those members using some synchronization (or volatile 
> data), it might slow down the connection initialization.
> The IoServiceStatistics class should be thread safe, and these statistics 
> should not be updated if the user don't want them, ie, it should be optionnal 
> (the Configuration object should take care of this)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-32) Revise JavaDoc, PPT, and Tutorial

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-32:
-

Affects Version/s: 2.0.0-M3
Fix Version/s: 2.0.0-RC1

I will reuse this issue to avoid recreating a new one. 

> Revise JavaDoc, PPT, and Tutorial
> -
>
> Key: DIRMINA-32
> URL: https://issues.apache.org/jira/browse/DIRMINA-32
> Project: MINA
>  Issue Type: Task
>  Components: Web Site / Documentation
>Affects Versions: 2.0.0-M3
>Reporter: Trustin Lee
> Fix For: 2.0.0-RC1
>
>
> 0.9 will integrate I/O layer and Protocol layer.  We need up-to-date 
> documentation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-597) AbstractIoAcceptor.toString() blocks when invoked from IoServiceListener.serviceActivated()

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-597:
--

Fix Version/s: 2.0.0-M4

has to be fixed for 2.0.0-M4

> AbstractIoAcceptor.toString() blocks when invoked from 
> IoServiceListener.serviceActivated()
> ---
>
> Key: DIRMINA-597
> URL: https://issues.apache.org/jira/browse/DIRMINA-597
> Project: MINA
>  Issue Type: Bug
>  Components: Core, Transport
>Affects Versions: 2.0.0-M1
> Environment: MINA-2.0.0-RC1, tested on both JDK 1.5 and JDK 1.6
>Reporter: Barend Garvelink
> Fix For: 2.0.0-M4
>
> Attachments: ServiceActivatedBlocksDatagramAcceptorToString.java
>
>
> When NioDatagramAcceptor.toString() is invoked from the serviceActivated() 
> method of IoServiceListener, the system locks up. The [NioDatagramAcceptor-1] 
> thread ends up waiting for a lock held by [main] which is waiting for 
> [NioDatagramAcceptor-1] to finish activating the service.
> I will attach a JUnit test case that demonstrates the problem. I'm not yet 
> comfortable enough around MINA's innards to submit a patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-598) ByteBuffer passed to ProtocolEncoderOutput.write(ByteBuffer) does not get released back to the pool

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-598:
--

Fix Version/s: 1.1.8
   2.0.0-M4

We have to check the proposal, see if it applies to 2.0 too.

> ByteBuffer passed to ProtocolEncoderOutput.write(ByteBuffer) does not get 
> released back to the pool
> ---
>
> Key: DIRMINA-598
> URL: https://issues.apache.org/jira/browse/DIRMINA-598
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 1.1.7
>Reporter: Greg Dhuse
> Fix For: 2.0.0-M4, 1.1.8
>
>
> When pooled ByteBuffers are used in conjunction with a ProtocolCodecFilter, 
> buffers passed to ProtocolEncoderOutput.write() do not get released back to 
> the pool in all circumstances, causing unnecessary memory allocation.  
> The following patch appears to resolve this issue in a simple filter chain, 
> but it should be verified that there is no case where this change would cause 
> a buffer to be released too early.
> Best regards,
>  Greg
> Index: 
> core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java
> ===
> --- core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java  
> (revision 657929)
> +++ core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java  
> (working copy)
> @@ -186,6 +186,10 @@
>  public void messageSent(NextFilter nextFilter, IoSession session,
>  Object message) throws Exception {
>  if (message instanceof HiddenByteBuffer) {
> + // Release buffer originally passed to 
> ProtocolEncoderOutput.write(ByteBuffer)
> + // See 
> http://mina.apache.org/report/1.1/apidocs/org/apache/mina/common/ByteBuffer.html
> + ((HiddenByteBuffer) message).release();
> + 
>  return;
>  }
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-617) JMX - IoServiceMBean doesn't expose IoService statistics

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-617:
--

Fix Version/s: 3.0.0-M1

Postponed to 3.0

> JMX - IoServiceMBean doesn't expose IoService statistics
> 
>
> Key: DIRMINA-617
> URL: https://issues.apache.org/jira/browse/DIRMINA-617
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M3
>Reporter: simon trudeau
> Fix For: 3.0.0-M1
>
>
> As of Mina 2.0.0-M3 it is not possible to browse Mina's statistics using JMX 
> and IoServiceMBean. Only the object memory address is exposed and not its 
> attributes.
> This should also be looked into for IoSession too.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-627) ByteBuffer.getObject() doesn't support Class objects for non-serializable classes

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-627:
--

Fix Version/s: 3.0.0-M1

I _think_ that's belong to 3.0. Anyway, we will have most certainly a better 
way to handle buffers in 3.0

> ByteBuffer.getObject() doesn't support Class objects for non-serializable 
> classes
> -
>
> Key: DIRMINA-627
> URL: https://issues.apache.org/jira/browse/DIRMINA-627
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.7
>Reporter: Owen Jacobson
> Fix For: 3.0.0-M1
>
> Attachments: fix.patch, tests.patch
>
>
> Instances of java.lang.Class are serializable, whether or not the class they 
> represent is serializable.  However, org.apache.mina.common.ByteBuffer's 
> optimizations prevent it from unserializing Class instances representing 
> classes that are not serializable.  For example, given
> public interface NotSerializable {}
> /*...*/
> ObjectOutputStream o = /*...*/;
> o.writeObject (NotSerializable.class);
> /*...*/
> ObjectInputStream i = /*..bytes written by o, above..*/;
> Object read = i.readObject();
> The 'read' object will be NotSerializable.class.
> Trying the same thing with buffer.putObject (NotSerializable.class); 
> buffer.flip(); buffer.getObject() throws a NullPointerException.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-596) Sessions generated by NioSocketConnector cannot be closed in time (within MINA2.0 M1,M2)

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649754#action_12649754
 ] 

Emmanuel Lecharny commented on DIRMINA-596:
---

Still waiting for a sample to work on. Otherwise, we will have to postpone the 
issue to 3.0...

> Sessions generated by NioSocketConnector cannot be closed in time (within 
> MINA2.0 M1,M2)
> 
>
> Key: DIRMINA-596
> URL: https://issues.apache.org/jira/browse/DIRMINA-596
> Project: MINA
>  Issue Type: Bug
>  Components: Core, Transport
>Affects Versions: 2.0.0-M1, 2.0.0-M2
> Environment: MINA:mina-core-2.0.0-M2-20080427.091119-1.jar
> JDK: java version "1.5.0_05"
> Plat: Windows XP
>Reporter: Silver
>
> I use MINA 2.0.0 M1 and M2 to build my application.
> When I use one NioSocketConnector to generate 10 sessions and then close them 
> in the messageReceived event of each session, only 5 or 6 sessions(that is to 
> say, not of all sessions)  can be closed correctly, others cannot, but I can 
> receive the sessionClosed event. The number of the closed sessions varies 
> from 2-6 during my experiments.
> Another intersting event will occur:
>Since the rest sessions cannot be closed, I tried to generate a new 
> session by the same NioSocketConnector, then all of the 10 "old" sessions 
> were closed as one might expect, except the last new session.
> the main method:
> public static void main(String[] args)
> {
> NioSocketConnector acceptor = new NioSocketConnector();
> acceptor.setDefaultRemoteAddress(new InetSocketAddress("127.0.0.1", 
> 2361));
> acceptor.getFilterChain().addLast( "executor", new 
> ExecutorFilter(100) );
> acceptor.setHandler( new TimeServerHandler() );
> for(int i=0; i<10; i++)
> acceptor.connect();
> }
> the messageReceived method in TimeServerHandler class:
> public void messageReceived(IoSession session, Object message)
> throws Exception
> {
> System.out.println(((IoBuffer) 
> message).getString(Charset.forName("UTF-8")
> .newDecoder()));
> session.close();
> }
> the log of the test server:
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3211>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3212>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3213>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3214>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3215>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3216>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3217>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3218>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3219>
> 2008-5-27 17:09:32 Connected 127.0.0.1 / 3220>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3211>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3213>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3214>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3212>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3216>
> 2008-5-27 17:09:32 Disconnected ---127.0.0.1 / 3215>
> 2008-5-27 17:09:37 Connected 127.0.0.1 / 3221>
> 2008-5-27 17:09:37 Disconnected ---127.0.0.1 / 3217>
> 2008-5-27 17:09:37 Disconnected ---127.0.0.1 / 3218>
> 2008-5-27 17:09:37 Disconnected ---127.0.0.1 / 3219>
> 2008-5-27 17:09:37 Disconnected ---127.0.0.1 / 3220>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-631) AbstractIoFilter: increment writen- and receivedMessages statistics on application end of filter chain

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-631:
--

Fix Version/s: 3.0.0-M1

I suggest a potspone to 3.0, as we will redesign the chain.

> AbstractIoFilter: increment writen- and receivedMessages statistics on 
> application end of filter chain
> --
>
> Key: DIRMINA-631
> URL: https://issues.apache.org/jira/browse/DIRMINA-631
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter
>Affects Versions: 2.0.0-M3
> Environment: MINA 2.0.0-M3
>Reporter: Barend Garvelink
> Fix For: 3.0.0-M1
>
>
> This is the JIRA for the mina-dev mailing list discussion here:
> http://markmail.org/message/e7qw6k5tp52knpav
> To summarise:
> {quote}
> I would like to suggest that the invocations of increaseWrittenMessages() and 
> increaseReceivedMessages() are moved from their current spot in 
> AbstractIoFilter into the appropriate methods of TailFilter. The 
> increaseWrittenBytes() and increaseReceivedBytes() invocations can stay where 
> they are. 
> [...]
> I have an IoFilter chain in which a SegmentationFilter takes in a single 
> application message to filterWrite() and splits it into multiple packets. On 
> the way back, it filters the messageSent() events for every packet sent, 
> collating them into a single call to nextFilter#messageSent() for each 
> original application-level message. Further down the chain, I have an ARQ 
> filter which can re-send packets that weren't acknowledged in time. Both 
> filters can cause a different number of messages to come out at the IoService 
> end than went into them at the Application end (and vice versa). 
> [...]
> In this scenario the writtenBytes/receivedBytes counters are fine as they 
> are, but the writtenMessages/readMessages counters are basically useless in 
> their current form. Their value depends on the size of the messages my 
> application sends and on the quality of the network connection (i.e. if any 
> retries were necessary) and even on whether the outgoing ACK packets can 
> piggyback on a data packet or have to be sent out on their own. Compared to a 
> message counter I keep at the application level, the messages sent/received 
> values tracked in IoServiceStatistics diverge immediately. 
> {quote}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-438) Multicast support for MINA API

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-438:
--

Fix Version/s: 3.0.0-M1

Postponed to 3.0

> Multicast support for MINA API 
> ---
>
> Key: DIRMINA-438
> URL: https://issues.apache.org/jira/browse/DIRMINA-438
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Julien Vermillard
>Priority: Minor
> Fix For: 3.0.0-M1
>
>
> For supporting multicast over UDP we need to change the MINA API for
> Set the multicast Time to Live (TTL) for a multicast transmission.
> Joining a multicast group for a given session.
> Leaving a multicast group.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-507) IoBuffer: Support prepending data

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-507:
--

Fix Version/s: 3.0.0-M1

Will be rethink totally in 3.0.

> IoBuffer: Support prepending data
> -
>
> Key: DIRMINA-507
> URL: https://issues.apache.org/jira/browse/DIRMINA-507
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: David M. Lloyd
>Priority: Minor
> Fix For: 3.0.0-M1
>
>
> I'd like to see IoBuffer enhanced to support prepending data.  It could work 
> as follows:
> * A means to specificy or reserve space should be provided.  An 
> IoBuffer.reserve() method could do the trick, and maybe a 3-parameter version 
> of IoBuffer.  IoBuffer.reserve() would keep the position at zero, but 
> decrease the capacity and limit by the given number of bytes, and move the 
> buffer start up by the given number of bytes.
> * A means to reclaim the space must be provided.  An IoBuffer.reclaim() would 
> work by moving the buffer start back down by the given amount, maybe 
> returning a slice to the recovered area.  Or another alternative would be to 
> have a series of prepend* methods which would prepend bytes/ints/etc. similar 
> to put*(), but rather than adding to the end of the buffer, they would add to 
> the beginning, moving the buffer start back down to the start of the 
> just-written data.  Though I'm not sure how helpful it would be to add 
> another dozen methods to a class that already has probably over a hundred 
> methods.
> * Care should be taken that the mechanism to prepend data does not allow a 
> user to "escape" a buffer slice.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-418) sendUrgentData feature is needed

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-418:
--

Fix Version/s: 3.0.0-M1

Postponed to 3.0

> sendUrgentData feature is needed
> 
>
> Key: DIRMINA-418
> URL: https://issues.apache.org/jira/browse/DIRMINA-418
> Project: MINA
>  Issue Type: New Feature
>Reporter: mina tds
> Fix For: 3.0.0-M1
>
>
> Java Sockets support sendUrgentData method on sockets.
> Similar feature is needed in MINA.
> For example, in proxy application that need to forward out of band packets 
> like urgent data packet to its remote destination.
> It can receive the urgent data packet  as inlne through setting 
> tSessionConfig.setOobInline(true);
> But  It cannot create/send any urgent packet after It receives such packet.
> Trustin suggested to open an issue in JIRA

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-56) Create a Benchmark Suite That Generates HTML Reports.

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-56:
-

Fix Version/s: 3.0.0-M1

Postponed to 3.0

> Create a Benchmark Suite That Generates HTML Reports.
> -
>
> Key: DIRMINA-56
> URL: https://issues.apache.org/jira/browse/DIRMINA-56
> Project: MINA
>  Issue Type: Task
>Reporter: Trustin Lee
>Priority: Minor
> Fix For: 3.0.0-M1
>
>
> We need benchmark suite before releasing 0.8 (stable stream)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-57) 100% Test Coverage

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-57:
-

Fix Version/s: 3.0.0-M1

Far too late for 2.0 !!! It should have been started from day one, as for the 
Javadoc ...

Postponed to 3.0 (And 100% test coverage is just a wet dream ... ;)

> 100% Test Coverage
> --
>
> Key: DIRMINA-57
> URL: https://issues.apache.org/jira/browse/DIRMINA-57
> Project: MINA
>  Issue Type: Task
>Reporter: Trustin Lee
> Fix For: 3.0.0-M1
>
>
> We need to add more test codes to be confident MINA is stable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-624) Message handlers selection is not efficient in the DemuxingIoHandler

[Emmanuel Lecharny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lecharny updated DIRMINA-624:
--

Fix Version/s: 3.0.0-M1

Postponed to 3.0

> Message handlers selection is not efficient in the DemuxingIoHandler
> 
>
> Key: DIRMINA-624
> URL: https://issues.apache.org/jira/browse/DIRMINA-624
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
> Fix For: 3.0.0-M1
>
>
> The way we are selecting a message handler in the DemuxingIoHandler is far 
> from being optimal. The problem is that we are registering a handler without 
> checking its inheritence scheme, but we do so when receiving a message.
> It would be much more efficient to do the inheritence discovering while 
> registering a handler, avoiding such a discovery when receiving a message.
> There is only one tricky issue we have to take care of : as we can associate 
> a handler with one of it's inherited class or implemented interface, if there 
> is another handler associated with those classes/interfaces added later, this 
> should override the default association. So we must flag the automatically 
> added handlers in order to be able to replace them if needed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.