Guys, After some benchmarks we found that in most of the case compression at record level doesn't bring benefits, but the opposite. We suggest you to use:
-Dstorage.compressionMethod=nothing And in facts 2.0rc1 comes with this default setting. Lvc@ ᐧ On 28 August 2014 05:51, odbuser <[email protected]> wrote: > Hi, I too use OrientDB under OSGI (latest version of Equinox). I used > karaf on and off but moved to 3.1+. I ran into the same problems you had > and now I basically combine all orientdb jars into one jar and create a > manifest with all of the correct imports/exports since maintaining > individual orientdb jars between releases was a nightmare. This greatly > simplified things but I have to be careful of any package changes and > META-INF service file changes. > > I also got Spi-Fly to work so that the services load correctly even across > jars so you might want to look into that if you haven't already. > > I side stepped the snappy issue by not using it. I believe > -Dstorage.compressionMethod=gzip along with combining the jars to resolve > the service loading and/or package import/exports fixed the problem. I > left snappy as a separate jar but updated the manifest. After glancing at > it I believe the following manifest line in snappy caused an issue: > Export-Package: > org.xerial.snappy;uses:="org.osgi.framework";version="1.1.0.1" > That is fixed by simply removing ";version="1.1.0.1". That looks like a > bug in their manifest to me... > > I run on lots of different platforms now without an issue. After much > pain I think I figured most stuff out around release 1.7.3. I'm on 1.7.8 > now. > > > On Tuesday, August 26, 2014 4:06:47 PM UTC-4, amoore wrote: >> >> Well, upgrading has caused many more OSGi dependency issues that we >> haven't been able to solve. We are going to downgrade back to the 1.7rc2 >> version, as I think the solution of registering the graph functions will >> still work. >> >> Specifically, we are having trouble running 1.7.8 in apache karaf (2.3.2) >> because of the dependence on the org.xerial.snappy snappy-java library. We >> initially couldn't run on OSX without duplicating a file in the snappy >> library and re-packaging it. Then, it failed to run for the same reason on >> windows server 2012. >> >> We've tried configuring OrientDB to use 'nothing' and 'gzip' compression >> modes, as well as removing the org.xerial.snappy dependency from the >> orientdb-core library's manifest file. >> >> We had no luck running on windows with it, and I'm sort of wondering why >> the org.iq80.snappy version (which is a pure java port, and does not >> include specific platform compilations) isn't the one used by OrientDB? I >> can't switch to it because OrientDB's OSnappyCompression class specifically >> imports the org.xerial.snappy version. >> >> Not sure what help the ODB folks can give us at this point, but maybe the >> feedback is useful for future releases... >> >> Any other insights or help would be greatly appreciated, or else we'll be >> stuck on 1.7rc2 for a while until we find another option. >> >> Regards, >> >> Andrew >> > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
