You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Nitin Lamba <ni...@ampool.io> on 2016/02/19 22:48:22 UTC
Lucene function added by default
Hi,
While starting-up a new geode cluster, I see that a lucene function is registered even before any regions are created. Following are the simple steps to reproduce it:
./bin/gfsh
gfsh>start locator --name=Locator
gfsh>start server --name=Server1
gfsh>list functions
Member | Function
------- | ---------------------------------------------------------------------
Server1 | com.gemstone.gemfire.cache.lucene.internal.distributed.LuceneFunction
Is this expected/ necessary? I would expect such a function to be defined only when Lucene integration is intended to be used. Please advise if a JIRA should be opened for this.
Thanks,
Nitin
Re: Lucene function added by default
Posted by Jens Deppe <jd...@pivotal.io>.
At the very least we should be adding a manifest-only
<component>-dependencies.jar that can simply be added to the classpath.
--Jens
On Fri, Feb 19, 2016 at 3:57 PM, Dan Smith <ds...@pivotal.io> wrote:
> I do think we need to work on making geode more modular, and make some of
> these components easier to enable/disable.
>
> -Dan
>
> On Fri, Feb 19, 2016 at 3:49 PM, Dan Smith <ds...@pivotal.io> wrote:
>
> > I added GEODE-991 for the fact that LuceneFunction shows up in the list.
> >
> > I don't think hbase is currently being used. I'm mentioned that on
> > GEODE-818 that we need to get rid of that.
> >
> > -Dan
> >
> >
> > On Fri, Feb 19, 2016 at 3:08 PM, Anilkumar Gingade <ag...@pivotal.io>
> > wrote:
> >
> >> Its about usability and simplicity; the end users look at the product
> >> features and expects that to be in the downloaded
> >> product/artifacts...Separating out may be additional work for end
> user...
> >>
> >> -Anil.
> >>
> >>
> >> On Fri, Feb 19, 2016 at 2:30 PM, Nitin Lamba <ni...@ampool.io> wrote:
> >>
> >> > Hi Dan,
> >> >
> >> > I see - thanks for the detailed explanation!
> >> >
> >> > In the spirit of modularity and cleaner dependencies, the core should
> >> not
> >> > depend on any custom integrations on application (Spark, Redis,
> Lucene)
> >> or
> >> > storage side (HDFS, HBase?). I also see hbase jar within
> >> 'apache-geode/lib'
> >> > directory. Do you know what that is used for?
> >> >
> >> > To answer your question, such dependencies should ideally be pulled-in
> >> > only at runtime or better be configurable. Seems Zeppelin has a
> concept
> >> of
> >> > profiles that builds 'integration-specific' artifacts.
> >> >
> >> > I'm sure this is easier said than done but that's a starting view...
> >> >
> >> > Thanks,
> >> > Nitin
> >> >
> >> > ________________________________________
> >> > From: Dan Smith <ds...@pivotal.io>
> >> > Sent: Friday, February 19, 2016 2:09 PM
> >> > To: geode
> >> > Subject: Re: Lucene function added by default
> >> >
> >> > Hi Nitin,
> >> >
> >> > I think this is a bug that the function shows up in that list. We
> >> actually
> >> > have a lot of other internal functions that don't show up in that list
> >> > because they implement the "InternalEntity" marker interface. So this
> >> > function should probably implement that as well.
> >> >
> >> > There's another question this brings up, which is whether the lucene
> >> > integration and lucene jars should be added by default to the
> classpath
> >> > when you start a gemfire server. That I'm not as sure about. Thoughts?
> >> >
> >> > -Dan
> >> >
> >> > On Fri, Feb 19, 2016 at 1:48 PM, Nitin Lamba <ni...@ampool.io> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > >
> >> > > While starting-up a new geode cluster, I see that a lucene function
> is
> >> > > registered even before any regions are created. Following are the
> >> simple
> >> > > steps to reproduce it:
> >> > >
> >> > >
> >> > > ./bin/gfsh
> >> > >
> >> > > gfsh>start locator --name=Locator
> >> > >
> >> > > gfsh>start server --name=Server1
> >> > >
> >> > > gfsh>list functions
> >> > >
> >> > >
> >> > > Member | Function
> >> > >
> >> > > ------- |
> >> > >
> ---------------------------------------------------------------------
> >> > >
> >> > > Server1 |
> >> > >
> com.gemstone.gemfire.cache.lucene.internal.distributed.LuceneFunction
> >> > >
> >> > >
> >> > > Is this expected/ necessary? I would expect such a function to be
> >> defined
> >> > > only when Lucene integration is intended to be used. Please advise
> if
> >> a
> >> > > JIRA should be opened for this.
> >> > >
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Nitin
> >> > >
> >> > >
> >> > >
> >>
> >
> >
>
Re: Lucene function added by default
Posted by Dan Smith <ds...@pivotal.io>.
I do think we need to work on making geode more modular, and make some of
these components easier to enable/disable.
-Dan
On Fri, Feb 19, 2016 at 3:49 PM, Dan Smith <ds...@pivotal.io> wrote:
> I added GEODE-991 for the fact that LuceneFunction shows up in the list.
>
> I don't think hbase is currently being used. I'm mentioned that on
> GEODE-818 that we need to get rid of that.
>
> -Dan
>
>
> On Fri, Feb 19, 2016 at 3:08 PM, Anilkumar Gingade <ag...@pivotal.io>
> wrote:
>
>> Its about usability and simplicity; the end users look at the product
>> features and expects that to be in the downloaded
>> product/artifacts...Separating out may be additional work for end user...
>>
>> -Anil.
>>
>>
>> On Fri, Feb 19, 2016 at 2:30 PM, Nitin Lamba <ni...@ampool.io> wrote:
>>
>> > Hi Dan,
>> >
>> > I see - thanks for the detailed explanation!
>> >
>> > In the spirit of modularity and cleaner dependencies, the core should
>> not
>> > depend on any custom integrations on application (Spark, Redis, Lucene)
>> or
>> > storage side (HDFS, HBase?). I also see hbase jar within
>> 'apache-geode/lib'
>> > directory. Do you know what that is used for?
>> >
>> > To answer your question, such dependencies should ideally be pulled-in
>> > only at runtime or better be configurable. Seems Zeppelin has a concept
>> of
>> > profiles that builds 'integration-specific' artifacts.
>> >
>> > I'm sure this is easier said than done but that's a starting view...
>> >
>> > Thanks,
>> > Nitin
>> >
>> > ________________________________________
>> > From: Dan Smith <ds...@pivotal.io>
>> > Sent: Friday, February 19, 2016 2:09 PM
>> > To: geode
>> > Subject: Re: Lucene function added by default
>> >
>> > Hi Nitin,
>> >
>> > I think this is a bug that the function shows up in that list. We
>> actually
>> > have a lot of other internal functions that don't show up in that list
>> > because they implement the "InternalEntity" marker interface. So this
>> > function should probably implement that as well.
>> >
>> > There's another question this brings up, which is whether the lucene
>> > integration and lucene jars should be added by default to the classpath
>> > when you start a gemfire server. That I'm not as sure about. Thoughts?
>> >
>> > -Dan
>> >
>> > On Fri, Feb 19, 2016 at 1:48 PM, Nitin Lamba <ni...@ampool.io> wrote:
>> >
>> > > Hi,
>> > >
>> > >
>> > > While starting-up a new geode cluster, I see that a lucene function is
>> > > registered even before any regions are created. Following are the
>> simple
>> > > steps to reproduce it:
>> > >
>> > >
>> > > ./bin/gfsh
>> > >
>> > > gfsh>start locator --name=Locator
>> > >
>> > > gfsh>start server --name=Server1
>> > >
>> > > gfsh>list functions
>> > >
>> > >
>> > > Member | Function
>> > >
>> > > ------- |
>> > > ---------------------------------------------------------------------
>> > >
>> > > Server1 |
>> > > com.gemstone.gemfire.cache.lucene.internal.distributed.LuceneFunction
>> > >
>> > >
>> > > Is this expected/ necessary? I would expect such a function to be
>> defined
>> > > only when Lucene integration is intended to be used. Please advise if
>> a
>> > > JIRA should be opened for this.
>> > >
>> > >
>> > > Thanks,
>> > >
>> > > Nitin
>> > >
>> > >
>> > >
>>
>
>
Re: Lucene function added by default
Posted by Dan Smith <ds...@pivotal.io>.
I added GEODE-991 for the fact that LuceneFunction shows up in the list.
I don't think hbase is currently being used. I'm mentioned that on
GEODE-818 that we need to get rid of that.
-Dan
On Fri, Feb 19, 2016 at 3:08 PM, Anilkumar Gingade <ag...@pivotal.io>
wrote:
> Its about usability and simplicity; the end users look at the product
> features and expects that to be in the downloaded
> product/artifacts...Separating out may be additional work for end user...
>
> -Anil.
>
>
> On Fri, Feb 19, 2016 at 2:30 PM, Nitin Lamba <ni...@ampool.io> wrote:
>
> > Hi Dan,
> >
> > I see - thanks for the detailed explanation!
> >
> > In the spirit of modularity and cleaner dependencies, the core should not
> > depend on any custom integrations on application (Spark, Redis, Lucene)
> or
> > storage side (HDFS, HBase?). I also see hbase jar within
> 'apache-geode/lib'
> > directory. Do you know what that is used for?
> >
> > To answer your question, such dependencies should ideally be pulled-in
> > only at runtime or better be configurable. Seems Zeppelin has a concept
> of
> > profiles that builds 'integration-specific' artifacts.
> >
> > I'm sure this is easier said than done but that's a starting view...
> >
> > Thanks,
> > Nitin
> >
> > ________________________________________
> > From: Dan Smith <ds...@pivotal.io>
> > Sent: Friday, February 19, 2016 2:09 PM
> > To: geode
> > Subject: Re: Lucene function added by default
> >
> > Hi Nitin,
> >
> > I think this is a bug that the function shows up in that list. We
> actually
> > have a lot of other internal functions that don't show up in that list
> > because they implement the "InternalEntity" marker interface. So this
> > function should probably implement that as well.
> >
> > There's another question this brings up, which is whether the lucene
> > integration and lucene jars should be added by default to the classpath
> > when you start a gemfire server. That I'm not as sure about. Thoughts?
> >
> > -Dan
> >
> > On Fri, Feb 19, 2016 at 1:48 PM, Nitin Lamba <ni...@ampool.io> wrote:
> >
> > > Hi,
> > >
> > >
> > > While starting-up a new geode cluster, I see that a lucene function is
> > > registered even before any regions are created. Following are the
> simple
> > > steps to reproduce it:
> > >
> > >
> > > ./bin/gfsh
> > >
> > > gfsh>start locator --name=Locator
> > >
> > > gfsh>start server --name=Server1
> > >
> > > gfsh>list functions
> > >
> > >
> > > Member | Function
> > >
> > > ------- |
> > > ---------------------------------------------------------------------
> > >
> > > Server1 |
> > > com.gemstone.gemfire.cache.lucene.internal.distributed.LuceneFunction
> > >
> > >
> > > Is this expected/ necessary? I would expect such a function to be
> defined
> > > only when Lucene integration is intended to be used. Please advise if a
> > > JIRA should be opened for this.
> > >
> > >
> > > Thanks,
> > >
> > > Nitin
> > >
> > >
> > >
>
Re: Lucene function added by default
Posted by Anilkumar Gingade <ag...@pivotal.io>.
Its about usability and simplicity; the end users look at the product
features and expects that to be in the downloaded
product/artifacts...Separating out may be additional work for end user...
-Anil.
On Fri, Feb 19, 2016 at 2:30 PM, Nitin Lamba <ni...@ampool.io> wrote:
> Hi Dan,
>
> I see - thanks for the detailed explanation!
>
> In the spirit of modularity and cleaner dependencies, the core should not
> depend on any custom integrations on application (Spark, Redis, Lucene) or
> storage side (HDFS, HBase?). I also see hbase jar within 'apache-geode/lib'
> directory. Do you know what that is used for?
>
> To answer your question, such dependencies should ideally be pulled-in
> only at runtime or better be configurable. Seems Zeppelin has a concept of
> profiles that builds 'integration-specific' artifacts.
>
> I'm sure this is easier said than done but that's a starting view...
>
> Thanks,
> Nitin
>
> ________________________________________
> From: Dan Smith <ds...@pivotal.io>
> Sent: Friday, February 19, 2016 2:09 PM
> To: geode
> Subject: Re: Lucene function added by default
>
> Hi Nitin,
>
> I think this is a bug that the function shows up in that list. We actually
> have a lot of other internal functions that don't show up in that list
> because they implement the "InternalEntity" marker interface. So this
> function should probably implement that as well.
>
> There's another question this brings up, which is whether the lucene
> integration and lucene jars should be added by default to the classpath
> when you start a gemfire server. That I'm not as sure about. Thoughts?
>
> -Dan
>
> On Fri, Feb 19, 2016 at 1:48 PM, Nitin Lamba <ni...@ampool.io> wrote:
>
> > Hi,
> >
> >
> > While starting-up a new geode cluster, I see that a lucene function is
> > registered even before any regions are created. Following are the simple
> > steps to reproduce it:
> >
> >
> > ./bin/gfsh
> >
> > gfsh>start locator --name=Locator
> >
> > gfsh>start server --name=Server1
> >
> > gfsh>list functions
> >
> >
> > Member | Function
> >
> > ------- |
> > ---------------------------------------------------------------------
> >
> > Server1 |
> > com.gemstone.gemfire.cache.lucene.internal.distributed.LuceneFunction
> >
> >
> > Is this expected/ necessary? I would expect such a function to be defined
> > only when Lucene integration is intended to be used. Please advise if a
> > JIRA should be opened for this.
> >
> >
> > Thanks,
> >
> > Nitin
> >
> >
> >
Re: Lucene function added by default
Posted by Nitin Lamba <ni...@ampool.io>.
Hi Dan,
I see - thanks for the detailed explanation!
In the spirit of modularity and cleaner dependencies, the core should not depend on any custom integrations on application (Spark, Redis, Lucene) or storage side (HDFS, HBase?). I also see hbase jar within 'apache-geode/lib' directory. Do you know what that is used for?
To answer your question, such dependencies should ideally be pulled-in only at runtime or better be configurable. Seems Zeppelin has a concept of profiles that builds 'integration-specific' artifacts.
I'm sure this is easier said than done but that's a starting view...
Thanks,
Nitin
________________________________________
From: Dan Smith <ds...@pivotal.io>
Sent: Friday, February 19, 2016 2:09 PM
To: geode
Subject: Re: Lucene function added by default
Hi Nitin,
I think this is a bug that the function shows up in that list. We actually
have a lot of other internal functions that don't show up in that list
because they implement the "InternalEntity" marker interface. So this
function should probably implement that as well.
There's another question this brings up, which is whether the lucene
integration and lucene jars should be added by default to the classpath
when you start a gemfire server. That I'm not as sure about. Thoughts?
-Dan
On Fri, Feb 19, 2016 at 1:48 PM, Nitin Lamba <ni...@ampool.io> wrote:
> Hi,
>
>
> While starting-up a new geode cluster, I see that a lucene function is
> registered even before any regions are created. Following are the simple
> steps to reproduce it:
>
>
> ./bin/gfsh
>
> gfsh>start locator --name=Locator
>
> gfsh>start server --name=Server1
>
> gfsh>list functions
>
>
> Member | Function
>
> ------- |
> ---------------------------------------------------------------------
>
> Server1 |
> com.gemstone.gemfire.cache.lucene.internal.distributed.LuceneFunction
>
>
> Is this expected/ necessary? I would expect such a function to be defined
> only when Lucene integration is intended to be used. Please advise if a
> JIRA should be opened for this.
>
>
> Thanks,
>
> Nitin
>
>
>
Re: Lucene function added by default
Posted by Dan Smith <ds...@pivotal.io>.
Hi Nitin,
I think this is a bug that the function shows up in that list. We actually
have a lot of other internal functions that don't show up in that list
because they implement the "InternalEntity" marker interface. So this
function should probably implement that as well.
There's another question this brings up, which is whether the lucene
integration and lucene jars should be added by default to the classpath
when you start a gemfire server. That I'm not as sure about. Thoughts?
-Dan
On Fri, Feb 19, 2016 at 1:48 PM, Nitin Lamba <ni...@ampool.io> wrote:
> Hi,
>
>
> While starting-up a new geode cluster, I see that a lucene function is
> registered even before any regions are created. Following are the simple
> steps to reproduce it:
>
>
> ./bin/gfsh
>
> gfsh>start locator --name=Locator
>
> gfsh>start server --name=Server1
>
> gfsh>list functions
>
>
> Member | Function
>
> ------- |
> ---------------------------------------------------------------------
>
> Server1 |
> com.gemstone.gemfire.cache.lucene.internal.distributed.LuceneFunction
>
>
> Is this expected/ necessary? I would expect such a function to be defined
> only when Lucene integration is intended to be used. Please advise if a
> JIRA should be opened for this.
>
>
> Thanks,
>
> Nitin
>
>
>