Hi,
There is an outstanding Jira (UP-3552) that relates to this.
Obviously for large files a longer timeout may be needed, however due to
this issue we are forced to choose a very high timeout that will work
for very slow connections.
-- Anthony.
On 29/08/13 09:51, Vincent Bonamy wrote:
Hi All,
Even if the latest release of esup-filemanager (2.2.2), we use here in
production the "future" version of esup-filemanager (3.0.0-SNAPSHOT -
master on github/EsupPortail) which is already stable actually.
This version corresponds to a portlet 2.0 (esup-filemanager 2.2.2 is
portlet 1.0) for which all requests go through uPortal: that is to say
the Ajax requests, but also the Download and Upload requests !
We did this because portlet 2.0 provides these features and with that,
the code is so much easier (no sharing sessions/objects between
portlet/servlet ).
On the other hand, the upload request (for example) is also constrained
by this portal render timeout ... and so, 5 seconds or 20 seconds are
too low values for the user ... -> I put 2 hours (7200000) for this
portlet.
For esup-filemanager (> v. 3.0.0) , the default value with 5000 or 20000
does not matter really ... but sure, it is very important that the
administrator set up "well" this parameter.
Vincent.
On 28/08/2013 22:45, Jim Helwig wrote:
I think I lean towards Anthony's side. I'd have to check what we set
ours to, but we aim to have requests served under 5sec. Long running
requests are outside the norm. I would think the default could be low
and if a portlet is known to need more, it could be changed accordingly.
That said, an administrator should generally review them before moving
into production so maybe the default is not as important.
JimH
-------- Original message --------
From: Anthony Colebourne <[email protected]>
Date: 08/28/2013 15:26 (GMT-06:00)
To: [email protected]
Cc: James Wennmacher <[email protected]>
Subject: Re: [uportal-dev] Proposal to change portal's default render
timeout from 5000ms to 20000ms
Hi James,
In my experience I would recommend extreme caution when raising portlet
timeouts.
Under heavy load, it is very easy to use up all the portlet rendering
threads.
Just this morning I accidentally mis-configured a portlet who's time out
is 10000 and brought down our servers. We're pretty strict about timeout
values and almost all of our portlets use the 5s default.
We in many cases use ajax to load content from long-running processes.
I'm some of these cases I have reluctantly raised to timeout of the
resource requests only.
I would like to see documented the relationship between rendering
threads and timeout values, also how this relates to tomcat threads and
apache threads where applicable. (I guess db connection pools are also
impacted, both portal and portlet?).
Some guidance on how to choose sensible thread/timeout values based on
averages such as portlets per page / server resources would be useful.
I'm happy to provide information and statistics from our production
cluster if it helps?
-- Anthony.
On 28/08/13 20:08, James Wennmacher wrote:
> I propose we change the portal's default render timeout from 5000ms to
> 20000ms. There are portlets that tend to take long time (such as email
> preview) or custom portlets connecting to back end systems where 5000ms
> is sometimes too short a time.
>
> I think the user experience in general would be better to have a longer
> default so:
> - The portal doesn't display an unpleasant message to the user for
> longer-running scenarios
> - The portal is more tolerant of operational issues such as uPortal or
> dependent systems running a bit slow
> - Longer-running processes should typically use ajax requests to obtain
> the data for a better user experience, so the urgent user response is
> less important in these situations since the entire UI is not impacted
>
> This would affect new portlets that are created via the UI (or imported
> without a timeout value I believe) but not existing portlet instances.
>
> Thoughts?
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
