Forum Discussion

Narendra_26827's avatar
Icon for Nimbostratus rankNimbostratus
May 15, 2012

universal persistence issue




We are facing a strange problem with universal persistence.




We have one vip on port 443 in which we have one default pool (Pool A)




other than that there are 2 additional pools (Pool B,C) to which request is redirected based on URI and it is persisted via iRule.




The iRule is :








switch -glob [string tolower [HTTP::uri]] {




"/api/xyz*" {


pool "Pool B"


persist uie [HTTP::header "objectId"] 300






"/api/abc*" {


pool "Pool C"


persist uie [HTTP::header "objectId"] 300






default {


pool "Pool A"


persist none











The default static requests are routed to Pool A, while /api http calls which contains objectId in headers are persisted to respective Pools (B & C) based on URI.




Now sometimes not always the request for Pool B /api/xyz* are load balanced in round robin fashion and are not persisted within the same time period (same as persistence TTL of 300 sec.) This is causing our critical application to crash.




We want if the connection is established for first time it should be persisted to same node every time.




Our client call these http calls /api/xyz* with every long poll of 55 seconds so i don't think the persistence record is getting cleared it should reset again for every request.




We don't have much logging enabled in production as well as the access is restricted so we can't say much what exactly is happening.




Can anyone help us around this. What exactly are we doing wrong here? Or there is some area other than persistence that we have to look into.




Thanks in advance.


4 Replies

  • nathe's avatar
    Icon for Cirrocumulus rankCirrocumulus



    May be a shot in the dark but thought I'd add a comment. From the Configuration Guide re Universal Persistence:



    When you enable universal persistence, the system can sometimes ignore


    persistence information in the request URI (due to the way that the system


    parses HTTP requests). To mitigate this issue, F5 Networks recommends


    that you also configure a OneConnect™ profile, as well as enable the


    OneConnect Transformation setting of the HTTP profile.



    I wonder if this might help explain things.



    Hope it helps.



  • Thanks Nathan for your reply.



    We have already enabled oneconnect profile in the vip and also we do have oneconnect transformations setting enabled in the http profile.