Olivier increased it to 30 min https://jira.codehaus.org/browse/WAGON-365 http://svn.apache.org/viewvc?view=revision&revision=1213414
Thus I suppose we have to prepare another RC ? Is there others feedback to listen before launching another RC ? Others problems with the RC3 ? On Tue, Dec 13, 2011 at 9:24 AM, Anders Hammar <and...@hammar.net> wrote: > I also think that 60s timeout is way too short for corporate users. I > suggest something like at least 180s (500s would be even better). If > we go with 60s, I know for sure that it will fail for most of my > corporate customers and Maven will be the focus of some more bad > talks. Please don't do this - it will be bad for Maven! > Those that want to lower timeout could configure that. A third digit > release should not have a big impact on your environment. > > As someone pointed out, in most corporate environments downloads are > scanned by AV engines. And that means that the entire file needs to be > downloaded by that engine and then scanned, before made available to > the repo manager. So this isn't something that the repo manager could > fix. > > /Anders > > On Mon, Dec 12, 2011 at 16:21, Arnaud Héritier <aherit...@gmail.com> > wrote: > > +1 to have it set to 5 or 10 minutes by default and with a big warning > and > > associated doc in the release note > > Even if I understand Brian about the "why do we fix something not > reported > > as broken", I would better consider it as an improvement and not a fix. > > Do we have to release a 3.1 just for this improvement .... I'm not > sure... > > Do we want to wait for a 3.1 to include it ... I'm less sure ... > > > > > > On Mon, Dec 12, 2011 at 4:04 PM, Igor Fedorenko <i...@ifedorenko.com> > wrote: > > > >> m2e has read timeout of 60s by default (IDE is different environment, > >> we can't afford blocking build thread forever). There were > >> bugreports about this. Some corporate users reported wait times in tens > >> of minutes due to conservative firewall setup that fully downloads > >> artifacts and does antivirus scan before serving the artifact to the > >> client. > >> > >> -- > >> Regards, > >> Igor > >> > >> > >> On 11-12-12 9:45 AM, Olivier Lamy wrote: > >> > >>> 2011/12/12 Brian Fox<bri...@infinity.nu>: > >>> > >>>> Agree. > >>>>> I will add it in release and complete documentation here: > >>>>> http://maven.apache.org/**guides/mini/guide-http-**settings.html< > http://maven.apache.org/guides/mini/guide-http-settings.html> > >>>>> > >>>> > >>>> > >>>> This seems like a pretty big change and not enough people will read > >>>> that and start to freak out. If maven worked all this time with no > >>>> read timeout, why change it now? I've never been aware of it causing a > >>>> problem and this is just begging for all kinds of bug reports and > >>>> flaming blogs. > >>>> > >>> > >>> If any remote repository/server hang, I'm still thinking not wait > >>> infinitely a response from a server is a good idea and will provide a > >>> better user experience. (sure IMHO) > >>> > >>> BTW 60s value is maybe to small. > >>> What would you prefer as value ? 300s ? > >>> > >>> Note this value is the SO_TIMEOUT which is the value before receiving > >>> the first packet or the maximum of inactivity time between 2 packets. > >>> > >>> > >>> > >>>> > >>>> > >>>>> > >>>>>> - Brett > >>>>>> > >>>>>> -- > >>>>>> Brett Porter > >>>>>> br...@apache.org > >>>>>> http://brettporter.wordpress.**com/< > http://brettporter.wordpress.com/> > >>>>>> http://au.linkedin.com/in/**brettporter< > http://au.linkedin.com/in/brettporter> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> ------------------------------**------------------------------** > >>>>>> --------- > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org< > dev-unsubscr...@maven.apache.org> > >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Olivier Lamy > >>>>> Talend: http://coders.talend.com > >>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy > >>>>> > >>>>> ------------------------------**------------------------------** > >>>>> --------- > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org< > dev-unsubscr...@maven.apache.org> > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>> > >>>>> > >>>> ------------------------------**------------------------------** > >>>> --------- > >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org< > dev-unsubscr...@maven.apache.org> > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>> > >>>> > >>> > >>> > >>> > >> > ------------------------------**------------------------------**--------- > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org< > dev-unsubscr...@maven.apache.org> > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
