?? Jelikož v původním dotazu nebylo uvedeno nic o povaze volání, netroufal bych si tvrdit zda ze své podstaty synchronní nebo asynchronní. A odvozovat synchronnost/asynchronnost z časové náročnosti, to je... svérázné.
Něco jiného je, že synchronní volání v takovémto případě není zřejmě vhodné a bylo vy vhodné ho změnit na asynchronní, případně (pokud nelze provést zásadní změny architektury) simulovat sychronní volání pomocí asynchronního. Což bych zároveň považoval i za nejlepší závěr pro původního tazatele. Kamil Podlešák 2010/11/10 Oto Buchta <[email protected]>: > Dne 10. listopadu 2010 15:06 Kamil Podlesak <[email protected]> > napsal(a): >> Nevím sice co by na tom mělo být za prasárnu, nicméně problém je ještě > > Protože asynchronní volání je simulováno synchronním a tím pádem se > drží všechny zdroje navázané na to volání a tedy brzy dojdou. > >> horší: nejen že tam jsou volaní delší než 60 sekund, ale je jich >> tolik, že došlo k vyčerpání poolu na HTTP spojení. > > A proto také došlo k tomuto. Defaultně se HTTP pool nastavuje na 100 s > timeoutem minuta a frontou maximálně deset krát větší než je pool. > Potom se dostáváme k výkonnosti necelé dva požadavky za sekundu. A to > mi v roce 2010 příjde setsakra málo. > >> >> Timeout sice lze změnit, ale bylo by asi vhodné pořádně prozkoumat zda >> to vůbec pomůže. >> >> Kamil Podlešák >> >> On 10 November 2010 14:52, Oto Buchta <[email protected]> wrote: >>> Chapu to spravne, ze pouzivas takovou prasarnu, jakou je synchroni >>> volani pres HTTP transport, ktere trva dele nez 60 sekund? >>>
