You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kirk Lund <kl...@apache.org> on 2016/12/21 17:28:35 UTC
snappy-java dependency version
I'm looking at gradle/dependency-versions.properties and I'm not sure the
snappy-java.version is correct:
snappy-java.version=0.4
0.4 would be a very old version. GemFire 8.x uses 1.0.4.1:
<property name="snappy.version" value="1.0.4.1"/>
<property name="snappy.jar.name" value="snappy-java-${snappy.version}.jar"/>
Anyone know why it would be set to 0.4 in Geode? Or is 0.4 some weird alias
for 1.0.4.1??
Thanks,
Kirk
Re: snappy-java dependency version
Posted by Kirk Lund <kl...@pivotal.io>.
Just to tie this thread up, use of SnappyCompressor (using org.iq80.snappy)
does work on Solaris:
gfsh>create region --type=REPLICATE --name=region1
--compressor=org.apache.geode.compression.SnappyCompressor
Member | Status
------- | --------------------------------------
server1 | Region "/region1" created on "server1"
And the resulting region seems to work fine.
-Kirk
On Wed, Dec 21, 2016 at 10:36 AM, Dan Smith <ds...@pivotal.io> wrote:
> We switched to org.iq80.snappy because that's a pure java implementation,
> as opposed to just a wrapper around the C++ implementation. See GEODE-1573
> <https://issues.apache.org/jira/browse/GEODE-1573> for some details.
>
> I'm kinda surprised it doesn't work on Solaris. We switched to the new
> version to avoid these sort of cross platform compatibility issues. How is
> it failing on Solaris?
>
> Here's the github page for this new snappy implementation:
> https://github.com/dain/snappy/
>
> -Dan
>
> On Wed, Dec 21, 2016 at 9:40 AM, Kirk Lund <kl...@apache.org> wrote:
>
> > More info: I'm looking at the snappy dependency in Apache Geode because a
> > user reported that SnappyCompressor in Apache 1.0.0-incubating doesn't
> work
> > on Solaris x86.
> >
> > Hmm, I see that Geode uses org.iq80.snappy (latest version is 0.4):
> >
> > org.iq80.snappy:snappy:0.4
> >
> > Previous versions of GemFire used org.xerial.snappy (latest version is
> > 1.1.2.6):
> >
> > org.xerial.snappy:snappy-java:1.0.4.1
> >
> > Additional questions:
> >
> > Do we know why we changed from org.xerial.snappy to org.iq80.snappy? Was
> > this change made because org.xerial.snappy is not compatible with Apache
> > licenses? And does this change the platforms that SnappyCompressor will
> > work on?
> >
> > Thanks,
> > Kirk
> >
> >
> > On Wed, Dec 21, 2016 at 9:28 AM, Kirk Lund <kl...@apache.org> wrote:
> >
> > > I'm looking at gradle/dependency-versions.properties and I'm not sure
> > the
> > > snappy-java.version is correct:
> > >
> > > snappy-java.version=0.4
> > >
> > > 0.4 would be a very old version. GemFire 8.x uses 1.0.4.1:
> > >
> > > <property name="snappy.version" value="1.0.4.1"/>
> > > <property name="snappy.jar.name" value="snappy-java-${snappy.
> > > version}.jar"/>
> > >
> > > Anyone know why it would be set to 0.4 in Geode? Or is 0.4 some weird
> > > alias for 1.0.4.1??
> > >
> > > Thanks,
> > > Kirk
> > >
> > >
> >
>
Re: snappy-java dependency version
Posted by Dan Smith <ds...@pivotal.io>.
We switched to org.iq80.snappy because that's a pure java implementation,
as opposed to just a wrapper around the C++ implementation. See GEODE-1573
<https://issues.apache.org/jira/browse/GEODE-1573> for some details.
I'm kinda surprised it doesn't work on Solaris. We switched to the new
version to avoid these sort of cross platform compatibility issues. How is
it failing on Solaris?
Here's the github page for this new snappy implementation:
https://github.com/dain/snappy/
-Dan
On Wed, Dec 21, 2016 at 9:40 AM, Kirk Lund <kl...@apache.org> wrote:
> More info: I'm looking at the snappy dependency in Apache Geode because a
> user reported that SnappyCompressor in Apache 1.0.0-incubating doesn't work
> on Solaris x86.
>
> Hmm, I see that Geode uses org.iq80.snappy (latest version is 0.4):
>
> org.iq80.snappy:snappy:0.4
>
> Previous versions of GemFire used org.xerial.snappy (latest version is
> 1.1.2.6):
>
> org.xerial.snappy:snappy-java:1.0.4.1
>
> Additional questions:
>
> Do we know why we changed from org.xerial.snappy to org.iq80.snappy? Was
> this change made because org.xerial.snappy is not compatible with Apache
> licenses? And does this change the platforms that SnappyCompressor will
> work on?
>
> Thanks,
> Kirk
>
>
> On Wed, Dec 21, 2016 at 9:28 AM, Kirk Lund <kl...@apache.org> wrote:
>
> > I'm looking at gradle/dependency-versions.properties and I'm not sure
> the
> > snappy-java.version is correct:
> >
> > snappy-java.version=0.4
> >
> > 0.4 would be a very old version. GemFire 8.x uses 1.0.4.1:
> >
> > <property name="snappy.version" value="1.0.4.1"/>
> > <property name="snappy.jar.name" value="snappy-java-${snappy.
> > version}.jar"/>
> >
> > Anyone know why it would be set to 0.4 in Geode? Or is 0.4 some weird
> > alias for 1.0.4.1??
> >
> > Thanks,
> > Kirk
> >
> >
>
Re: snappy-java dependency version
Posted by Kirk Lund <kl...@apache.org>.
More info: I'm looking at the snappy dependency in Apache Geode because a
user reported that SnappyCompressor in Apache 1.0.0-incubating doesn't work
on Solaris x86.
Hmm, I see that Geode uses org.iq80.snappy (latest version is 0.4):
org.iq80.snappy:snappy:0.4
Previous versions of GemFire used org.xerial.snappy (latest version is
1.1.2.6):
org.xerial.snappy:snappy-java:1.0.4.1
Additional questions:
Do we know why we changed from org.xerial.snappy to org.iq80.snappy? Was
this change made because org.xerial.snappy is not compatible with Apache
licenses? And does this change the platforms that SnappyCompressor will
work on?
Thanks,
Kirk
On Wed, Dec 21, 2016 at 9:28 AM, Kirk Lund <kl...@apache.org> wrote:
> I'm looking at gradle/dependency-versions.properties and I'm not sure the
> snappy-java.version is correct:
>
> snappy-java.version=0.4
>
> 0.4 would be a very old version. GemFire 8.x uses 1.0.4.1:
>
> <property name="snappy.version" value="1.0.4.1"/>
> <property name="snappy.jar.name" value="snappy-java-${snappy.
> version}.jar"/>
>
> Anyone know why it would be set to 0.4 in Geode? Or is 0.4 some weird
> alias for 1.0.4.1??
>
> Thanks,
> Kirk
>
>