Red Hat Bugzilla – Bug 1275647
Proxy templates API breaks on concurrent requests
Last modified: 2017-02-23 14:44:10 EST
When trying to render templates concurrently, multiple (different) failures occurs. Reproducer: <pre> #!/bin/bash proxy_url=$1 token=$2 num_requests=$3 path="${proxy_url}/unattended/iPXE?token=${token}" for (( i=0; i<$num_requests; i++ )) do curl -s $path & done </pre> <pre> # ./proxy_error_test.sh http://localhost:8448 eb9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6 15 Failed to retrieve iPXE template for {"token"=>"eb9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", "splat"=>[], "captures"=>["iPXE"], "kind"=>"iPXE"}: stream closedFailed to retrieve iPXE template for {"token"=>"eb9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", "splat"=>[], "captures"=>["iPXE"], "kind"=>"iPXE"}: stream closedFailed to retrieve iPXE template for {"token"=>"eb9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", "splat"=>[], "captures"=>["iPXE"], "kind"=>"iPXE"}: undefined method `closed?' for nil:NilClassFailed to retrieve iPXE template for {"token"=>"eb9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", "splat"=>[], "captures"=>["iPXE"], "kind"=>"iPXE"}: undefined method `closed?' for nil:NilClassFailed to retrieve iPXE template for {"token"=>"eb9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", "splat"=>[], "captures"=>["iPXE"], "kind"=>"iPXE"}: undefined method `closed?' for nil:NilClassFailed to retrieve iPXE template for {"token"=>"eb9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", "splat"=>[], "captures"=>["iPXE"], "kind"=>"iPXE"}: undefined method `closed?' for nil:NilClassFailed to retrieve iPXE template for {"token"=>"eb9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", "splat"=>[], "captures"=>["iPXE"], "kind"=>"iPXE"}: undefined method `closed?' for nil:NilClass </pre>
Created from redmine issue http://projects.theforeman.org/issues/12319
I think this should make it in 6.1 z-stream. Upstream merged. Low effort.
Upstream bug assigned to ddolguik@redhat.com
Moving to POST since upstream bug http://projects.theforeman.org/issues/12319 has been closed ------------- Anonymous Applied in changeset commit:26aba8520d3d32ca27b9708cb98169bc31d43d7b.
I was trying to verify this bz with given script and steps in comment 7 and 8. However, looks like port 8000 is not valid. hwoever, with port 8443, I'm getting following output. [root@cloud-qe-6 ~]# ./racetest.sh http://localhost:8443 b9d50b5c-23a3-4a66-b4d2-9f18cafc7db9 5 [root@cloud-qe-6 ~]# Is this expected result, please confirm ? thanks
Created attachment 1115759 [details] test_result with 8443 port
Please take a look at attachment.
Oh port is the smart proxy port, which is usually 9090, 8448 or 8443 according to your configuration. You must see request logs in proxy.log.
Thank you Lukas. Verified with in 6.1.6 compose #5 On concurrent requests, I don't see error reported in original bug request. I tried with 1500 requests concurrently. [root@cloud-qe-6 ~]# ./racetest.sh http://localhost:9090 b9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6 1500 [root@cloud-qe-6 ~]# ./racetest.sh https://localhost:9090 b9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6 1500 Failed to retrieve iPXE template for {"token"=>"b9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", "splat"=>[], "captures"=>["iPXE"], "kind"=>"iPXE"}: Error retrieving iPXE for {"token"=>"b9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", :url=>"http://cloud-qe-6.idmqe.lab.eng.bos.redhat.com:8000"} from cloud-qe-6.idmqe.lab.eng.bos.redhat.com: Net::HTTPMethodNotAllowed ::::: ::::: Failed to retrieve iPXE template for {"token"=>"b9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", "splat"=>[], "captures"=>["iPXE"], "kind"=>"iPXE"}: Error retrieving iPXE for {"token"=>"b9e1d9c-0bd1-4361-a3c2-7e0961a9b5b6", :url=>"http://cloud-qe-6.idmqe.lab.eng.bos.redhat.com:8000"} from cloud-qe-6.idmqe.lab.eng.bos.redhat.com: Net::HTTPMethodNotAllowed
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:0052
*** Bug 1343667 has been marked as a duplicate of this bug. ***