Couchbase Server

assert in flusher::step, unable to open database file

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 1.6.5
  • Fix Version/s: 2011-01-20
  • Component/s: couchbase-bucket
  • Security Level: Public
  • Labels:
    None
  • Environment:
    1.6.5-2
    centos 5.4 64 bit
    php tests

Description

I was only able to reproduce this with the php tests, however it did happen every time I ran them.

I did verify that the system worked fine before starting the php tests against it.

memcached log:
sqlite error: unable to open database file
sqlite error: unable to open database file
Exception in flusher loop: unknown database kv_2
memcached: flusher.cc:189: bool Flusher::step(Dispatcher&, TaskId): Assertion `false' failed.


Backtrace:
Thread 1 (process 19143):
#0 0x0000003e5f430265 in raise () from /lib64/libc.so.6
#1 0x0000003e5f431d10 in abort () from /lib64/libc.so.6
#2 0x0000003e5f4296e6 in __assert_fail () from /lib64/libc.so.6
#3 0x00002b4a54262525 in Flusher::step (this=<value optimized out>, d=<value optimized out>, tid=<value optimized out>) at flusher.cc:189
#4 0x00002b4a5426280e in FlusherStepper::callback (this=0x108de9c0, d=@0x10933000, t=<value optimized out>) at flusher.cc:23
#5 0x00002b4a5422a76f in Task::run (this=<value optimized out>, d=@0x10933000, t=<value optimized out>) at dispatcher.hh:133
#6 0x00002b4a542295d3 in Dispatcher::run (this=0x10933000) at dispatcher.cc:116
#7 0x00002b4a5422a003 in launch_dispatcher_thread (arg=0x4ac5) at dispatcher.cc:26
#8 0x0000003e600064a7 in start_thread () from /lib64/libpthread.so.0
#9 0x0000003e5f4d3c2d in clone () from /lib64/libc.so.6

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Chiyoung Seo added a comment -
Dustin, I don't exactly understand why this db open failure happened. As you know the reason for this issue, I assigned this bug back to you.
Show
Chiyoung Seo added a comment - Dustin, I don't exactly understand why this db open failure happened. As you know the reason for this issue, I assigned this bug back to you.
Hide
Permalink
Dustin Sallings added a comment -
I believe the issue is that we've got more than one connection now so we need to have a flush close *all* connections and then open them in a controlled manner.

If we don't do this with control, we'll have connections racing to either use or create tables concurrently. If we don't properly shut them all down, we'll have queries failing with schema-updated errors.

This is my initial thought, though I haven't looked into it very deeply. Does this make sense?
Show
Dustin Sallings added a comment - I believe the issue is that we've got more than one connection now so we need to have a flush close *all* connections and then open them in a controlled manner. If we don't do this with control, we'll have connections racing to either use or create tables concurrently. If we don't properly shut them all down, we'll have queries failing with schema-updated errors. This is my initial thought, though I haven't looked into it very deeply. Does this make sense?
Hide
Permalink
Chiyoung Seo added a comment -
Thanks Dustin for the useful comments. I think that make sense to me, and will work on it soon.
Show
Chiyoung Seo added a comment - Thanks Dustin for the useful comments. I think that make sense to me, and will work on it soon.
Hide
Permalink
Chiyoung Seo added a comment -
http://review.membase.org/4255
Show
Chiyoung Seo added a comment - http://review.membase.org/4255

People

  • Assignee:
    Chiyoung Seo
    Reporter:
    Keith Batten
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
4h
Original Estimate - 4h
Remaining:
4h
Remaining Estimate - 4h
Logged:
Not Specified
Time Spent - Not Specified