[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: real world examples


We're evaluating Ozone for use in storing geospatial data for military
applications.

I've had similar experience with the server "crashing" - but with single thread.

By "crashing" I mean that it simply freezes - no exception and fails to exit.
It's happening in WizardStore.commitNameTable() when close() is called on
a LocalDatabase instance.  When a transaction is committed, commitNameTable()
appears to correctly write all id's and objects, then when close() is called, it
freezes
about half way through.

In my case its random - it will not necessarily occur at the same data twice in
a row.

Does anyone have any insight?

Roy Ladner
Naval Research Laboratory

Reason wrote:

> Annoyingly, it's one of those problems in which turning debugging on and off
> changes what actually happens. Oh well. In every case, the server freezes
> up; this happens in every run of the test code, even with randomizing of the
> order in which operations are performed by the threads. If debugging is on,
> the JVM crashes with a stack overflow. If debugging is off, things just
> freeze.
>
> Reason
>
> -----Original Message-----
> From: ozone-users-owner@ozone-db.org
> [mailto:ozone-users-owner@ozone-db.org]On Behalf Of Falko Braeutigam
> Sent: Monday, June 18, 2001 11:39 AM
> To: Reason; ozone-users@ozone-db.org
> Subject: RE: real world examples
>
>
>
> >
> > I'm having considerable difficulty producing a solution for a generic data
> > layer with Ozone that is stable under multithreading -- external
> > transactions kill me. Or rather, they crash the server for even simple
> > applications providing that the threads are following one another closely
> > enough.
>
> Hmmm... so there must be some kind of race condition inside the
> ExternalDatabase code.
>
> What does this mean "crash the server"? Do you have a stack trace or
> something?
> I never, under no circumstances, saw an ozone server actually "crash"
> (actually
> stop execution), with the exception of JVM crashes.
>
> ______________________________________________________________________
> Falko Braeutigam                              mailto:falko@smb-tec.com
> SMB GmbH                                        http://www.smb-tec.com