ok... i've been thinking about film for 12.5 hours straight today so forgive me...
the core problem is really that the request can go to server A and then the redirect to B, right?
what does chris think? he's our clustering expert.
jon
Martijn Dashorst wrote:
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
------------------------------------------------------- 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
