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 <[email protected]> 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 <[email protected]> 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<[email protected]>: >>> >>>> 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 >>>>>> [email protected] >>>>>> http://brettporter.wordpress.**com/<http://brettporter.wordpress.com/> >>>>>> http://au.linkedin.com/in/**brettporter<http://au.linkedin.com/in/brettporter> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------**------------------------------** >>>>>> --------- >>>>>> To unsubscribe, e-mail: >>>>>> [email protected].**org<[email protected]> >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Olivier Lamy >>>>> Talend: http://coders.talend.com >>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>> >>>>> ------------------------------**------------------------------** >>>>> --------- >>>>> To unsubscribe, e-mail: >>>>> [email protected].**org<[email protected]> >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> ------------------------------**------------------------------** >>>> --------- >>>> To unsubscribe, e-mail: >>>> [email protected].**org<[email protected]> >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> [email protected].**org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
