Moped::Errors::OperationFailure failed with error "no such cmd - ruby-on-rails

I recently upgraded from mongoid 2.0.2 to mongoid 3 with rails 3.2.12 and ruby 1.9.3 .
Following issue comes when save command excutes => #new_node.save
Moped::Errors::OperationFailure (The operation: #<Moped::Protocol::Command
#length=366
#request_id=30
#response_to=0
#op_code=2004
#flags=[:slave_ok]
#full_collection_name="campus_dev.$cmd"
#skip=0
#limit=-1
#selector={:aggregate=>"nodes", :pipeline=>[{"$match"=>{"parent_id"=>"51382df8851d1912b7000009", "_id"=>{"$ne"=>"513f24952f1feda4bc000002"}, "position"=>{"$nin"=>[nil]}}}, {"$group"=>{"_id"=>"position", "count"=>{"$sum"=>1}, "max"=>{"$max"=>"$position"}, "min"=>{"$min"=>"$position"}, "sum"=>{"$sum"=>"$position"}, "avg"=>{"$avg"=>"$position"}}}]}
#fields=nil>
failed with error "no such cmd"):
app/controllers/nodes_controller.rb:37:in `create'

You didn't mention also upgrading MongoDB version to the latest (at that time).
If you were pointing at an older MongoDB server that didn't recognize the "aggregate" command, then you would get exactly this error.
All instances of similar errors seem to have been pointing at older mongod process.

Related

An ActionView::Template::Error occurred in sessions#new: activeadmin couldn't find file 'active_admin/nested_menu_arrow.gif'

After updgrading from Rails 5.0.1 to 5.2.0, there was an upgrade in active admin (from 1.0.0.pre5 to 2.6.0)
Now I am getting :
An ActionView::Template::Error occurred in sessions#new:
couldn't find file 'active_admin/nested_menu_arrow.gif'
Checked in these paths:
/mnt/d/Project/Wittybrains/Optisom/clarityv2/app/assets/images
/mnt/d/Project/Wittybrains/Optisom/clarityv2/app/assets/javascripts
/mnt/d/Project/Wittybrains/Optisom/clarityv2/app/assets/stylesheets
/mnt/d/Project/Wittybrains/Optisom/clarityv2/vendor/assets/javascripts
/mnt/d/Project/Wittybrains/Optisom/clarityv2/vendor/assets/stylesheets
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/lazy_high_charts-1.4.3/vendor/assets/javascripts
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/bundler/gems/activeadmin-ef1faccaef75/app/assets/javascripts
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/bundler/gems/activeadmin-ef1faccaef75/app/assets/stylesheets
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/bundler/gems/activeadmin-ef1faccaef75/vendor/assets/javascripts
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/jquery-rails-4.3.5/vendor/assets/javascripts
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/formtastic-3.1.5/app/assets/stylesheets
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/actioncable-5.2.0/lib/assets/compiled
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/activestorage-5.2.0/app/assets/javascripts
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/actionview-5.2.0/lib/assets/compiled
/mnt/d/Project/Wittybrains/Optisom/clarityv2/app/assets/fonts
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/font-awesome-sass-4.5.0/assets/stylesheets
/root/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/font-awesome-sass-4.5.0/assets/fonts
app/assets/stylesheets/active_admin.css.scss:9
After digging on Google, finally I found this link :
https://git.rarolabs.com.br/rarolabs/active_admin/tree/1a16239be31d40307f3fee972e91ca15b9341167/app/assets/images/active_admin
What I did, I downloaded the necessary resources and keep in my project path at corresponding locations. This solves the issues.

ArgumentError: cannot interpret as DNS name: nil capybara

Hi all can anyone help me to resolve the issue
'ArgumentError: cannot interpret as DNS name: nil'
The error is coming when doing capybara selenium integration testing in rails 4
here I am using jruby-1.7.9 and ruby version inside JRuby is 2.0.0p195
already I had used the Ruby version is 1.9.7 at that time I faced the error
'cant connect to chrome driver error'
in pure ruby like without using JRuby its the integration testing is working. but my application is in JRuby. and I am using ubuntu platform.
So anyone have any solution on this. what should I do to resolve this??
Here iam adding the exception backtrace
["/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:1181:in create'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:1027:ingenerate_candidates'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:1052:in resolv'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:518:ineach_resource'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:411:in each_address'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:120:ineach_address'", "org/jruby/RubyArray.java:1613:in each'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:119:ineach_address'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:97:in getaddress'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/resolv.rb:48:ingetaddress'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/1.9/resolv-replace.rb:10:in getaddress'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/1.9/resolv-replace.rb:22:ininitialize'", "org/jruby/RubyIO.java:1178:in open'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/net/http.rb:882:inconnect'", "org/jruby/ext/timeout/Timeout.java:144:in timeout'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/net/http.rb:881:inconnect'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/net/http.rb:866:in do_start'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/net/http.rb:855:instart'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/2.0/net/http.rb:582:in start'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara/server.rb:81:inresponsive?'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara/server.rb:97:in boot'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara/session.rb:72:ininitialize'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara.rb:324:in current_session'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara/dsl.rb:47:inpage'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara/dsl.rb:52:in visit'", "/media/sidharthan/NewVolume/sidharthan_fooddev/foodapp/webapp/food/test/test_helper.rb:115:inIntegrationTest'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/capybara-2.9.1/lib/capybara.rb:67:in configure'", "/media/sidharthan/NewVolume/sidharthan_fooddev/foodapp/webapp/food/test/test_helper.rb:102:inIntegrationTest'", "org/jruby/RubyBasicObject.java:1565:in instance_exec'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:446:inmake_lambda'", "org/jruby/RubyProc.java:271:in call'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:192:insimple'", "org/jruby/RubyProc.java:271:in call'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:504:incall'", "org/jruby/RubyArray.java:1613:in each'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:504:incall'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:92:in __run_callbacks__'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:782:in_run_setup_callbacks'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/callbacks.rb:81:in run_callbacks'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activesupport-4.2.6/lib/active_support/testing/setup_and_teardown.rb:41:inbefore_setup'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/activerecord-4.2.6/lib/active_record/fixtures.rb:827:in before_setup'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:105:inrun'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:204:in capture_exceptions'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:104:inrun'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:255:in time_it'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:103:inrun'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:348:in on_signal'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:275:inwith_info_handler'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest/test.rb:102:in run'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:799:inrun_one_method'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:322:in run_one_method'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:310:inrun'", "org/jruby/RubyArray.java:1613:in each'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:309:inrun'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:348:in on_signal'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:335:inwith_info_handler'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:308:in run'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:158:in__run'", "org/jruby/RubyArray.java:2409:in map'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:158:in__run'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:135:in run'", "/home/sidharthan/.rbenv/versions/jruby-1.7.9/lib/ruby/gems/shared/gems/minitest-5.9.1/lib/minitest.rb:62:inautorun'"]
Thanks in advance
From the stacktrace you can see it's erring inside https://github.com/teamcapybara/capybara/blob/2.9.1/lib/capybara/server.rb#L81 - which is while Capybara is waiting for the application to be tested to start up.
This could mean you have set Capybara.server_host or Capybara.server_port incorrectly. Without the real code you're running that generates the stacktrace it's impossible to say.
You also probably want to update to the latest 2.x version of Capybara -- 2.9.1 is really old.

Neo4j.rb (8.0.11) + Resque : Input/output error # io_write - <STDOUT>

I have recently upgraded neo4j and I am getting issue in resque workers,
Exception
Errno::EIO
Error
Input/output error # io_write - <STDOUT>
I am getting this issue and backtrace says its related to neo4j.rb puts
Errno::EIO: Input/output error - <STDOUT>
/home/ubuntu/staycircles-backend/shared/bundle/ruby/2.3.0/gems/neo4j-8.0.11/lib/neo4j/session_manager.rb:60:in `write'
/home/ubuntu/staycircles-backend/shared/bundle/ruby/2.3.0/gems/neo4j-8.0.11/lib/neo4j/session_manager.rb:60:in `puts'
/home/ubuntu/staycircles-backend/shared/bundle/ruby/2.3.0/gems/neo4j-8.0.11/lib/neo4j/session_manager.rb:60:in `puts'
/home/ubuntu/staycircles-backend/shared/bundle/ruby/2.3.0/gems/neo4j-8.0.11/lib/neo4j/session_manager.rb:60:in `block in wait_for_value'
My current configration is
neo4j version - 3.xx
neo4j.rb - 8.0.11
Could you try updating to 8.0.13 of the neo4j gem?
The gem maintainers have released v 8.0.13, which removes the puts statements. Want to see if it fixes the issue on your end?
https://github.com/neo4jrb/neo4j/releases/tag/v8.0.13

Sunspot Solr core initialization failure

When I run my tests, most of them fail with the following error.
Failure/Error: let(:user){ FactoryGirl.create(:user) }
RSolr::Error::Http:
RSolr::Error::Http - 500 Internal Server Error
Error: {msg=SolrCore 'test' is not available due to init failure: Error opening new searcher,trace=org.apache.solr.common.SolrException: SolrCore 'test' is not available due to init failure: Error opening new searcher
at org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:745)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:299)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
URI: http://localhost:8981/solr/test/update?wt=ruby
Request Headers: {"Content-Type"=>"text/xml"}
Request Data: "<?xml version=\"1.0\" encoding=\"UTF-8\"?><add><doc><field name=\"id\">User 13497</field><field name=\"type\">User</field><field name=\"type\">ActiveRecord::Base</field><field name=\"class_name\">User</field><field name=\"phone_number_text\">+11111111200</field><field name=\"name_text\">111.111.1200</field></doc></add>"
Development is working fine. I thought it may be a corrupt test index so did:
$ rm -rf solr/data/test/
$ rm -rf solr/test/
That didn't help. Looking at the development admin page: http://localhost:8982/solr/#/ I don't see any warnings or errors.
When I go to the test admin page:
http://localhost:8981/solr/#/
SolrCore Initialization Failures
development: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Error opening new searcher
default: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Error opening new searcher
test: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Error opening new searcher
In the logs for the test admin site I see:
null:org.apache.solr.common.SolrException: SolrCore 'test' is not available due to init failure: Error opening new searcher
at org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:745)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:299)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.common.SolrException: Error opening new searcher
at org.apache.solr.core.SolrCore.<init>(SolrCore.java:873)
at org.apache.solr.core.SolrCore.<init>(SolrCore.java:646)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
... 1 more
Caused by: org.apache.solr.common.SolrException: Error opening new searcher
at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1565)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1677)
at org.apache.solr.core.SolrCore.<init>(SolrCore.java:845)
... 8 more
Caused by: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock#/Users/pramod/workspace/merlin/solr/test/data/index/write.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:89)
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:753)
at org.apache.solr.update.SolrIndexWriter.<init>(SolrIndexWriter.java:77)
at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:64)
at org.apache.solr.update.DefaultSolrCoreState.createMainIndexWriter(DefaultSolrCoreState.java:279)
at org.apache.solr.update.DefaultSolrCoreState.getIndexWriter(DefaultSolrCoreState.java:111)
at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1528)
... 10 more
So my best guess is that something is wrong with how the write locks are being created/deleted. I checked solr/conf/solrconfig.xml and I had the following (other stackoverflow posts seem to say this was necessary):
<unlockOnStartup>true</unlockOnStartup>
I also rebooting my computer. However, it's still not working. Any suggestions on how to fix this? Thanks!
System info:
Mac OS X 10.11 El Capitan
Sunspot 2.2.0
ruby 2.2.2
rails 4.2.1
solr 4.10.2
I upgraded solr version from the default that comes with sunspot to 4.10.2 to match my production environment. This seems to be the action that screwed everything up.
------------PARTIAL WORKAROUND------------
In my solr/conf/solrconfig.xml I added the following:
<lockType>simple</lockType>
right above <unlockOnStartup>true</unlockOnStartup>
Restart the solr instance and it resolves the issue that time.
It seems that NativeFSLockFactory (the default that Solr uses) causes issues (http://wiki.apache.org/lucene-java/AvailableLockFactories)
However if I stop the Solr instance and then try to start it again, I get a different exception now:
Caused by: java.nio.file.NoSuchFileException: /solr/test/data/index/_5p.si
As a workaround I do
$ rm -rf solr/data/test/
$ rm -rf solr/test/
Whenever I close the solr instance or start it. That seems to solve the issue for now. I still don't understand what's going wrong.

Rails 3, JRuby and Warbler

I am trying to deploy a Rails 3 application on Tomcat 6.0.24. The JRuby version is 1.6.2 (ruby-1.8.7-p330) and Warbler is 1.3.0. I use bundler to handle the gem dependencies.
Checked the WEB-INF/lib folder and the following jars are present:
jruby-rack-1.0.9.jar
jruby-core-1.6.2.jar
jruby-stdlib-1.6.2.jar
But, however after the server starts, hitting the application results in the following exception:
javax.servlet.ServletException: Filter execution threw an exception
java.lang.NoClassDefFoundError: Could not initialize class com.kenai.jaffl.struct.Struct$Constants
com.kenai.jaffl.struct.Struct$Signed64.<init>(Struct.java:1074)
org.jruby.ext.posix.HeapStruct$Int64.<init>(HeapStruct.java:41)
org.jruby.ext.posix.LinuxHeapFileStat.<init>(LinuxHeapFileStat.java:35)
org.jruby.ext.posix.LinuxPOSIX.allocateStat(LinuxPOSIX.java:26)
org.jruby.ext.posix.LinuxPOSIX.stat(LinuxPOSIX.java:107)
org.jruby.ext.posix.LazyPOSIX.stat(LazyPOSIX.java:226)
org.jruby.RubyFileTest.directory_p(RubyFileTest.java:102)
org.jruby.RubyFileTest.directory_p(RubyFileTest.java:87)
org.jruby.RubyFileTest$FileTestFileMethods.directory_p(RubyFileTest.java:428)
org.jruby.RubyFileTest$FileTestFileMethods$s$1$0$directory_p.call(RubyFileTest$FileTestFileMethods$s$1$0$directory_p.gen:65535)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:282)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
org.jruby.ast.IfNode.interpret(IfNode.java:111)
org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104)
org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:75)
org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:147)
org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:163)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:262)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:105)
org.jruby.ast.CallNoArgNode.interpret(CallNoArgNode.java:63)
org.jruby.ast.IfNode.interpret(IfNode.java:117)
org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104)
org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:75)
org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:120)
org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:145)
org.jruby.runtime.callsite.SuperCallSite.cacheAndCall(SuperCallSite.java:286)
org.jruby.runtime.callsite.SuperCallSite.callBlock(SuperCallSite.java:70)
org.jruby.runtime.callsite.SuperCallSite.call(SuperCallSite.java:75)
org.jruby.ast.ZSuperNode.interpret(ZSuperNode.java:101)
org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104).....
Does that ring any bells?
[Answer Updated]: The issue was with the java implementation on the server. It was Open JDK. I switched it over to Sun Java 1.6.0_26 and everything started working :)
Not sure if this is a new bug or an old one. Consider googling the error or looking on http://bugs.jruby.org.
You might try setting -Djruby.native.enabled=false in the VM to use the pure-Java POSIX layer and avoid this error.
The issue was with the java implementation on the server. It was Open JDK. I switched it over to Sun Java 1.6.0_26 and everything started working

Resources