Not when it gets distributed across a cluster... It also depends on how
large the string is which gets stored in the session. Any hoo... it can
also be part of the strategy. Make it configurable.
Martijn
Gili wrote:
>
> I'm still a little fuzzy on how this new approach works, but
> zipping up the temporary storage seems like a bad idea to me. Doesn't
> the client-side redirect come back fairly quickly? Zipping it up for
> ten seconds seem like a waste of resources to me.
>
> Gili
>
> Martijn Dashorst wrote:
>
>> As a side note, we could zip the request for temporary storage in the
>> session, and unzip it when served (preferable hot). This would exchange
>> some processing power for space...
>>
>> Martijn
>>
>> Eelco Hillenius wrote:
>>
>>
>>> Note for list: this is an idea we discussed at Topicus (means Martijn
>>> - came up with the idea -, Johan and I) today. Basically, all
>>> processing is now done in one pass, but when redirect is true, the
>>> response is buffered instead of send to the output stream, and the
>>> redirect is used to get that buffered response. Only potential
>>> problems I see with it, is that it consumes more memory potentially,
>>> though as all processing is done in one pass, it might save a bunch of
>>> temporary objects that were used otherwise.
>>>
>>> Could Johan check his code in (as a branch?), and could you - Chris,
>>> Juergen, Jonathan (if you're not shooting a movie) - take a look at
>>> it? It seems pretty important to me (read 1.0) to have a solid answer
>>> to some of the problems with the current redirect pattern.
>>>
>>> Eelco
>>>
>>> Johan Compagner wrote:
>>>
>>>
>>>> We always do clientside redirects. So developer don't always take
>>>> this into account.
>>>> Like setResponsePage(new Page(myHibernateObject))
>>>> then myHibernateObject uses a wrong HibernateSession.
>>>>
>>>> ClientSide redirect do fix a number of problems so we like to keep
>>>> this.
>>>>
>>>> Now i made a hybrid solution.
>>>> We do use a clientside redirect put the responsepage is rendered as
>>>> it was a serverside redirect...
>>>>
>>>> Changed 2 classes/methods:
>>>>
>>>> WebRequestCycle.redirectTo(final Page page)
>>>> {
>>>> String redirectUrl = page.urlFor(page, IRedirectListener.class);
>>>> // create the redirect response.
>>>> Response previous = getResponse();
>>>> RedirectResponse rr = new RedirectResponse(redirectUrl);
>>>> setResponse(rr);
>>>> page.request();
>>>> setResponse(previous);
>>>> Map map =
>>>> (Map)getWebRequest().getHttpServletRequest().getSession(true).getAttribute("wicket-redirect");
>>>>
>>>>
>>>> if(map == null)
>>>> {
>>>> map = new HashMap(3);
>>>>
>>>> getWebRequest().getHttpServletRequest().getSession(true).setAttribute("wicket-redirect",map);
>>>>
>>>>
>>>> }
>>>> map.put(redirectUrl,rr);
>>>> // Redirect to the url for the page
>>>> response.redirect(redirectUrl);
>>>> }
>>>>
>>>> So when we redirect the page is first rendered (page.request()) in a
>>>> buffered response object.
>>>> this object is stored in the httpsession.
>>>> Then the redirect is done.
>>>>
>>>> in:
>>>>
>>>> WicketServlet.doGet(final HttpServletRequest servletRequest,
>>>> final HttpServletResponse servletResponse) throws
>>>> ServletException, IOException
>>>> {
>>>> // try to see if this is a redirect that is already stored in
>>>> the wicket-redirect map of its session.
>>>> Map redirectMap =
>>>> (Map)servletRequest.getSession(true).getAttribute("wicket-redirect");
>>>> if(redirectMap != null)
>>>> {
>>>> RedirectResponse rr =
>>>> (RedirectResponse)redirectMap.remove(servletRequest.getRequestURI() +
>>>> "?" + servletRequest.getQueryString());
>>>> if(rr != null)
>>>> {
>>>> PrintWriter pw = servletResponse.getWriter();
>>>> servletResponse.setContentLength(rr.getContentLength());
>>>> servletResponse.setContentType(rr.getContentType());
>>>> pw.write(rr.toString());
>>>> pw.close();
>>>> return;
>>>> }
>>>> }
>>>> // Get session for request
>>>> final WebSession session =
>>>> webApplication.getSession(servletRequest);
>>>>
>>>> I first test if there is a redirect response item in the redirect map.
>>>> If this is the case then that redirect object is removed from the map
>>>> and the redirect is written to the directly written to the response.
>>>>
>>>> the drawback:
>>>> There is a complete page in mem of the server for a very short time.
>>>>
>>>> plus:
>>>> the redirect is very very fast. And doesn't take almost no memory, no
>>>> hibernate session need to be created nothing needs to be loaded.
>>>>
>>>>
>>>> Any objections for this approach?
>>>> We could make it optional or something
>>>>
>>>> johan
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF.Net email is sponsored by: Tell us your software development plans!
>>>> Take this survey and enter to win a one-year sub to SourceForge.net
>>>> Plus IDC's 2005 look-ahead and a copy of this survey
>>>> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
>>>> _______________________________________________
>>>> Wicket-develop mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is sponsored by: Tell us your software development plans!
>>> Take this survey and enter to win a one-year sub to SourceForge.net
>>> Plus IDC's 2005 look-ahead and a copy of this survey
>>> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
>>> _______________________________________________
>>> Wicket-develop mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Tell us your software development plans!
>> Take this survey and enter to win a one-year sub to SourceForge.net
>> Plus IDC's 2005 look-ahead and a copy of this survey
>> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
>> _______________________________________________
>> Wicket-develop mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>
>>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
