nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Freemarker shows webscript response from cache

zladuric

Hello,

I have a similar problem to this one:
http://forums.alfresco.com/en/viewtopic.php?f=36&t=20538&p=66938&hilit=cache#p66938

I have a webscript which returns a json rendered based on a document property. Now, this works for some clients, and for some, not.
The webscript itself is called from share, from document-actions.get.js. The result is then processed in document-actions.get freemarker.

The only difference I've noticed is the OS. When I call the webscript from my machine, on linux (Firefox, Chrome, Opera, curl-ing the webscript directly with an alf ticket, whatever), I always get correct results. When I try from a Mac, it's good. But for windows clients (Internet Explorer, few versions, latest Firefox) - the result shown is cached. I get the values that should be shown in the previous step.

Tried with the explicit

<cache>
     <never>true</never>
     <mustrevalidate>true</mustrevalidate>
  </cache>
‍‍‍‍‍

..doesn't work.

I've even done the following:
- added a timestamp argument (simple timestamp) to webscript
- shown it in the log and in UI on the share side

Now it gets really weird: I see that the webscript gets called again! and the timestamp from the webscript log and the UI match - but I still get the old result.

Why does the windows browser go back in time and get the result for the document from when it was at least half-a-day younger?

Find more posts tagged with

Comments

zladuric

Gets even weirder - when I read a custom prop from one browser, I get one (valid) value. When I do it AFTER that with the other browser, I get another (older) value.

And if I don't call the status-changing webscript (although I already done that), it'll always stay like that. It's like I have two different repositories!!

kevinr

Do you have a proxy in the middle?

If the cache setting is applied appropriate then it should work, as it just sets the usual HTTP cache headers - examine them in FireBug or Fiddler or similar to see if they what you think they are!

Kev

zladuric

Nope, no proxy.

Besides, what is cached is the node property. I tried including a timestamp in a webscript call, and then logging the timestamp and the property (along with the nodeRef).

So I tried the following: setting the property to "value1". Afterwards, I change it to "value2" with the same webscript I normally use.

Then I call my original script directly (via URI) from one browser, and I get in the system log:

Timestamp: <date_and_time>, property value: "value2"‍

Then I call the webscript from the other browser - and the second response is:

Timestamp: <new_date_and_time>, property value: "value1"‍

P.S. Lightbulbed on a point while writing this reply - I call the script with nodeRef argument, then use search.findNode(nodeRef); to get the document. Does that mean that I could be getting the prop value from lucene cache? But why isn't the cache cleared after the first call?

P.P.S. Oh, and thanks for the reply. I'm getting totally crazy with this.

kevinr

Hi,

The property values from node are always pulled from the NodeService, Lucene is used to retrieve Node *references* only - you would perhaps get a noderef back from Lucene that does not actually exist - but it would blow up immediately you tried to populate its properties - so an exists() call is needed in that case - so that is not the issue you are seeing.

I assume you are *not* running a cluster?

When you say "I get in the system log:" - are you logging output from your repository webscript to the console via the logger or do you mean "in the browser window"? (i'm just trying to rule out browser caching here, which I think we now have done)

I would suggest you look using the NodeBrowser admin tool to see what the *actual* value of the node is before running the test again, that might help highlight something.

Cheers,

Kev

zladuric

I am not running a cluster, you're right.
Also, I am logging to the console via logger.

The actual value of a node is "value2" (the one that should be there). So why would I call a webscript twice and get different results is way beyond me.

The actual use case is that some of inhouse users get this "status", based on which I show them an additional link in document-details. (The link is actually calling the other webscript - which changes the prop value and does other stuff.)

So for the same document in share, I get different possible values, and users get confused.

zladuric

Just an update:

logger.log("Tasks: "+args["timestamp"]+", user: "+person.properties.userName + ", nodeRef: "+args["nodeRef"]);‍

Results the same from various browsers in log, but I get different JSON output:

11:35:08,885 User:admin DEBUG [repo.jscript.ScriptLogger] Tasks: null, user: admin, nodeRef: workspace://SpacesStore/382dd161-b0bd-471f-b170-87c2bbc51cf2‍

And the problem is, when I log a doc.properties[myCustomProp] - I get two different values.

Where can I look next?

zladuric

Oh, and more fun this way:

logger.log("Property: "+prop+",modified: "+doc.properties["cm:modified"]);‍

From firefox: (same user, same nodeRef)

11:59:32,993 User:admin DEBUG [repo.jscript.ScriptLogger] Property: booking,modified: Thu Dec 30 2010 08:59:43 GMT+0100 (CET)‍

From Chrome:

11:58:55,615 User:admin DEBUG [repo.jscript.ScriptLogger] Property: consulting,modified: Thu Dec 30 2010 08:59:43 GMT+0100 (CET)‍