Hi Andrea,
I'll defer to your judgement on implementation details of course, but I think
the heavy-load is resolvable by simply having the value really high. I was
thinking considerably higher than whatever the GeoServer (rendering time -
which I know is only for a portion of the full-query-handling-time),
load-balancer, proxy-server, or whatever else have their timeouts set to.
So if they all have timeouts set to 60s, a minimum token-timeout of say 120s
would probably be my suggestion (or maybe even higher??).
The idea is to ensure tokens remain alive over the long-term. It shouldn't
matter in this context if a token is missing for a few minutes while the
difference between the timeouts passes, the server admin would want to not be
permanently losing tokens which over a period of days, weeks, months, or even
longer could add up.
As a bonus, this would improve the load-balancing further if tokens did go
missing during high load because it would give GeoServer a slight reprieve for
a minute or two (or whatever the value is set to) as the number of tokens (and
thus requests) is temporarily reduced.
As long as that's documented clearly in the manual (including the reasoning) so
folks can set it appropriately, I believe this should neatly side-step the
heavy-load problem.
Cheers,
Jonathan
---- On Mon, 23 May 2016 13:04:38 +0100 Andrea
Aime<[email protected]> wrote ----
On Mon, May 23, 2016 at 1:42 PM, Jonathan Moules
<[email protected]> wrote:
Hi Andrea,
Just a thought, but what about implementing a timeout on the pool tokens,
and/or allowing one to be configured?
That way if one request in a while goes astray, after n-seconds control-flow
will assume things broke and the token will be returned to the pool. That way
you don't end up with a situation of the pool getting slowly smaller over time
as the odd erroneous-in-a-certain-way query makes tokens disappears gradually.
Yes, this idea has been discussed but I'm fiercely resisting it for a couple of
reasons:
It is not entirely trivial to implement
It makes control-flow completely useless under heavy load, when all the
requests end up taking a lot of time, and by allowing more to get it due to the
timeout, which in the end make things works as requests will take even longer,
allowing more tokens to reach the timeout and thus allow even more requests in.
Long story short, imho, if I cannot trust control-flow to limit concurrent
access under heavy load, it's useless and it's better to run without. I want to
fix it instead of allowing it to degrade into no-control
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo
è consentito esclusivamente al destinatario del messaggio, per le finalità
indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne
il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di
procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro
sistema. Conservare il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse,
costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the
attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act (Legislative
Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in
accord with its purpose, any disclosure, reproduction, copying, distribution,
or either dissemination, either whole or partial, is strictly forbidden except
previous formal approval of the named addressee(s). If you are not the intended
recipient, please contact immediately the sender by telephone, fax or e-mail
and delete the information in this message that has been received in error. The
sender does not give any warranty or accept liability as the content, accuracy
or completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of e-mail
transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
