Re: [bdbxml] DbXml::QueryPlanFunction::getUriArg unexpected throw.

Thanks John,

You guys rock...as always, great product, lives up to the sleepycat name 
i have grown to trust!

-tom

ps - i am just about to wrap up a project w/ a client in munich that is 
using bdb to store billions of financial/economic time-series for 
various uses including risk management, perfomance attribution, and 
various other research and back office needs.  bdb has scaled 
tremendously, and my next hope is that they will start using DB XML, via 
nxqd for various financial meta-data storage requirements( financial 
statements, etc ), as rdbms' have been too damn rigid for the varried, 
abnormal structure of the data...i'll be bugging you guys for a while to 
come.  I will be releasing the TimeSeries database (tsdb) project for 
all as part of the historic data project on sourceforge soon...its a 
fairly large body of work w/ pluggable persistence backends, w/ BDB 
being my recommended.  As i seg off of these projects, i'm going to give 
a strong push to buy commercial support...who should i contact to 
discuss this?

pps - one last thing, in tsdb time-series are blobbed and average 
20-40kbytes which always forces them into overflow pages.  Would it be 
any faster to use dup. keys and the bulk request where the avg dup count 
is 5K keys?  I have a preallocated buffer for reading, so there is only 
mem. allocation if the time-series is unusually large.  any advice is 
appreciated...thanks again.

John Snelson wrote:

> Hi Tom,
>
> I found and fixed this bug recently. The "#" characters are not valid 
> in a URI, but DB XML wasn't catching the exception that caused properly.
>
> The fix will be present in the next release,
>
> John
>
> Tom McCubbin wrote:
>
>> Ok, first let me preface this email: this report is slightly bogus 
>> from the 'unlikely to happen in the real world' category of bugs.  
>> However, in our unit tests, which continue to grow for nxqd we have 
>> experienced the following 'strange behavior'.
>>
>> Here's the synopsis in pseudo code:
>>
>> createContainer( 'db#824948458663#641948458648' );
>> query ( 'collection("db#824948458663#641948458648")//Node3' );
>>
>> This core dumps.  However, if the # signs are removed from the 
>> container name, all is well.
>>
>> Here is a back trace from gdb at the server side:
>>
>> #0  0xb7ff8402 in __kernel_vsyscall ()
>> #1  0x00a607d5 in raise () from /lib/tls/libc.so.6
>> #2  0x00a62149 in abort () from /lib/tls/libc.so.6
>> #3  0x009861db in __gnu_cxx::__verbose_terminate_handler () from 
>> /usr/lib/libstdc++.so.6
>> #4  0x00983ef1 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6
>> #5  0x00983f26 in std::terminate () from /usr/lib/libstdc++.so.6
>> #6  0x0098406f in __cxa_throw () from /usr/lib/libstdc++.so.6
>> #7  0xb790fac7 in DbXml::QueryPlanFunction::getUriArg (this=0x0, 
>> context=0x8a0c608) at XStr.hpp:24
>> #8  0xb7911bbb in DbXml::QueryPlanFunction::generateQueryPlan 
>> (this=0x8a1cb08, mgr=@0x8a0ca94, txn=0x0, qp=0x8a1cbb4,
>>    context=0x8a0c608) at QueryPlanFunction.cpp:143
>> #9  0xb7916a92 in DbXml::QueryPlanGenerator::generateRawQueryPlans 
>> (this=0x8a1bd80) at stl_iterator.h:614
>> #10 0xb791d106 in DbXml::QueryPlanGenerator::optimize 
>> (this=0x8a1bd80, query=0x8a1c390) at QueryPlanGenerator.cpp:200
>> #11 0xb7914605 in DbXml::Optimizer::startOptimize (this=0x8a1bd80, 
>> query=0x8a1c390) at Optimizer.cpp:45
>> #12 0xb786cb2b in DbXml::QueryExpression::init (this=0x8a0c9e0, 
>> txn=0x0) at scoped_ptr.hpp:64
>> #13 0xb786d6ae in DatabaseQueryExpression (this=0x8a0c9e0, 
>> query=@0x89e2370, context=@0xb753d2c0, txn=0x0)
>>    at QueryExpression.cpp:132
>> #14 0xb78b20f0 in DbXml::XmlManager::prepare (this=0x89d8338, 
>> xquery=@0x89e2370, context=@0xb753d2c0) at XmlManager.cpp:414
>> #15 0xb78b21d7 in DbXml::XmlManager::query (this=0x89d8338, 
>> xquery=@0x89e2370, context=@0xb753d2c0, flags=3075723776)
>>    at XmlManager.cpp:429
>> #16 0x08050c5b in org::nxqd::server::query (this=0xbfff54f0, 
>> query=0x89e2370, namespacePrefix=0x0, namespaceURI=0x0,
>>    result=@0xb753d350) at server.hpp:275
>> #17 0x08050f28 in nxqd__query (soap=0x0, query=0x89e2370, 
>> namespacePrefix=0x0, namespaceURI=0x0, result=@0xb753d350)
>>    at server.cpp:333
>> #18 0x080658e1 in soap_serve_nxqd__query (soap=0x89e2390) at 
>> soapServer.cpp:113
>> #19 0x08067111 in soap_serve_request (soap=0x89e2390) at 
>> soapServer.cpp:74
>> #20 0x08067371 in soap_serve (soap=0x89e2390) at soapServer.cpp:49
>> #21 0x0804e385 in org::nxqd::server::process_queue (this=0xbfff54f0, 
>> soap=0x89e2390) at server.cpp:555
>> #22 0x0804e3e9 in org::nxqd::server::process_queue (soap=0x89e2390) 
>> at server.cpp:529
>> #23 0x00c80341 in start_thread () from /lib/tls/libpthread.so.0
>> #24 0x00afffee in clone () from /lib/tls/libc.so.6
>>
>> Never mind that i haven't registered to catch unexpected throws for a 
>> clean shutdown - that's being added now :)
>>
>> thanks for a great product...hopefully we will be able to offer 
>> something to aid in a broader DB XML adoption!
>>
>> -tom mccubbin
>>
>>
>>
>> ------------------------------------------
>> To remove yourself from this list, send an
>> email to [email protected]
>>
>
>



------------------------------------------
To remove yourself from this list, send an
email to [email protected]