Cookies and Clusters

["(Home) Dan Connelly" <ds...@adelphia.net>]

I have recently ran across this interesting, web app.  It is a quite MVC-ish with a Controller servlet and Model beans, but too much logic in the JSPs to be strictly Views (no taglibs).

This app features a page with a hierarchical, walking menu, somewhat like a "DHTML Labs" HierMenu.

However, each step through this menu hiearchy requires (??) an interaction with the web server.  [I leave open the possibility that the "walking" requests to the server might be overkill in this case.]

Fetching each successive level of  the walking menu from the server is handled in a complex JavaScript in this app.  This JS sends a request, a POST, to the controlller, giving the level in the hierarchy and the OPTION picked in the last traversed SELECT list.  The browser gets back a Status Code=204, NO CONTENT.   The screen is not updated, except as noted below.  The document model (including JavaScript) is not replaced.  The JS now examines the Cookies where it finds the encoded options for the next select list.  It then fills in that select list with the newly received options.  Very smooth screen changes.  The MVC ideal.     

(So OK, the graphics aren't so great.  It not really a HierMenu.  It doesn't really "walk"  The "menu" is fully extended to begin with.  The "unwalked" lists on the right are empty.  But its the same idea.  And it could scale up nicely beyond what DHTML could do with wimpey static hierarchies.)

Is this legal?  I think so.  It does seem to be what 204 (NO CONTENT) is intended to be used for.  So that's kosher.

Cookies get a lot of bad press.  But, cookies (or complex URL encoding) are the fall-back when session beans are not going to be used.   Many JSP developers will shun session beans because the app might get deployed on clustered servers (reverse proxied).  Each POST might then be dispatched to a different JVM.  Session beans were not shared correctly among clustered JVMs until Servlet 2.3.  (Correct me if I am wrong.)   Nobody is there yet in the commercial offerings.

Is there any one of us working on a taglib for Sruts with cookie hacks like this?  Or, am I going to get a well-deserved flaming for even suggesting the possiblity.

Dan Connelly      (Not the famous guy at W3C).

Re: Cookies and Clusters (Cookies)

["(Home) Dan Connelly" <ds...@adelphia.net>]

I will reply to Malcolm Davis in two parts: Cookies, then (later) Clusters:

Cookies:

Yes, my presentation of the DHTML and JS stuff was a bit confusing.  And unnecessary.

Let me boil it down.   

What I was musing about was a hack (??) I had just seen in a non-Struts MVC app whereby the current page gets updated, in situ, through the cookie(s) that head-up an SC_NO_CONTENT page just sent from the server.  The JavaScript in the current page reads the cookie(s) and updates its own document model.  No screen flash.  Very smooth.  A nice MVC screen effect.  Think of the Color Chooser, the canonical MVC application.   Smooth updates.

Is it a hack?  Would we consider such a technique for Struts?

Of course, having the client code read cookies might be considered weird.  But why not.  This is the web.  We survived the frameset mish-mash.   Many B2B apps have captive clients on dedicated PCs.   If the app wants cookies, he should get cookies, right?  These are session cookies, not persistent cookies.  Privacy is not a big concern.  If the browser is loading up on cookies from other apps and maxes out, he gets a nice warning to quit screwing around.

I did not write this MVC-ish app that I am talking about.  I am merely testing it, aggresively, looking for hacks.   I don't have access to the servlet code but I can see the cookies arriving at the browser.  No JSESSIONID there.  Just 4k of encoded state.   You ask, does this app use HttpSession?  Apparently not.  It bakes its own cookies, complex cookies.  

Bad.  Bad.  Bad.  

But I like it.   It contributes to MVC.  Why not do it, do it, do it??????

  ----- Original Message ----- 
  From: malcolm davis 
  To: struts-user@jakarta.apache.org 
  Sent: Monday, April 23, 2001 1:47 AM
  Subject: RE: Cookies and Clusters


  Dan, 

  > Cookies get a lot of bad press.  But, cookies (or complex URL encoding) are the fall-back 
  > when session beans are not going to be  used.   Many JSP developers will shun session 
  > beans because the app might get deployed on clustered servers (reverse proxied).  
  > Each POST might then be dispatched to a different JVM.  Session beans were not shared 
  > correctly among clustered JVMs until Servlet 2.3.  (Correct me if I am wrong.)   
  > Nobody is there yet in the commercial offerings.

  iPlanet does, and I'm sure other vendors do also.

  I'm a little lost here about the DHTML & JS stuff, 
  but you might have a misunderstanding about cookies. 

  You can turn cookies off in the browser, but the Appserver should 
  implement them via the jsessionid.  Cookies are fine for a cluster environment.  
  The servlets must be marked as sticky, meaning each subsequent request will 
  return to the correct JVM.  Of course, this might depend on the Appserver being 
  used, and how your cluster is configured.

  At my present job, we have 3 machines running 10 JVM's, a total of 30 JVM's
  in the cluster. 

  If your not using session beans, are you using HttpSession?

  - malcolm

RE: Cookies and Clusters

[malcolm davis <ma...@nuearth.com>]

Dan,

> Cookies get a lot of bad press.  But, cookies (or complex URL encoding)
are the fall-back
> when session beans are not going to be  used.   Many JSP developers will
shun session
> beans because the app might get deployed on clustered servers (reverse
proxied).
> Each POST might then be dispatched to a different JVM.  Session beans were
not shared
> correctly among clustered JVMs until Servlet 2.3.  (Correct me if I am
wrong.)
> Nobody is there yet in the commercial offerings.

iPlanet does, and I'm sure other vendors do also.

I'm a little lost here about the DHTML & JS stuff,
but you might have a misunderstanding about cookies.

You can turn cookies off in the browser, but the Appserver should
implement them via the jsessionid.  Cookies are fine for a cluster
environment.
The servlets must be marked as sticky, meaning each subsequent request will
return to the correct JVM.  Of course, this might depend on the Appserver
being
used, and how your cluster is configured.

At my present job, we have 3 machines running 10 JVM’s, a total of 30 JVM’s
in the cluster.

If your not using session beans, are you using HttpSession?

- malcolm