Issue is closed. The thrift problem persists albeit in a bit different form now.
The stack trace is as usual:
(gdb) bt
#0 0x008c0402 in __kernel_vsyscall ()
#1 0x00219472 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib/tls/i686/nosegneg/libpthread.so.0
#2 0x084c69c2 in
boost::condition_variable_any::timed_wait<boost::unique_lock<boost::mutex>
> (this=0x9cea9f8, m...@0xbfba6ef0, wait_unt...@0xbfba6e90)
at /usr/local/include/boost/thread/pthread/condition_variable.hpp:110
#3 0x084c6abc in
boost::condition_variable_any::timed_wait<boost::unique_lock<boost::mutex>
> (this=0x9cea9f8, m...@0xbfba6ef0, wait_unt...@0xbfba6ee4)
at /usr/local/include/boost/thread/pthread/condition_variable.hpp:127
#4 0x084c6b31 in
Hypertable::TableMutatorCompletionCounter::wait_for_completion
(this=0x9cea9e0, tim...@0xbfba7148)
at
/home/mateusz/episcale-hypertable/src/cc/Hypertable/Lib/TableMutatorCompletionCounter.h:70
#5 0x084c0b04 in
Hypertable::TableMutatorScatterBuffer::wait_for_completion
(this=0x9cea990, tim...@0xbfba7148)
at
/home/mateusz/episcale-hypertable/src/cc/Hypertable/Lib/TableMutatorScatterBuffer.cc:262
#6 0x084ba444 in Hypertable::TableMutator::wait_for_previous_buffer
(this=0x9cea720, tim...@0xbfba7148)
at
/home/mateusz/episcale-hypertable/src/cc/Hypertable/Lib/TableMutator.cc:283
#7 0x084bc762 in Hypertable::TableMutator::flush (this=0x9cea720) at
/home/mateusz/episcale-hypertable/src/cc/Hypertable/Lib/TableMutator.cc:233
#8 0x08410c9c in
Hypertable::ThriftBroker::ServerHandler::flush_mutator
(this=0x9cd2fe8, mutator=164538144, tok...@0xbfba959c)
at
/home/mateusz/episcale-hypertable/src/cc/ThriftBroker/ThriftBroker.cc:1395
#9 0x084165da in
Hypertable::ThriftBroker::ServerHandler::close_mutator
(this=0x9cd2fe8, mutator=164538144, tok...@0xbfba959c, flush=true)
at
/home/mateusz/episcale-hypertable/src/cc/ThriftBroker/ThriftBroker.cc:1417
#10 0x0843cb06 in
Hypertable::ThriftGen::ClientServiceProcessor::process_close_mutator
(this=0x9cd1f38, seqid=0, iprot=0x9cd1428, oprot=0x9cd13c8)
at
/home/mateusz/episcale-hypertable/src/cc/ThriftBroker/gen-cpp/ClientService.cpp:7153
#11 0x08431a5c in
Hypertable::ThriftGen::ClientServiceProcessor::process_fn
(this=0x9cd1f38, iprot=0x9cd1428, oprot=0x9cd13c8, fna...@0xbfba9724,
seqid=0)
at
/home/mateusz/episcale-hypertable/src/cc/ThriftBroker/gen-cpp/ClientService.cpp:6708
#12 0x0845de17 in
Hypertable::ThriftGen::HqlServiceProcessor::process_fn
(this=0x9cd1f38, iprot=0x9cd1428, oprot=0x9cd13c8, fna...@0xbfba9724,
seqid=0)
at
/home/mateusz/episcale-hypertable/src/cc/ThriftBroker/gen-cpp/HqlService.cpp:582
#13 0x0845e4e5 in Hypertable::ThriftGen::HqlServiceProcessor::process
(this=0x9cd1f38, piprot={px = 0xbfba9780, pn = {pi_ = 0xbfba9778}},
poprot=
{px = 0xbfba9778, pn = {pi_ = 0x1}}) at
/home/mateusz/episcale-hypertable/src/cc/ThriftBroker/gen-cpp/HqlService.cpp:575
#14 0x0011b551 in apache::thrift::server::TConnection::transition
(this=0x9cd1150) at src/server/TNonblockingServer.cpp:303
#15 0x0011bd89 in apache::thrift::server::TConnection::workSocket
(this=0x9cd1150) at src/server/TNonblockingServer.cpp:147
#16 0x001215c5 in apache::thrift::server::TConnection::eventHandler
(fd=14, v=0x9cd1150) at src/server/TNonblockingServer.h:418
#17 0x0012c5dc in event_base_loop () from /usr/lib/libevent-1.3e.so.1
#18 0x0011a55b in apache::thrift::server::TNonblockingServer::serve
(this=0xbfba992c) at src/server/TNonblockingServer.cpp:747
#19 0x0839e647 in main (argc=Cannot access memory at address 0x0
) at /home/mateusz/episcale-hypertable/src/cc/ThriftBroker/ThriftBroker.cc:1818
(gdb) c
There's a significant delay before the Thrift continues but the
operation continues successfully as opposed to failing as it was
happening before the fix for KFS.
I'll be testing it a bit more later today.
Mateusz
On Tue, Jun 16, 2009 at 7:43 PM, Mateusz Berezecki<[email protected]> wrote:
> As a side note, I think it might also fix ThriftBroker problems...
>
> Mateusz
>
> On Tue, Jun 16, 2009 at 7:42 PM, Mateusz Berezecki<[email protected]> wrote:
>> Hi Doug,
>>
>> On Tue, Jun 16, 2009 at 7:38 PM, Doug Judd<[email protected]> wrote:
>>> Hi Mateusz,
>>>
>>> According to Sriram, this problem was fixed in revision 359 of the KFS
>>> code. Can you pull that revision and try it out? If it fixes the problem,
>>> go ahead and close out issue 302.
>>
>> Yup, I'm in the middle of doing just that :-)
>>
>> Mateusz
>>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Hypertable Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/hypertable-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
