dispatch http request to all pool members instead of only one pool member

This is an interesting question and one that comes up from time to time. A clone pool is a one-way mechanism. It accepts no responses and establishes no sessions. It possibly could be made to work, but might require some substantial tweaking to your environment. Ultimately, you're confined to a single "flow" in a request or response event, so to make this work you'd have to do something to force new flows for each backend server. For example, you could:

1. Save the request
2. Send the request to a pool member
3. Catch the response
4. Reselect a new pool member
5. Use HTTP::retry to send the saved request to the new pool member
6. Rinse and repeat

This may have changed in recent versions, but I believe there's still an issue with how many times you can call LB::reselect, so you may be limited to that number. Another option is an internal sideband call. This basically launches a separate "tangent" flow to wherever you want it to go, without affecting the main flow. Here's an example:

proc send_to_sideband { data server } {
     this is the sideband processing procedure (function)

     create a new sideband connection
    set sbserver [connect -protocol TCP -timeout 100 -idle 5 -status conn_status $server]

     send the sideband request
    send -status send_status -timeout 100 $sbserver $data

     return the sideband response
    return [recv -status recv_status -timeout 300 $sbserver]
}
when HTTP_REQUEST {
    if { [HTTP::method] equals "DELETE" } { 
        foreach x [active_members -list [LB::server pool]] {
            set sb [call send_to_sideband [HTTP::request] [join $x ":"]]
        }
        HTTP::respond 200 content "Complete"
    }   
}

Both sideband and procs are really cool. You need 11.4 to do procs and sideband has been around since 11.1 I think. You can do this without a proc by just putting the sideband code inside the loop, but this looks cooler. The idea is that, for every pool member, you launch a sideband call to that pool member with the original request. at the end of that loop you simply return a status "complete" to the user. A few words of caution though.

1. Looping through all of the pool members will induce some latency. It'd do that no matter how you sent the request to each, but just keep that in mind.

    

2. Be careful. Assuming the DELETE semantic is allowed in your web servers, you should probably take care to make sure unintentional deletes can't happen.