Re: Hudson strat to p*ss me off ...
On Sat, Feb 20, 2010 at 10:59 PM, Emmanuel Lecharny wrote: > is there any reason why this stupid Hudson *always* fail when we commit some > new code, and one hour later come back with again 6 useless mails telling us > that "Hey, sorry, I was totally f*cked up last time I sent you 6 mails" ? I don't think that is entirely correct. We're running four builds for trunk (Ubuntu with Sun JDK 1.6, Ubuntu with Sun JDK 1.5, WIndows with Sun JDK 1.6, WIndows with Sun JDK 1.5). These get reported separately and might run at different times (due to how they are scheduled and the current job queue in Hudson), therefore the different builds might report their results at different times during about one hour (we poll SVN once per hour). One the the builds, on JDK 1.6 on Windows, consistently fails on one of the MDC tests. I reported that on this list about a week ago but I have not had the time to look into the details myself: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-windows/org.apache.mina$mina-core/14/testReport/org.apache.mina.filter.logging/MdcInjectionFilterTest/testOnlyRemoteAddress/ > If Hudson can't inform us when there are *real* errors, at some point, we > will simply ignore the alerts and lose all interest of having Hudson as a > safety belt ! I'm pretty sure that on most occasions Hudson is reporting the real errors and that we should look into why the builds fail (like the one on Windows). That said, I've found a some builds in the last weeks where there seems to be inconsistencies in the results. Some of these are also worth looking into. Here are those I've found: * Build creating corrupt JAR, Maven problem?: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-windows/9/ * Maven failed to install JAR, Maven problem?: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-ubuntu/226 * One-time test failure in XBean module: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-windows/7 * Hudson problem, possibly due to the MINA build getting killed by a restart of Hudson: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-ubuntu/7/ * One-time test failure in core: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-ubuntu/6/ So, I think our time is better spent at looking at why our tests fail, which will reduce the number of failed builds in Hudson (or any build tool) and thus the email frequency. /niklas
Make Hudson happy was : Re: Hudson strat to p*ss me off ...
Ok, guys, sorry for my overreaction... Sure we have to check what's going on with the builds. If we look at the build history, we see that we don't have that many failures. The problem is that those failures seems to be time-dependent. The JDK 1.6/Windows build are also in constant failure, and it has to be fixed. Looking at som of the failures, I'm a bit annoyed : the failing tests are totally cryptic, I'm not able to know what is being tested. I would say, considering MINA's history, I'm not suprised. At some point, it's difficult to say if : - the test is broken - the part which is tested is broken but nobody uses it and should be removed - or we have a serious issue In any case, for anyone who crawl into the mud^H^H^Hcode it's pretty obvious that MINA design is far from being extracted from any blue print. Yesterday I had a look at the IoSession hierarchy, and once agin, it's totally broken. We have generic used to express the fact that the IoProcessor is typed, but it's not consistent, and to avoid a compilation error, the top level processor variable does not use generic. Also we don't have a processor varibale in the AbstractIoSession, the place it should be. We don't have either the getProcessor() method in the interface, and I can't move it there as the API is frozen now. What I want to say is : get this bloddy 2.0 out, and let's bury it. It's dead code, it's a cancer we can't fix. Any time we spend on it is a waste, and slow down our work on MINA 3.0. We have some issues like DIRMINA-764, but it can be worked around on the client side, and can't be fixed on the server without fixing the whole mess and breaking the API. I suggest we stop here, unplug the monitor and oxygen, and move to the next version. Thoughts ? On 2/21/10 9:31 AM, Niklas Gustavsson wrote: On Sat, Feb 20, 2010 at 10:59 PM, Emmanuel Lecharny wrote: is there any reason why this stupid Hudson *always* fail when we commit some new code, and one hour later come back with again 6 useless mails telling us that "Hey, sorry, I was totally f*cked up last time I sent you 6 mails" ? I don't think that is entirely correct. We're running four builds for trunk (Ubuntu with Sun JDK 1.6, Ubuntu with Sun JDK 1.5, WIndows with Sun JDK 1.6, WIndows with Sun JDK 1.5). These get reported separately and might run at different times (due to how they are scheduled and the current job queue in Hudson), therefore the different builds might report their results at different times during about one hour (we poll SVN once per hour). One the the builds, on JDK 1.6 on Windows, consistently fails on one of the MDC tests. I reported that on this list about a week ago but I have not had the time to look into the details myself: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-windows/org.apache.mina$mina-core/14/testReport/org.apache.mina.filter.logging/MdcInjectionFilterTest/testOnlyRemoteAddress/ If Hudson can't inform us when there are *real* errors, at some point, we will simply ignore the alerts and lose all interest of having Hudson as a safety belt ! I'm pretty sure that on most occasions Hudson is reporting the real errors and that we should look into why the builds fail (like the one on Windows). That said, I've found a some builds in the last weeks where there seems to be inconsistencies in the results. Some of these are also worth looking into. Here are those I've found: * Build creating corrupt JAR, Maven problem?: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-windows/9/ * Maven failed to install JAR, Maven problem?: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-ubuntu/226 * One-time test failure in XBean module: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-windows/7 * Hudson problem, possibly due to the MINA build getting killed by a restart of Hudson: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-ubuntu/7/ * One-time test failure in core: http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-ubuntu/6/ So, I think our time is better spent at looking at why our tests fail, which will reduce the number of failed builds in Hudson (or any build tool) and thus the email frequency. /niklas -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: Make Hudson happy was : Re: Hudson strat to p*ss me off ...
What I want to say is : get this bloddy 2.0 out, and let's bury it. It's dead code, it's a cancer we can't fix. Any time we spend on it is a waste, and slow down our work on MINA 3.0. We have some issues like DIRMINA-764, but it can be worked around on the client side, and can't be fixed on the server without fixing the whole mess and breaking the API. I suggest we stop here, unplug the monitor and oxygen, and move to the next version. Thoughts ? I really think that this is a great chance for a guy like me who wants to participate in development but is not very familiar with current MINA design and code. Have been following some discussions around MINA 3.0 though, would love to see that take more momentum Kiran Ayyagari
Re: [sshd] Output for errOut goes to stdOut
Opened SSHD-76 with more info.
Thanks,
Bernd
On Fri, Feb 19, 2010 at 18:05, Guillaume Nodet wrote:
> I'm not aware of any problem like that.
> Are you connecting to a native ssh server or the one from SSHD ?
> Also could you try to set the log level to DEBUG on the client side
> and see if you see a SSH_MSG_CHANNEL_FAILURE somehow ?
> Maybe you could set up a small test case I could try and debug ?
>
> On Fri, Feb 19, 2010 at 17:42, Bernd Fondermann
> wrote:
>> Hi,
>>
>> I'm connecting to a remote machine using
>> org.apache.sshd.ClientSession.createChannel("shell");
>> I'm setting
>> channel.setOut(outputListener);
>> channel.setErr(errorListener);
>> to two distinct sinks.
>> Now, when I invoke an unexisting command on the other machine
>> directly, like this:
>> pommes >std.out 2>err.out
>> I'll find that - as expected - std.out is empty and err.out contains
>> -bash: pommes: command not found
>> while invoking this command (without output redirection) via sshd client,
>> I'll get the same error message via "out", none via "err".
>> With a debugger I could confirm that
>> org.apache.sshd.client.channel.AbstractClientChannel.doWriteExtendedData()
>> never get's called.
>>
>> What's it I'm doing wrong here?
>>
>> Thanks,
>>
>> Bernd
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
>
> Blog: http://gnodet.blogspot.com/
>
> Open Source SOA
> http://fusesource.com
>
Re: Make Hudson happy was : Re: Hudson strat to p*ss me off ...
Sounds like you are pissed now, try to breath ;) I'm agree for releasing 2.0 now. Julien Le Sun, 21 Feb 2010 11:53:28 +0100, Emmanuel Lécharny a écrit : > Ok, guys, > > sorry for my overreaction... > > Sure we have to check what's going on with the builds. > > If we look at the build history, we see that we don't have that many > failures. The problem is that those failures seems to be > time-dependent. The JDK 1.6/Windows build are also in constant > failure, and it has to be fixed. > > Looking at som of the failures, I'm a bit annoyed : the failing tests > are totally cryptic, I'm not able to know what is being tested. I > would say, considering MINA's history, I'm not suprised. At some > point, it's difficult to say if : > - the test is broken > - the part which is tested is broken but nobody uses it and should be > removed > - or we have a serious issue > > In any case, for anyone who crawl into the mud^H^H^Hcode it's pretty > obvious that MINA design is far from being extracted from any blue > print. Yesterday I had a look at the IoSession hierarchy, and once > agin, it's totally broken. We have generic used to express the fact > that the IoProcessor is typed, but it's not consistent, and to avoid > a compilation error, the top level processor variable does not use > generic. Also we don't have a processor varibale in the > AbstractIoSession, the place it should be. We don't have either the > getProcessor() method in the interface, and I can't move it there as > the API is frozen now. > > What I want to say is : get this bloddy 2.0 out, and let's bury it. > It's dead code, it's a cancer we can't fix. Any time we spend on it > is a waste, and slow down our work on MINA 3.0. > > We have some issues like DIRMINA-764, but it can be worked around on > the client side, and can't be fixed on the server without fixing the > whole mess and breaking the API. I suggest we stop here, unplug the > monitor and oxygen, and move to the next version. > > Thoughts ? > > On 2/21/10 9:31 AM, Niklas Gustavsson wrote: > > On Sat, Feb 20, 2010 at 10:59 PM, Emmanuel > > Lecharny wrote: > >> is there any reason why this stupid Hudson *always* fail when we > >> commit some new code, and one hour later come back with again 6 > >> useless mails telling us that "Hey, sorry, I was totally f*cked up > >> last time I sent you 6 mails" ? > > I don't think that is entirely correct. We're running four builds > > for trunk (Ubuntu with Sun JDK 1.6, Ubuntu with Sun JDK 1.5, > > WIndows with Sun JDK 1.6, WIndows with Sun JDK 1.5). These get > > reported separately and might run at different times (due to how > > they are scheduled and the current job queue in Hudson), therefore > > the different builds might report their results at different times > > during about one hour (we poll SVN once per hour). > > > > One the the builds, on JDK 1.6 on Windows, consistently fails on one > > of the MDC tests. I reported that on this list about a week ago but > > I have not had the time to look into the details myself: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-windows/org.apache.mina$mina-core/14/testReport/org.apache.mina.filter.logging/MdcInjectionFilterTest/testOnlyRemoteAddress/ > > > > > >> If Hudson can't inform us when there are *real* errors, at some > >> point, we will simply ignore the alerts and lose all interest of > >> having Hudson as a safety belt ! > >> > > I'm pretty sure that on most occasions Hudson is reporting the real > > errors and that we should look into why the builds fail (like the > > one on Windows). > > > > That said, I've found a some builds in the last weeks where there > > seems to be inconsistencies in the results. Some of these are also > > worth looking into. Here are those I've found: > > * Build creating corrupt JAR, Maven problem?: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-windows/9/ > > * Maven failed to install JAR, Maven problem?: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-ubuntu/226 > > * One-time test failure in XBean module: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-windows/7 > > * Hudson problem, possibly due to the MINA build getting killed by a > > restart of Hudson: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-ubuntu/7/ > > * One-time test failure in core: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-ubuntu/6/ > > > > So, I think our time is better spent at looking at why our tests > > fail, which will reduce the number of failed builds in Hudson (or > > any build tool) and thus the email frequency. > > > > /niklas > > > > > > -- Julien Vermillard Archean Technologies http://www.archean.fr signature.asc Description: PGP signature
Re: Make Hudson happy was : Re: Hudson strat to p*ss me off ...
On Sun, Feb 21, 2010 at 1:23 PM, Julien Vermillard wrote: > Sounds like you are pissed now, try to breath ;) > I'm agree for releasing 2.0 now. +1 /niklas
Re: Make Hudson happy was : Re: Hudson strat to p*ss me off ...
On Sun, Feb 21, 2010 at 4:23 PM, Emmanuel Lécharny wrote: > Ok, guys, > > sorry for my overreaction... > > Sure we have to check what's going on with the builds. > > If we look at the build history, we see that we don't have that many > failures. The problem is that those failures seems to be time-dependent. The > JDK 1.6/Windows build are also in constant failure, and it has to be fixed. > > Looking at som of the failures, I'm a bit annoyed : the failing tests are > totally cryptic, I'm not able to know what is being tested. I would say, > considering MINA's history, I'm not suprised. At some point, it's difficult > to say if : > - the test is broken > - the part which is tested is broken but nobody uses it and should be > removed > - or we have a serious issue > > In any case, for anyone who crawl into the mud^H^H^Hcode it's pretty obvious > that MINA design is far from being extracted from any blue print. Yesterday > I had a look at the IoSession hierarchy, and once agin, it's totally broken. > We have generic used to express the fact that the IoProcessor is typed, but > it's not consistent, and to avoid a compilation error, the top level > processor variable does not use generic. Also we don't have a processor > varibale in the AbstractIoSession, the place it should be. We don't have > either the getProcessor() method in the interface, and I can't move it there > as the API is frozen now. > > What I want to say is : get this bloddy 2.0 out, and let's bury it. It's > dead code, it's a cancer we can't fix. Any time we spend on it is a waste, > and slow down our work on MINA 3.0. > > We have some issues like DIRMINA-764, but it can be worked around on the > client side, and can't be fixed on the server without fixing the whole mess > and breaking the API. I suggest we stop here, unplug the monitor and oxygen, > and move to the next version. A big +1 Had this thought in my mind, but the way you enthusiastically took up the things stopped me :-) if we try to fix a lot of things in 2.0, we would be rewriting a lot of code :-( The energy is better spent on 3.0 discussions, prototypes, etc etc... thanks ashish
[Vote] MINA 2.0-GA
Hi guys, I know this will not be the perfect version, but it's not that bad. We have some pending issues that can probably be fixed in a 2.0.1 or later, but the base services are pretty much correctly covered. Here are the currently pending issues : DIRMINA-539 : Pb on TraficClass for datagram DIRMINA-760 : Client fails to detect server disconnection DIRMINA-764 : DDOS if the client does not wait the response We have also unscheduled issues that should be moved to 2.0.1. So, let's start a vote and see what happens : [ ] +1, yes get 2.0 out now [ ] +/-0 : I'm not pro or con. [ ] -1 : no, we are not ready. The vote is open for 72h, starting at 0:00, monday, 22, Paris' time. My vote : [X] +1, yes get 2.0 out now DIRMINA-539 -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: [Vote] MINA 2.0-GA
[X] +1, yes get 2.0 out now On Mon, Feb 22, 2010 at 4:17 AM, Emmanuel Lecharny wrote: > Hi guys, > I know this will not be the perfect version, but it's not that bad. We have > some pending issues that can probably be fixed in a 2.0.1 or later, but the > base services are pretty much correctly covered. > Here are the currently pending issues : > DIRMINA-539 : Pb on TraficClass for datagram > DIRMINA-760 : Client fails to detect server disconnection > DIRMINA-764 : DDOS if the client does not wait the response > > We have also unscheduled issues that should be moved to 2.0.1. > > So, let's start a vote and see what happens : > > [ ] +1, yes get 2.0 out now > [ ] +/-0 : I'm not pro or con. > [ ] -1 : no, we are not ready. > > The vote is open for 72h, starting at 0:00, monday, 22, Paris' time. > > My vote : > [X] +1, yes get 2.0 out now > > > DIRMINA-539 > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > > > -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
[mina 3.0] Idleness detection
Some thoughts about how to manage Idle sessions : In order to manage idle sessions, we should use a separated thread which will check periodically that the session has been used or not. We use a boolean flag which is reset when we read of write on this session, and switch to true when we check the session idleness : if the flag is already true, that means the session has been idle for at least one period. The thread will be wake up after having slept for the defined period (configurable globally), and will check every registered sessions. The flag is named isIdle. It's an AtomicBoolean. Note : if we want to manage different idle times for different sessions we need to compute the sleep period for all the followed sessions, and also add a map of sessions to check accordingly to the periods. IMO, it's a bit over killing atm. Q: should we manage two different IDLE states ? One for READ nod one for WRITE ? Not sure it makes sense... -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: [mina 3.0] Idleness detection
On Mon, Feb 22, 2010 at 1:12 PM, Emmanuel Lecharny wrote: > Some thoughts about how to manage Idle sessions : > > In order to manage idle sessions, we should use a separated thread which > will check periodically that the session has been used or not. We use a > boolean flag which is reset when we read of write on this session, and > switch to true when we check the session idleness : if the flag is already > true, that means the session has been idle for at least one period. > The thread will be wake up after having slept for the defined period > (configurable globally), and will check every registered sessions. I did something similar for a cache. Used an ScheduledExecutor to iterate through entries and decide what to do. It was ok, the only problem in my case was that I got CPU spikes each time I iterated, but the num of entries were more than a million :-) > The flag is named isIdle. It's an AtomicBoolean. > > Note : if we want to manage different idle times for different sessions we > need to compute the sleep period for all the followed sessions, and also add > a map of sessions to check accordingly to the periods. IMO, it's a bit over > killing atm. Ehcache has something similar for cache entries. Each cache entry has last accessed timestamp and based on that calculation is made. So if Session doesn't fit the criteria, we can safely leave the same. Side effect would be that we may not have precise time for events, it shall be when our Thread iterates through all of them. the other alternative is to use Timertask, but it has overhead that we need to kill the task each time the session is accessed and created a new task. there is a lot of overhead in this approach, but it works fine. > Q: should we manage two different IDLE states ? One for READ nod one for > WRITE ? Not sure it makes sense... Not sure if it makes sense, but whatever the case may be.. we fire a session idle event, and either use a keep-alive functionality or kill the session. May be we can start with one event. Could any implementation be interested in having distinct event? I am not sure thanks ashish
