search

Letractively / wro4j

Automatically exported from code.google.com/p/wro4j
0 stars 0 forks source link

resourceWatcherAsync=true doesn't behave deterministically in load balanced / clustered configurations #849

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
resourceWatcherAsync=true does what appears to be sub-requests to refresh the 
WRO resources (CSS/JS) asynchronously. You can see this by setting a breakpoint 
at UrlUriLocator:69, and observing the uri - it will be the full URL derived 
from what a user, at one time, requested. Ex, here's a uri at that breakpoint:
http://127.0.0.1:8080/assets/wro/base.js?wroAPI=resourceWatcher&group=base&resou
rceType=JS&auth=a31aaa53-57cf-4c74-94b4-9e7be67f839a
That value came up after I hit 
http://127.0.0.1:8080/assets/wro/base.js?minimize=true
If I hit http://localhost:8080/assets/wro/base.js?minimize=false the breakpoint 
uri changes to use "localhost" instead of "127.0.0.1"

This approach is problematic in clustered / load balanced configurations. Image 
the URL is:
https://www.example.com/wro/base.js?minimize=true
and there are 2 load balanced server (A and B).
A will request:
https://www.example.com/wro/base.js?wroAPI=resourceWatcher&group=base&resourceTy
pe=JS&auth=a31aaa53-57cf-4c74-94b4-9e7be67f839a
to refresh the JS asynchronously. Here's where the problems begin:
1) A may, depending upon what the cluster/load balancer feels like doing, 
actually end up hitting that URL on B, never refreshing it's own cache
2) A has to trust the SSL certificate of "www.example.com" (which it may not) - 
you could argue that this is a corner case, but especially in "Enterprise" 
setups, this isn't necessarily true

Original issue reported on code.google.com by candrews...@gmail.com on 18 Feb 2014 at 5:22

GoogleCodeExporter commented 9 years ago 
I'm not sure what the ideal solution is, but one idea is to change 
PreserveDetailsRequestWrapper so it always returns "localhost" as the server 
name, but it's not as simple as that as name based routing may be involved...

Original comment by candrews...@gmail.com on 18 Feb 2014 at 5:23

GoogleCodeExporter commented 9 years ago 
The async resource watcher is meant to be used mostly during development, where 
load balancers are typically not involved. However, I agree that the 
implementation should take into acount this kind of corner cases..

Original comment by alex.obj...@gmail.com on 19 Feb 2014 at 8:01

GoogleCodeExporter commented 9 years ago 
Another point worth mentioning is that you will probably should use a 
distributed cache implementation of CacheStrategy in a balanced environment. 
This would solve the original problem, since invalidation of a key on any 
server would eventually propagate to all nodes. Thoughts?

Original comment by alex.obj...@gmail.com on 19 Feb 2014 at 8:01

GoogleCodeExporter commented 9 years ago 
In my case (and I've seen this before, particularly in "cloud" type setups), 
there is no inter-server communication (no shared sessions or caches, session 
is per server and session affinity makes sure it works right). There is a 
common database, but using that for this purpose seems less than ideal (as the 
data will be large opaque blobs that aren't the ideal use for a SQL database). 
I think that's probably fairly common. I don't want to introduce inter-server 
communication now if I can avoid it :-)

Original comment by candrews...@gmail.com on 20 Feb 2014 at 3:19

GoogleCodeExporter commented 9 years ago 
I think it is possible to change the implementation of 
PreserveDetailsRequestWrapper or at least make it easily configurable.

Original comment by alex.obj...@gmail.com on 21 Feb 2014 at 9:59

GoogleCodeExporter commented 9 years ago 
Would you have time to provide a fix for this issue?

Original comment by alex.obj...@gmail.com on 21 Feb 2014 at 10:02

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 21 Mar 2014 at 9:19

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 8 Apr 2014 at 9:55

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 18 Jun 2014 at 11:07