Hi Daniel,
Thank you for the detailed bug report. It's very important for us to fix
such problems.
Could you at least try the latest night build from the
http://www.modis.ispras.ru/FTPContent/sedna/development ? It's absolutely
stable and still lacks only documentation for CMake build system. You can
use either binaries or build Sedna from sources with something like this:
cd SEDNA_SRC
mkdir buildc
cd buildc
cmake ..
make
Please, let me know if you'll have problems.
Ivan Shcheklein,
Sedna Team
On Wed, Jun 16, 2010 at 11:12 PM, Daniel Ruoso <[email protected]> wrote:
> Hi,
>
> This is the kind of bug that is most annoying to me as a developer, so I
> know this is a very hard to identify report...
>
> Basically, I have two scenarios, Sedna frozen in both and the problem
> went away by doing it in a huge transaction instead of doing one atomic
> operation per transaction.
>
> Scenario 1:
>
> I have two collections, one with around 7k documents (each one with
> around 2 kb), and other with around 35k documents (each one with around
> 2kb as well). I have a batch process that uses this two collections as
> input, creating a third collection with a unified document (the first
> collection is "household information", the second is "personal
> informatino", the third unifies both as "family information"). The
> resulting collection will be around the same size as the first in number
> of documents, but the size in bytes will be about the sum (ok, a bit
> less, because the two first collections have digitilizing control data
> that we don't transfer here).
>
> If I begin and commit one transaction for each "family", sedna will at
> some point (about 3k iterations) freeze all connections and get to a
> dead-lock state that will only go away after restarting the governor
>
> If I, on the other hand, do all the 7k iterations into a single
> transaction, it works just fine all to the end.
>
> (it might be worth mentioning that as sedna doesn't provide a cursor
> API, I need to have one connection open for the reads and one for the
> writes).
>
> Scenario 2:
>
> The second scenario is about doing some data massage from the collection
> generated above (some of which can only be done once we have the above
> collection complete), so this involves reading from the third collection
> in one connection, have some additional queries for each iteration and
> then, finally, after modifying the data, saving the result in a fourth
> collection (I'm doing it incrementaly in order to have checkpoints for
> the data). The same issue arises, If I begin and commit the transaction
> in the writing connection for each iteration, it will freeze at some
> point around 3k transactions. Having it all in a single transaction
> seems to work fine.
>
> End of example...
>
> Well, this kind of bug sucks, because it's hard to reproduce it in a
> controlled environment and i'm not in the liberty to disclose the actual
> data, so... I'm saying this here in the hopes that it will give any hint
> on what might be causing the problem.
>
> daniel
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Sedna-discussion mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sedna-discussion
>
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Sedna-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sedna-discussion
