#6 — Ticked invalidated in a zeo cluster system

State Confirmed
Version: 1.1
Area Functionality
Issue type Bug
Severity Medium
Submitted by Reinout van Rees
Submitted on Jan 16, 2009
Target release:
**Note: this was copy/pasted from the old tracker at plone4artists.org, so it are multiple replies underneath eachother**

I am getting "Ticket ... was invalidated, cannot be used", when I try to upload more than I single file using my Squid server round robin through my 6 zeo-clients (in another word zeo-clustering).

If I close all clients except one everything works fine. If I reach my ZODB via a single client, bypassing squid, it works fine as well.

Could it be the RAMCache definition for the ticket? When a file is being uploaded via a zeo-client the ticket maybe is being travelling through the othe zeo-client and so on? Both RAMCaches would have different states on different zeo-caches! Just gessing.

Steps to reproduce:
    1) Have zeo-clustering (2 or more zeo-clients)
    2) Have a load balancer (squid in my case)
    3) try to upload 2 or more files through the squid address (using chacheFu's squid setup)

Added by Wolfgang Thomas on 31-03-2008 12:30
I get a very similar behaviour using 2 ZEO frontends. Sometimes it happens that the frontend doing the validation is not the same that issued the ticket. --> Ticket not valid.

Afaik, RAMCache works on a per-machine basis (being in local memory).
Added by Reinout van Rees on 07-04-2008 13:50
Issue state: unconfirmed → open
Yes, ploneflashupload's usage of ramcache makes it unsuitable for zeo setups. I haven't delved deeply enough in the code to know what that ramcache is actually used for.

Perhaps some memoize caching could serve the same function?
Added by Wolfgang Thomas on 07-04-2008 14:16
Yes, or maybe be ticket information could be stored in the session.

I created a workaround in our ZEO environment today so that ploneflashupload can be used with several frontends:

Just tell squid to forward all requests
- where the useragent (browser) is "Shockwave Flash" AND
- where the urlpath_regex is "@@ticket$"
to one dedicated frontend.
The first rule catches the actual uploading, the second rule the ticket issuing (2 separate requests).
Of course, if that frontend fails, flashuploading fails...
Added by (anonymous) on 10-04-2008 13:39
Wolfgang Thomas, how do you do that? Which squid directives you include in your squid.conf, please? I apologize for my ignorance.
Added by Wolfgang Thomas on 21-04-2008 03:40
I added two acl entries:
    acl special_useragents browser "/etc/squid/special_useragents.txt"
Which points to a text file that contains a single line:
    Shockwave Flash

    acl special_urlpath urlpath_regex "/etc/squid/special_urlpath.txt"
Which points to a file containing this regex:

With these 2 acls, I catch the uploading process (user agent == "Shockwave Flash"), and the ticket validation (urlpath ends with "@@ticket").

For my resgular cache-peers (in my case pound, in your case probably 5 out of your 6 round-robin frontends), I deny access for these acls, something like:
# send everything to regular_frontend except special_useragents and special_urlpath
cache_peer_access regular_frontend deny special_useragents
cache_peer_access regular_frontend deny special_urlpath
cache_peer_access regular_frontend allow all

I have one dedicated frontend which handles PloneFlashuploading exclusively:
# send special_useragents and special_urlpath to dedicated frontend
cache_peer_access special_frontend allow special_useragents
cache_peer_access special_frontend allow special_urlpath

There may be smarter solutions, but it works for me.
hth, Wolfgang
Added by (anonymous) on 30-07-2008 13:31
I patched PFU to make it play with ZEO-Clusters suing memcached, see http://bluedynamics.com/[…]/ploneflashupload-on-zeo-clusters
Added by (anonymous) on 23-09-2008 05:22
We use the loadbalancer in apache for balancing between multiple zeo clients so we have the same problem using PloneFlashUpload.

Using a patch is not really an option for us as we wan't to keep our packages as clean as possible.

The workaround we use now is almost the same as the squid solution posted above, only in apache :

RewriteCond %{HTTP_USER_AGENT} ^Adobe\ Flash\ Player.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^Shockwave\ Flash\ Player.* [OR]
RewriteCond %{REQUEST_URI} ^(.*)/uploadfile(.*)$
RewriteRule ^/(.*) http://<your_dedicated_zeoclient>:8080/VirtualHostBase/http/<your_url>:80/<your_plone_instance>/VirtualHostRoot/$1 [L,P]

Added by Reinout van Rees on Jan 16, 2009 02:31 PM
Issue state: UnconfirmedConfirmed
Ramonski: could SWFUpload (now that you've put that into 1.2) help solve this issue?
Added by Peter Jacobs on Nov 19, 2009 03:34 PM
We had the same problem and are trying the last solution with Apache. I had to tweak the RewriteRule to channel more requests to the dedicated instance:

RewriteRule ^/(.*flashupload|.*uploadfile|\+\+resource\+\+swfupload\/swfupload.swf)(/?$|/.*) \
  http://<your_dedicated_zeoclient>:8080/VirtualHostBase/http/<your_url>:80/<your_plone_instance>/VirtualHostRoot/_vh_$1$2 [L,P]

No responses can be added.