I am getting this error when i run the command: cap rubber:create_staging
response_call': Duplicate => the specified rule \"peer: sg-86b557e9, TCP, from port: 1, to port: 65535, ALLOW\" already exists (Fog::Compute::AWS::Error)
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/middlewares/response_parser.rb:26:inresponse_call'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/connection.rb:402:in response'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/connection.rb:272:inrequest'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/middlewares/idempotent.rb:12:in error_call'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/middlewares/base.rb:10:inerror_call'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/middlewares/base.rb:10:in error_call'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/connection.rb:292:inrescue in request'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/connection.rb:229:in request'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/middlewares/idempotent.rb:12:inerror_call'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/middlewares/base.rb:10:in error_call'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/middlewares/base.rb:10:inerror_call'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/connection.rb:292:in rescue in request'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/connection.rb:229:inrequest'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/middlewares/idempotent.rb:12:in error_call'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/middlewares/base.rb:10:inerror_call'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/middlewares/base.rb:10:in error_call'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/connection.rb:292:inrescue in request'
from /home/user/.rvm/gems/ruby-2.1.0/gems/excon-0.37.0/lib/excon/connection.rb:229:in request'
from /home/user/.rvm/gems/ruby-2.1.0/gems/fog-1.22.1/lib/fog/xml/sax_parser_connection.rb:35:inrequest'
from /home/user/.rvm/gems/ruby-2.1.0/gems/fog-1.22.1/lib/fog/xml.rb:21:in request'
from /home/user/.rvm/gems/ruby-2.1.0/gems/fog-1.22.1/lib/fog/aws/compute.rb:462:in_request'
from /home/user/.rvm/gems/ruby-2.1.0/gems/fog-1.22.1/lib/fog/aws/compute.rb:457:in request'
from /home/user/.rvm/gems/ruby-2.1.0/gems/fog-1.22.1/lib/fog/aws/requests/compute/authorize_security_group_ingress.rb:49:inauthorize_security_group_ingress'
from /home/user/.rvm/gems/ruby-2.1.0/gems/fog-1.22.1/lib/fog/aws/models/compute/security_group.rb:102:in authorize_port_range'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/cloud/aws.rb:380:inadd_security_group_rule'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/cloud/aws.rb:481:in block (2 levels) in sync_security_groups'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/cloud/aws.rb:476:ineach'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/cloud/aws.rb:476:in block in sync_security_groups'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/cloud/aws.rb:405:ineach'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/cloud/aws.rb:405:in sync_security_groups'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/cloud/aws.rb:260:insetup_security_groups'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/cloud/aws.rb:75:in before_create_instance'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/thread_safe_proxy.rb:13:inmethod_missing'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/recipes/rubber/instances.rb:267:in block in create_instance'
from /home/user/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/monitor.rb:211:inmon_synchronize'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/recipes/rubber/instances.rb:266:in create_instance'
from /home/user/.rvm/gems/ruby-2.1.0/gems/rubber-2.10.0/lib/rubber/recipes/rubber/instances.rb:230:inblock (2 levels) in create_instances'
I just found a workaround, although I'm not sure how secure it is.
I went onto my instance and edited the default group. I removed all the inbound rules except for the most basic one. This one I then opened up to anyone:
That seemed to fix the problem.
UPDATE: This was fixed in a recent commit to Rubber. I'm currently pointed to the github repo, but you can also wait for 2.10.1 to come out.
Related
Am trying to use https://github.com/RallyTools/RallyRestToolkitForRuby to pull permissions of all users in my Rally Subscription. My authentication is through API Key. It fails with below error:
C:\Users\Administrator\Desktop\Rally-User-Management-master\Rally-User-Management-master>user_permissions_summary.rb
Connecting to Rally: https://rally1.rallydev.com/slm as ganra08#ca.com...
Running initial query of users...
Found a total of 12392 Enabled Users.
Summarizing users and writing permission summary output file...
C:/Users/Administrator/Desktop/Rally-User-Management-master/Rally-User-Management-master/lib/go_user_permissions_summary.rb:224:in block (2 levels) in go_user_permissions_summary'
C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/rally_api-1.2.1/lib/rally_api/rally_colle
ction.rb:36:ineach'
C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/rally_api-1.2.1/lib/rally_api/rally_collection.rb:36:in each'
C:/Users/Administrator/Desktop/Rally-User-Management-master/Rally-User-Management-master/lib/go_user_permissions_summary.rb:201:inblock in go_user_permissions_summary'
C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/rally_api-1.2.1/lib/rally_api/rally_query_result.rb:22:in block in each'
C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/rally_api-1.2.1/lib/rally_api/rally_query_result.rb:21:ineach'
C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/rally_api-1.2.1/lib/rally_api/rally_query_result.rb:21:in each'
C:/Users/Administrator/Desktop/Rally-User-Management-master/Rally-User-Management-master/lib/go_user_permissions_summary.rb:180:ingo_user_permissions_summary'
C:/Users/Administrator/Desktop/Rally-User-Management-master/Rally-User-Management-master/user_permissions_summary.rb:38:in <main>' undefined method[]' for nil:NilClass
How do i get over this error? The Readme.pdf in the GitHub page provides no info about this.
Agile Central (formerly Rally) support helped to resolve this.
The $wsapi_version variable is set in a couple of places. We need to ensure that it is set to '1.43', and not 'v2.0'. Then the error went away and the script runs as expected.
If using the my_vars.rb file, comment out both lines of the $wsapi_version and just let the one in the go_user_permissions_summary.rb (1.43) be used.
I have the following working curl command:
curl -k -E some_cert.pem https://someurl.com/__dirlist__
Trying to implement this in Ruby I have:
uri = URI.parse('https://someurl.com/__dirlist__')
http_session = Net::HTTP.new(uri.host, uri.port)
http_session.ca_file = "some_cert.pem"
http_session.use_ssl = true
http_session.verify_mode = OpenSSL::SSL::VERIFY_NONE
res = http_session.get(uri.request_uri)
I've played around with using all the different versions of SSL (using http_session.ssl_version = :SSLv2_client etc), all which failed (some with different messages), I matched up versions using wireshark to see what curl was using so don't think that's the problem (although ruby was sending a bunch of extra settings none seemed pertinent).
From reading other bug reports I've seen people have a lot of problems related to not having the appropriate certificates in their cert store however with SSL::VERIFY_NONE I don't see how that could matter.
I can't rule out that it could be the openssl baked into my Ruby but it seems unlikely to me given I've also run this code on another machine and gotten the same error and I would assume curl is linking against the same openssl (I don't know how to check this).
I've looked through the rdocs like I've exhausted all the settings available in Net:HTTP.
This is the nondescript error that I'm seeing (anonymised slightly):
OpenSSL::SSL::SSLError: SSL_read:: ssl handshake failure
from /Users/a_user/.rvm/gems/ruby-1.9.3-p0#project/gems/right_http_connection-1.3.0/lib/net_fix.rb:52:in `sysread'
from /Users/a_user/.rvm/gems/ruby-1.9.3-p0#project/gems/right_http_connection-1.3.0/lib/net_fix.rb:52:in `block in rbuf_fill'
from /Users/a_user/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/timeout.rb:68:in `timeout'
from /Users/a_user/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/timeout.rb:99:in `timeout'
from /Users/a_user/.rvm/gems/ruby-1.9.3-p0#project/gems/right_http_connection-1.3.0/lib/net_fix.rb:51:in `rbuf_fill'
from /Users/a_user/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/protocol.rb:122:in `readuntil'
from /Users/a_user/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/protocol.rb:132:in `readline'
from /Users/a_user/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:2562:in `read_status_line'
from /Users/a_user/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:2551:in `read_new'
from /Users/a_user/.rvm/gems/ruby-1.9.3-p0#project/gems/right_http_connection-1.3.0/lib/net_fix.rb:146:in `request'
from /Users/a_user/.rvm/gems/ruby-1.9.3-p0#project/gems/right_http_connection-1.3.0/lib/net_fix.rb:131:in `block in request'
from /Users/a_user/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:745:in `start'
from /Users/a_user/.rvm/gems/ruby-1.9.3-p0#project/gems/right_http_connection-1.3.0/lib/net_fix.rb:129:in `request'
from /Users/a_user/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:1026:in `get'
From the curl manual:
-k, --insecure
(SSL) This option explicitly allows curl to perform "insecure"
SSL connections and transfers. All SSL connections are attempted
to be made secure by using the CA certificate bundle installed
by default. This makes all connections considered "insecure"
fail unless -k, --insecure is used.
So running without -k might reveal the problem on curl as well.
I am trying to create a Bosh Microinstance on my Rackspace Server and am getting the following error:
E, [2013-10-29T15:17:25.113723 #30341] [0xc9c00c] ERROR -- : Unable to connect to the OpenStack Compute API. Check task debug log for details.
I, [2013-10-29T16:38:36.928221 #1754] [0x335004] INFO -- : No existing deployments found (will save to /root/bosh-deployments.yml)
I, [2013-10-29T16:39:14.636310 #1768] [0xfa9010] INFO -- : Loading existing deployment data from: /root/bosh-workspace/deployments/bosh-deployments.yml
I, [2013-10-29T16:39:20.766583 #1768] [0xfa9010] INFO -- : bosh-registry is ready on port 25889
I, [2013-10-29T16:39:26.731953 #1768] [0xfa9010] INFO -- : Loading yaml from /tmp/d20131029-1768-ewe5t0/sc-20131029-1768-ansv2l/stemcell.MF
E, [2013-10-29T16:39:28.626135 #1768] [0xfa9010] ERROR -- : Expected([200, 204]) <=> Actual(401 Unauthorized)
response => #<Excon::Response:0x0000000382cdc0 #data={:body=>"{\"unauthorized\":{\"code\":401,\"message\":\"Unable to authenticate user with credentials provided.\"}}", :headers=>{"Server"=>"nginx/0.8.55", "Date"=>"Tue, 29 Oct 2013 16:39:27 GMT", "Content-Type"=>"application/json", "Transfer-Encoding"=>"chunked", "Connection"=>"keep-alive", "vary"=>"Accept, Accept-Encoding, X-Auth-Token", "VIA"=>"1.0 Repose (Repose/2.3.5)"}, :status=>401, :remote_ip=>"72.3.138.129"}, #body="{\"unauthorized\":{\"code\":401,\"message\":\"Unable to authenticate user with credentials provided.\"}}", #headers={"Server"=>"nginx/0.8.55", "Date"=>"Tue, 29 Oct 2013 16:39:27 GMT", "Content-Type"=>"application/json", "Transfer-Encoding"=>"chunked", "Connection"=>"keep-alive", "vary"=>"Accept, Accept-Encoding, X-Auth-Token", "VIA"=>"1.0 Repose (Repose/2.3.5)"}, #status=401, #remote_ip="72.3.138.129"> (Excon::Errors::Unauthorized)
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/excon-0.25.3/lib/excon/middlewares/expects.rb:10:in `response_call'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/excon-0.25.3/lib/excon/middlewares/response_parser.rb:8:in `response_call'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/excon-0.25.3/lib/excon/connection.rb:349:in `response'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/excon-0.25.3/lib/excon/connection.rb:247:in `request'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/core/connection.rb:57:in `request'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/core/deprecated/connection.rb:20:in `request'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/openstack.rb:195:in `retrieve_tokens_v2'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/openstack.rb:88:in `authenticate_v2'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/openstack/compute.rb:392:in `authenticate'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/openstack/compute.rb:316:in `initialize'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/core/service.rb:68:in `new'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/core/service.rb:68:in `new'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/compute.rb:44:in `new'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_openstack_cpi-1.5.0.pre.1181/lib/cloud/openstack/cloud.rb:55:in `initialize'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cpi-1.5.0.pre.1181/lib/cloud/provider.rb:11:in `new'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cpi-1.5.0.pre.1181/lib/cloud/provider.rb:11:in `create'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/configuration.rb:65:in `cloud'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:54:in `cloud'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:229:in `block (2 levels) in create_stemcell'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:79:in `step'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:228:in `block in create_stemcell'
/usr/local/rvm/rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:214:in `create_stemcell'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:118:in `create'
"microbosh-openstack/bosh_micro_deploy.log" 215L, 28192C
I have a .yml file set up which I can't really post for security reasons, but I've verified with my IAAS support that i have the correct credentials.
Has anyone seen an error like this on Openstack? Also I am getting a stack trace and half tempted to try debugging. Problem is I'm not well versed on debugging these large open projects. Does anyone know a good resource explaining how to begin debugging them?
The error that you're seeing is caused by OpenStack rejecting the credentials that you're providing. One possible pitfall: are you using your Rackspace account password for "PASSWORD" instead of an API key? You can find your API key by logging in to your account, clicking on your username in the upper-right, and choosing "account settings" from the drop-down. (I'm assuming you're using Rackspace because of the question tags.)
You mentioned that you've verified them with your provider -- perhaps they aren't being passed in correctly? According to the documentation, you should put them in a micro_bosh.yml file with the following form:
# ...
cloud:
plugin: openstack
properties:
openstack:
auth_url: http://<identity_server>:5000/v2.0
username: <username>
api_key: <password>
tenant: <tenant>
region: <region> # Optional
default_security_groups: ["ssh", "bosh"]
default_key_name: <microbosh_keypair>
private_key: <path_to_microbosh_keypar_private_key>
# ...
Remember that YAML is whitespace-sensitive.
As for debugging open-source projects, the best guidance I can give is to not be afraid of the source and to have some patience. The source code for bosh is available on GitHub, so you can easily browse around the source code up your stack trace to try to figure out what's going on. Work backwards from the actual exception or error message that you're seeing; try to determine what was put into an unexpected state, and trace callers to figure out how it could have ended up that way. Reading other people's source code is an incredibly useful skill, and it gets easier with practice, so have at it!
I got GitLab 5.4 using Bitnami Stack 5.4.0-0
After creating user, login and adding key, when pushing to new repository
git#gitlab.funshion.com:gitdemo1/gittest1.git: /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `initialize': getaddrinfo: Temporary failure in name resolution (SocketError)
from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `open'
from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `block in connect'
from /opt/bitnami/ruby/lib/ruby/1.9.1/timeout.rb:55:in `timeout'
from /opt/bitnami/ruby/lib/ruby/1.9.1/timeout.rb:100:in `timeout'
from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `connect'
from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:756:in `do_start'
from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:745:in `start'
from /opt/bitnami/apps/gitlab/gitlab-shell/lib/gitlab_net.rb:62:in `get'
from /opt/bitnami/apps/gitlab/gitlab-shell/lib/gitlab_net.rb:17:in `allowed?'
from /opt/bitnami/apps/gitlab/gitlab-shell/lib/gitlab_shell.rb:60:in `validate_access'
from /opt/bitnami/apps/gitlab/gitlab-shell/lib/gitlab_shell.rb:23:in `exec'
from /opt/bitnami/apps/gitlab/gitlab-shell/bin/gitlab-shell:16:in `<main>'
UPDATE:
Please help with starting GitLab server. We tried on 3 computers, no success.
UPDATE 2: gitlam.yml says relative_url_root is not supported, while Bitnami GitLab runs at server/gitlab/
# WARNING: This feature is no longer supported
UPDATE 3: A bit similar problem Gitlab 5.4 push connection refused was solved by changing the default URL to the root http://wiki.bitnami.com/Applications/BitNami_GitLab#How_to_change_the_default_URL_to_the_root.3f
However after executing all those steps, my GitLab is still running at /gitlab/ even after reboot.
accessing / , get message "Not Found: /" instead of default screen. So the transition is not full.
Server itself could not resolve the domain name. Solution is to add the domain in the /etc/hosts file.
127.0.0.1 gitlab.company.com
Also check the redis configuration in the gitlab/config/resque.yml. Could be pointing to redis.example.com.
I'm trying to set the timeout for subsequent http calls to a very unreliable API. I tried multiple attempts at using Ruby's built-in Timeout.timeout() method but had had no such luck getting it to extend to sub calls. For example, Timeout.timeout(300) will set the first timeout to 300 but sub calls go back to 60. I added a print of the seconds_delay and here is what I saw:
[16:55:16 miker#laughwhat-lm ~/optisol/src/rails/tools_app/trunk/adhoc/ticket] $ bundle exec ruby buck.rb
300
nil
warning: peer certificate won't be verified in this SSL session
60
60
nil
warning: peer certificate won't be verified in this SSL session
60
Here is the error I receive with full stack trace:
[16:49:50 miker#laughwhat-lm ~/optisol/src/rails/tools_app/trunk/adhoc/ticket] $ bundle exec ruby buck.rb
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
/Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/timeout.rb:64:in `rbuf_fill': execution expired (Timeout::Error)
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/protocol.rb:134:in `rbuf_fill'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/protocol.rb:116:in `readuntil'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/protocol.rb:126:in `readline'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:2028:in `read_status_line'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:2017:in `read_new'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:1051:in `request_without_fakeweb'
from /Users/miker/.rvm/gems/ree-1.8.7-2011.03/gems/fakeweb-1.3.0/lib/fake_web/ext/net_http.rb:50:in `request'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:845:in `post'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/soap/netHttpClient.rb:93:in `post'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/soap/netHttpClient.rb:116:in `start'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:543:in `start'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/soap/netHttpClient.rb:115:in `start'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/soap/netHttpClient.rb:92:in `post'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/soap/streamHandler.rb:170:in `send_post'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/soap/streamHandler.rb:109:in `send'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/soap/rpc/proxy.rb:170:in `route'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/soap/rpc/proxy.rb:141:in `call'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/soap/rpc/driver.rb:178:in `call'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/soap/rpc/driver.rb:232:in `getByBuyer'
from buck.rb:9
from /Users/miker/.rvm/gems/ree-1.8.7-2011.03/gems/yieldmanager-0.8.2/lib/yieldmanager/client.rb:131:in `session'
from buck.rb:8
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/timeout.rb:67:in `timeout'
from /Users/miker/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/timeout.rb:101:in `timeout'
from buck.rb:6
So I guess my question would be how can I go about patching the protocol.rb BufferedIO's method to look like this:
class BufferedIO
private
def rbuf_fill
puts "working"
timeout(300) { # forced 300 second timeout
#rbuf << #io.sysread(BUFSIZE)
}
end
end
Adding that to my ruby file before or after I do my requires/includes does not have an affect (i.e. no "working" is ever printed out). Hope someone has a solution. Thanks!
Of all the various Ruby library's, the clumsiest to work with and ugliest, in my opinion, would have to be net::http. Have you considered switching to something like this:
https://github.com/dbalatero/typhoeus
The requests in typhoeus occur via lib-curl and so aren't bound by Ruby's not-so-reliable when nested or threaded timeout method.
In terms of the rbuf_fill issue, I'm not sure if that will get you there. If I remember correctly, when a timeout exception fires, it always shows the location that the code is currently at in the stack. That location is only incidental. Take the example below I just ran in irb. Notice how it tells you the timeout occured in "sleep"? Where the timeout is reported is just what it happened to be doing at that moment, not where the timeout code is necessarily implemented, nor do you know which timeout it is that is tripping if there are multiple. I'd have to chase down the rbuf_fill to confirm this for you though, and I have to run at the moment...
irb> timeout(2){sleep 5}
Timeout::Error: execution expired
from (irb):3:in sleep'
from (irb):3:inblock in irb_binding'
from (irb):3
from /home/ebelan