Re: Got some error when compiling SSHd
Guillaume Nodet wrote: It works for me too. Please post some details. On Thu, May 7, 2009 at 12:20, Bernd Fondermann wrote: Emmanuel Lecharny wrote: Hi guys, just before leaving for a long week-end, I tried to build all the MINA code. I get some error when compiling sshd. Can someone check ? Thanks ! mvn install works fine for me. Works now on linux... Strange :/ -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Header stuff
Ashish wrote: Funny enough, you don't need network to do "svn info pom.xml" ;-) so +1 for removing Maarten +1 I have removed all the @version from MINA, SSHD and AsyncWeb. Still have to remove those from FtpServer. When it will be done, I will commit if nobody complains. Note : We also have to use the same @author tags everywhere. SSHd uses : @author mailto:dev@mina.apache.org";>Apache MINA SSHD Project FtpServer uses : @author The Apache MINA Project (dev@mina.apache.org) MINA uses : @author The Apache MINA Project (dev@mina.apache.org) AsyncWeb still have personal author's tags like : @author mailto:adr...@ephox.com";>Adrian Sutton In this case, we have to do three things : 1) check that those authors are Apache committers 2) check that the code was either committed as a part of the project or as a part of an ASL 2.0 compliant project 3) if they are external (ie, ASL 2.0 compliant license project), then we have to check that the notice.txt contains the correct attribution In any case, we should use the same tag formet (SSHd format ios probably more convenient, if we consider Javadoc). -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Commented: (DIRMINA-687) 2.0.0-M5 REGRESSION: sessionClosed called before doDecode completes
[ https://issues.apache.org/jira/browse/DIRMINA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708315#action_12708315 ] Emmanuel Lecharny commented on DIRMINA-687: --- I have run the tests against 2.0.0-M5, and got some error, accordingly to the report. So I went a bit further last week-end, adding some logs, up to a point I obtained those traces : [05:56:01]-main INFO [testcase.MinaRegressionTest] - START ... [05:56:02]-NioProcessor-2 INFO [testcase.MyIoHandler] - Creation of session 4 [05:56:02]-NioProcessor-2 INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event SESSION_OPENED to session 4 Queue : [SESSION_OPENED, ] [05:56:02]-MinaThread INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Processing task SESSION_OPENED for session 4 [05:56:02]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a SESSION_OPENED event for session 4 [05:56:02]-MinaThread INFO [testcase.MyIoHandler] - Session 4 is opened [05:56:02]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event SESSION_OPENED has been fired for session 4 [05:56:02]-NioProcessor-2 INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event MESSAGE_RECEIVED to session 4 Queue : [MESSAGE_RECEIVED, ] [05:56:02]-MinaThread INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Processing task MESSAGE_RECEIVED for session 4 [05:56:02]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a MESSAGE_RECEIVED event for session 4 [05:56:02]-MinaThread INFO [org.apache.mina.filter.codec.ProtocolCodecFilter] - Processing a MESSAGE_RECEIVED for session 4 [05:56:02]-NioProcessor-2 INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event MESSAGE_RECEIVED to session 4 Queue : [MESSAGE_RECEIVED, ] [05:56:02]-MinaThread INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Processing task MESSAGE_RECEIVED for session 4 [05:56:02]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a MESSAGE_RECEIVED event for session 4 [05:56:02]-MinaThread INFO [org.apache.mina.filter.codec.ProtocolCodecFilter] - Processing a MESSAGE_RECEIVED for session 4 [05:56:02]-NioProcessor-2 INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event SESSION_CLOSED to session 4 Queue : [SESSION_CLOSED, ] [05:56:02]-MinaThread INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Processing task SESSION_CLOSED for session 4 [05:56:02]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a SESSION_CLOSED event for session 4 [05:56:02]-MinaThread INFO [testcase.MyIoHandler] - 4> Session closed [05:56:02]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event SESSION_CLOSED has been fired for session 4 [05:56:03]-MinaThread ERROR [testcase.MyRequestDecoder] - 4> !session closed before decoding completes! [05:56:03]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event MESSAGE_RECEIVED has been fired for session 4 [05:56:03]-MinaThread ERROR [testcase.MyRequestDecoder] - 4> !decoding for closed session! [05:56:04]-MinaThread ERROR [testcase.MyRequestDecoder] - 4> !session closed before decoding completes! [05:56:04]-MinaThread INFO [testcase.MyRequestDecoder] - 4> done decoding [05:56:04]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event MESSAGE_RECEIVED has been fired for session 4 ... [05:56:04]-main INFO [testcase.MinaRegressionTest] - Received: 0 [05:56:04]-main INFO [testcase.MinaRegressionTest] - Sent: 10 [05:56:04]-main INFO [testcase.MinaRegressionTest] - FINISH (I'm focusing on session 4, from the server side, as it's one of the failing session. It's random...) What puzzle me is that the MESSAGE_RECEIVED event is added twice (but that should not be a problem). More important, the SESSION_CLOSED event is processed *before* the MESSAGE_RECEIVED is completely processed (even if the first message is being processed by the codec). Still debugging ... > 2.0.0-M5 REGRESSION: sessionClosed called before doDecode completes > --- > > Key: DIRMINA-687 > URL: https://issues.apache.org/jira/browse/DIRMINA-687 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-M5 >Reporter: Serge Baranov >Assignee: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-RC1 > > Attachments: regression-test.zip > > > The problem is described in detail at > http://markmail.org/message/3iqmkdcukhygxxva . > I did more tests by setting the CLOSED custom attribute inside sessionClosed > and by checking for this attribute in the middle of doDecode. > Under some networ
[jira] Commented: (DIRMINA-687) 2.0.0-M5 REGRESSION: sessionClosed called before doDecode completes
[ https://issues.apache.org/jira/browse/DIRMINA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708321#action_12708321 ] Emmanuel Lecharny commented on DIRMINA-687: --- Ok, I now understand what happens. The doDecode method in the MyRequestDecoder class create a new thread, and launch it. This thread does a sleep(500), nothing more. This has the side effect to let the main thread processing another event. If this new thread is not created, then the program works well. Here are the logs I got : [06:38:34]-main INFO [testcase.MinaRegressionTest] - START ... [06:38:34]-NioProcessor-2 INFO [testcase.MyIoHandler] - Creation of session 5 [06:38:34]-NioProcessor-2 INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event SESSION_OPENED to session 5 Queue : [SESSION_OPENED, ] [06:38:34]-MinaThread INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Processing task SESSION_OPENED for session 5 [06:38:34]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a SESSION_OPENED event for session 5 [06:38:34]-MinaThread INFO [testcase.MyIoHandler] - Session 5 is opened [06:38:34]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event SESSION_OPENED has been fired for session 5 ... [06:38:34]-NioProcessor-2 INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event MESSAGE_RECEIVED to session 5 Queue : [MESSAGE_RECEIVED, ] ... [06:38:34]-MinaThread INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Processing task MESSAGE_RECEIVED for session 5 [06:38:34]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a MESSAGE_RECEIVED event for session 5 [06:38:34]-MinaThread INFO [org.apache.mina.filter.codec.ProtocolCodecFilter] - Processing a MESSAGE_RECEIVED for session 5 ... [06:38:34]-NioProcessor-2 INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event MESSAGE_RECEIVED to session 5 Queue : [MESSAGE_RECEIVED, ] ... [06:38:34]-MinaThread DEBUG [testcase.MyRequestDecoder] - Sleep for 1000 ms for session 5 [06:38:34]-Thread-0 DEBUG [testcase.MyRequestDecoder] - Sleep for 500 ms for session 5 ... [06:38:34]-MinaThread INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Processing task MESSAGE_RECEIVED for session 5 [06:38:34]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a MESSAGE_RECEIVED event for session 5 [06:38:34]-MinaThread INFO [org.apache.mina.filter.codec.ProtocolCodecFilter] - Processing a MESSAGE_RECEIVED for session 5 ... [06:38:35]-Thread-0 DEBUG [testcase.MyRequestDecoder] - Wake up now from a 500 ms sleep for session 5 ... [06:38:35]-NioProcessor-2 INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event SESSION_CLOSED to session 5 Queue : [SESSION_CLOSED, ] [06:38:35]-MinaThread INFO [org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Processing task SESSION_CLOSED for session 5 [06:38:35]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a SESSION_CLOSED event for session 5 [06:38:35]-MinaThread INFO [testcase.MyIoHandler] - 5> Session closed [06:38:35]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event SESSION_CLOSED has been fired for session 5 ... [06:38:35]-MinaThread DEBUG [testcase.MyRequestDecoder] - Wake up now from a 1000 ms sleep for session 5 [06:38:35]-MinaThread ERROR [testcase.MyRequestDecoder] - 5> !session closed before decoding completes! [06:38:35]-MinaThread ERROR [testcase.MyRequestDecoder] - 5> !decoding for closed session! [06:38:35]-MinaThread DEBUG [testcase.MyRequestDecoder] - Sleep for 1000 ms for session 5 [06:38:35]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event MESSAGE_RECEIVED has been fired for session 5 ... [06:38:37]-main INFO [testcase.MinaRegressionTest] - Received: 0 [06:38:37]-main INFO [testcase.MinaRegressionTest] - Sent: 10 [06:38:37]-main INFO [testcase.MinaRegressionTest] - FINISH Now, the question is why does the MinaThread can process another event while the thread is supposed to be 'busy' ? > 2.0.0-M5 REGRESSION: sessionClosed called before doDecode completes > --- > > Key: DIRMINA-687 > URL: https://issues.apache.org/jira/browse/DIRMINA-687 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-M5 >Reporter: Serge Baranov >Assignee: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-RC1 > > Attachments: regression-test.zip > > > The problem is described in detail at > http://markmail.org/message/3iqmkdcukhygxxva . > I did more tests by setting the CLOSED custom attribute inside sessionClosed > and by checking fo
Re: Header stuff
Emmanuel Lecharny wrote: > Ashish wrote: >>> Funny enough, you don't need network to do "svn info pom.xml" ;-) >>> so +1 for removing >>> >>> Maarten >>> >> >> +1 >> > I have removed all the @version from MINA, SSHD and AsyncWeb. Still have > to remove those from FtpServer. > > When it will be done, I will commit if nobody complains. > > Note : We also have to use the same @author tags everywhere. > SSHd uses : > @author mailto:dev@mina.apache.org";>Apache MINA SSHD Project > > FtpServer uses : > @author The Apache MINA Project (dev@mina.apache.org) > > MINA uses : > @author The Apache MINA Project (dev@mina.apache.org) > > AsyncWeb still have personal author's tags like : > @author mailto:adr...@ephox.com";>Adrian Sutton > > In this case, we have to do three things : > 1) check that those authors are Apache committers > 2) check that the code was either committed as a part of the project or > as a part of an ASL 2.0 compliant project > 3) if they are external (ie, ASL 2.0 compliant license project), then we > have to check that the notice.txt contains the correct attribution For 2) and 3), where the origin of the code is not at the ASF covered by and *CLA, my understanding is that there should be either an IP grant on file or a corresponding JIRA with a checked ASF-license box. Nevertheless, the author tags could be removed altogether, because they are not a copyright (the original author retains copyright anyway, it is irrevokable AFAIK) or a licensing statement. > > In any case, we should use the same tag formet (SSHd format ios probably > more convenient, if we consider Javadoc). +1 Bernd
