cancel
Showing results for 
Search instead for 
Did you mean: 

Granule generating different ids for the same combined.js and combined.css file

Former Member
0 Kudos

Hi,

We have enabled granule for compression in our project. It works well and we do see a combined.js and combined.css file getting generated.

However, there are some anomalies we see -

  1. When we hit the home page (first URL) of application and check the combined.js, it has one id generated from the server. Not sure how the id generation process works though.

  2. Now when I do a search, the request goes to same back end hybris server but the id of combined.js changes.

Ideally, the id generated should be same per user session. The id can only be different if compressed JS versions are different. So we checked what is changing and found the CSRF token is included in "acc.common.js" file and as CSRF token will be different for different users, it may cause issue.

combined.js?id=5a3c089915572d1 combined.js?id=c09566f215572d1

So now we plan to take out the code from js.tag to master.tag so that CSRF token inclusion is not there in combined.js file.

However, now the issue is in clustered environment, at times the combined.js and combined.css doesn't get loaded. It throws 404 on home page. When we click on search, it generates a new id for combined.js and loads properly.

Note: We are using Varnish for caching in front of web server (apache). so the set up is:

  1. LB

  2. Varnish (for caching all JS/CSS/HTML)

  3. Web Server

  4. Hybris application server (2)

I need to know 2 things:

  1. Why id is generated different for different URLs within application? What is the logic granule uses to generate the id?

  2. When we by pass Varnish (although it is not caching combined.js/css) and hit the server directly the CSS and JS gets loaded properly.

Unfortunately there is not much documentation on granule and hence finding it difficult to understand how these ids are generated and also how can we control it? For instance; ids should be same in a clustered environment for all the users irrespective of servers because JS cached will be same.

Any help in this regard will be a blessing :) Saurabh

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Just to add more information, we are caching home page in varnish. however, other pages like PLP, PDP are not cached. Can that be the reason that varnish when caching HTML also caches the URL within HTML with the ID appended to combined.css and when home page is hit, it gives an old id which is not present on the server and hence 404 ?

Former Member
0 Kudos

Hi Saurabh,

We are also using this approach in couple of applications. When we use granule approach. We really dont required to cache the generated css or js. Because loading for this js and css is not too much time. You can ignore this from caching. That will be the easiest approach.

Otherwise cache everythiing wihout using granule approach i believe.

Thanks

Samudrala

Former Member
0 Kudos

Hi Vinay, The question is not about caching. As per our set up it is not getting cached anyway. However, the question is why multiple ids are getting generated for combined.css. I looked at carefully and found, hybris OOTB is appending a different Javascript on different user journey and hence it generates a different combined.js.

In a clustered environment, it is leading to 404 ocassionally. Not sure how come the specific combined.css leads to 404.