This repository has been archived by the owner on Jan 15, 2024. It is now read-only.
no implicit conversion of nil into String (TypeError) #290
Comments
|
getting the same issue here: |
|
Us too: |
|
It's happening on our project as well. Has anyone found a decent work around? It happens intermittently and it's proving impossible for me to replicate. |
|
Hi, Any updates on this? We are also running into the same issue. Thanks! |
|
+1 |
|
Our project is affected by this bug as well. We are using Ruby 2.1.2 with Moped 2.0.0 and Rails 4.1.4. |
|
also seeing this issue is this a mongodb server problem? cant tell why that would be nil. i did check and the server seems to be up, though i'm using mongohq elastic and they do replica sets or something |
|
How is this happening? thanks |
|
my issue earlier was that I had a malformed YML settings. |
|
I've seen this happen on one of the apps I'm working on... seems to happen after a couple of days. The first time I saw it was when we migrated to ruby 2.1.2 (from ruby 2.1.1, due to issues with the garbage collector) Currently running:
|
|
+1 we see this as well. We're using:
For us, it usually happens after 2-3 days of running. |
|
i have no idea how to replicate this, however I was seeing 1,000 of these exceptions reported a day on production it is using replica sets via mongohq, so there might be some kind of screwed up handling i'm doing a trial run just using a single server mongodb database setup (with no failover) to see if the errors happen then let me know if I can do anything to help debug this issue. I've only ever seen it on production, and it seems to happen non-deterministically (some hours i'll get 300 errors, other hours none) |
|
@mickeyren Your stack trace is different from the others listed here. Yours is caused by a nil username or password. |
|
@danielevans yes. It was caused by a malformed database yml |
|
Same here, running:
|
|
+1 |
1 similar comment
|
+1 |
|
anyone find any good workaround to this? I'm still seeing thousands of these a day in production |
|
@railsjedi, not sure if it'll be viable for you, but when we experienced it in our app we surrounded the problematic code with retry logic. Just had to swallow the exception and try again. With Rails we used the around filter and just marked which resource to apply. Since it seemed occurrences were arbitrary and the error didn't look like it happens in succession retrying once after a failure pretty much cleared this up. Though not as good as an actual fix for the issue. |
|
i think the root of the problem is just timeouts. So the bug is just that it crashes on timeout instead of giving some sort of reasonable exception ( maybe a way to replicate this bug is to have a mongodb server that takes a couple seconds to respond to queries? for my project, i switched my prod server to use a dumb hacked fork of moped 2.0 with the default timeouts set to much higher [redacted] |
|
Same issue here ... TypeError: no implicit conversion of nil into String
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/connection/socket/tcp.rb:20:in `initialize'
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/connection/socket/tcp.rb:20:in `block in initialize'
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/connection/socket/connectable.rb:119:in `handle_socket_errors'
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/connection/socket/tcp.rb:20:in `initialize'
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/connection/socket/connectable.rb:145:in `new'
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/connection/socket/connectable.rb:145:in `block in connect'
from .rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/timeout.rb:91:in `block in timeout'
from .rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/timeout.rb:35:in `block in catch'
from .rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/timeout.rb:35:in `catch'
from .rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/timeout.rb:35:in `catch'
from .rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/timeout.rb:106:in `timeout'
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/connection/socket/connectable.rb:144:in `connect'
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/connection.rb:52:in `connect'
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/node.rb:531:in `connect'
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/node.rb:179:in `block in ensure_connected'
from .rvm/gems/ruby-2.1.2/gems/moped-2.0.0/lib/moped/node.rb:115:in `block in connection'... 34 levels...
from .rvm/gems/ruby-2.1.2/gems/mongoid-4.0.0/lib/mongoid/contextual/mongo.rb:199:in `block (2 levels) in first'
from .rvm/gems/ruby-2.1.2/gems/mongoid-4.0.0/lib/mongoid/contextual/mongo.rb:535:in `with_sorting'
from .rvm/gems/ruby-2.1.2/gems/mongoid-4.0.0/lib/mongoid/contextual/mongo.rb:198:in `block in first'
from .rvm/gems/ruby-2.1.2/gems/mongoid-4.0.0/lib/mongoid/contextual/mongo.rb:447:in `try_cache'
from .rvm/gems/ruby-2.1.2/gems/mongoid-4.0.0/lib/mongoid/contextual/mongo.rb:197:in `first'
from .rvm/gems/ruby-2.1.2/gems/mongoid-4.0.0/lib/mongoid/contextual.rb:20:in `first'
from .rvm/gems/ruby-2.1.2/gems/mongoid-4.0.0/lib/mongoid/findable.rb:107:in `find_by' |
|
+1 |
|
We're having the exact same issue. Our production systems are going nuts. I'm in touch with mongohq/compose and will let you know once I found out something. As it always occurs only after a while I guess there're some connections stalling around or so... |
|
+1 |
|
anyone able to reproduce the error? |
|
@sebastian-julius did you speak to compose? what did they say? I tried @railsjedi 's branch but we still got the same errors afterwards. Anyone have any idea on how to go about setting up a repeatable test environment with which to investigate? It's ominously quiet on this issue and #308... |
|
We do not see the timeout any more. Compose had some issues during that timeframe. They and we guess it had to do with that situation! As it disappeared automagically it's fixed for us now. |
|
Also started getting this error a couple hours after upgrading to 2.1.2. Seems to be timeout related but haven't been able to track anything down yet. |
|
I've installed a caching nameserver on my box ( http://unbound.net/ ), and the errors stopped. So looks like it's a timeout issue with the DNS resolution. IMHO, Moped should cache the resolved IP address of the mongo nodes, at least for a while. Less DNS resolution requests should also help improving the performance. |
|
I see the same error message with a new Rails App. I don't think is the same issue (right?), but can help kosh@yuna:~/projects/test$ rails c
Loading development environment (Rails 4.1.6)
[1] pry(main)>
[2] pry(main)> Sender.first
TypeError: no implicit conversion of Fixnum into String
from /home/kosh/.rvm/gems/ruby-2.1.2@msg-gate/gems/moped-2.0.0/lib/moped/protocol/commands/authenticate.rb:35:in `+'
[3] pry(main)> |
|
how does the mongoid yml config file look like? specially the host part? |
|
See also #275 |
|
After 24 hours running #324 in production without a single "no implicit conversion of nil into String" error, I'd say we've found a solution to this problem. |
|
closing this as #324 was merged and it should solve this issue |
|
I am having this issue at this very moment. Anybody else ? |
|
@Elyasin which version of moped are you using? |
|
Thanks for the quick answer. I think I have the latest Moped. I tried using master, but no changes. EDIT: I thought it was Moped's issue, but it was a red herring :-( Moped could not authenticate because I did not set the environment vars. Sorry for having wasted your time @arthurnn |
|
Maybe moped should give a better error message when the authentication credentials are |
|
i am having this issue.. in |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
and others
I'm getting a lot of this errors sin updating to moped2/mongoid4:
The text was updated successfully, but these errors were encountered: