Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: 
 <CAH+CGsJ_Jy2c1gx8cUZZ8ROC3oW3jNSKZKtE1AUQhA+vZqEFmA@mail.gmail.com>
References: 
 <CADmm+KdDY40Bg8fzgQPu9sZChLtinRnYSfpmeMuJ24P8obrALQ@mail.gmail.com>
 <CAH+CGs++xwQ7XiC8uMr-qZ5k3vsy4c20LOM5Ouc=CYcbpsh0dg@mail.gmail.com>
 <CADmm+Ke9HMxjfqCpX=Dseu_D0NdVvxkFEzPcHdix1y=5Oy1QGw@mail.gmail.com>
 <CADmm+KeXLWiG7Fk_w=HoEdGroFt3iN_hPfabB7kxFEQ_ZxLCLA@mail.gmail.com>
 <CADmm+Kd=P5+rxcaPbbOLAd7LK0_VJny9WT+w6SPZhhLp4386fg@mail.gmail.com>
 <CAH+CGsJ_Jy2c1gx8cUZZ8ROC3oW3jNSKZKtE1AUQhA+vZqEFmA@mail.gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Tue, 9 Jun 2015 20:44:39 +0800
Message-ID: 
 <CADmm+Kd3esw01a+adjO-MZVo4d1fqg-Rq+nKgpSQCQXtLn+2MA@mail.gmail.com>
Subject: Re: [Elastic Search] exception on startup
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a113bb0d85e57170518152052

--001a113bb0d85e57170518152052
Content-Type: text/plain; charset=UTF-8

Yeah, and that is why I was putting it in a Config MODULE inside Infra
Layer... But Wait!! There is MORE !!!

  a. ES Config is in the Config Module

  b. On manipulation of that Configuration Entity Composite, the
StateNotificationConcern will locate all visible StateChangeListeners and
call them.

  c. The ElasticSearchIndexer implements this and must either reside inside
the Storage Module, with Visibility.module, or if it has its own Indexing
Module (my case), the StateNotication will see it... BAM.

So!! Either Indexer need to be Visibility.module and inside the Storage
Module, OR the Configuration needs to be in its own Layer below.


On Tue, Jun 9, 2015 at 8:18 PM, Jiri Jetmar <juergen.jetmar@gmail.com>
wrote:

> hmm.. I think it was because of the In-Memory EntityStore required for the
> configuration.. Thats the reason for the dedicated config module.. This
> chicken-egg issue..  at least when I remember correctly..
>
>
>
> 2015-06-09 14:13 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:
>
> > Ok, the reason is "found"... The most typical of problems...
> >
> > The Configuration object of the ES extension triggers the
> > StateChangeNotification back to the ElasticSearch extension, which isn't
> > ready to process it yet.
> >
> > Was this the reason why we always need a Configuration Layer, and a
> Config
> > Module in Infra can't be made work?
> >
> > Cheers
> >
> > On Tue, Jun 9, 2015 at 8:01 PM, Niclas Hedhman <niclas@hedhman.org>
> wrote:
> >
> > > That second one is probably a consequence of the first problem, as the
> > > client=null at passivation...
> > >
> > > On Tue, Jun 9, 2015 at 7:55 PM, Niclas Hedhman <niclas@hedhman.org>
> > wrote:
> > >
> > >>
> > >> Well, how can there be an existing Index the first time it is run?
> > >> Remember, I am not using ES directly, only that the ES extension
> > attaches
> > >> itself to the EntityStateListener notification...
> > >>
> > >> Just now, I go another problem, so I suspect that I am missing some
> > >> crucial setup/assembly part. Perhaps I just change to the RDF indexer
> > >> instead...
> > >>
> > >>
> > >> Caused by: java.lang.NullPointerException
> > >>     at
> > >>
> >
> org.qi4j.index.elasticsearch.ElasticSearchIndexer$Mixin.notifyChanges(ElasticSearchIndexer.java:105)
> > >>     at
> > >>
> >
> org.qi4j.spi.entitystore.StateChangeNotificationConcern$1.commit(StateChangeNotificationConcern.java:44)
> > >>     at
> > >>
> >
> org.qi4j.spi.entitystore.ConcurrentModificationCheckConcern$ConcurrentCheckingEntityStoreUnitOfWork$1.commit(ConcurrentModificationCheckConcern.java:117)
> > >>     at
> > >>
> >
> org.qi4j.api.configuration.Configuration$ConfigurationMixin.initializeConfigurationInstance(Configuration.java:281)
> > >>
> > >>
> > >> On Tue, Jun 9, 2015 at 7:42 PM, Jiri Jetmar <juergen.jetmar@gmail.com
> >
> > >> wrote:
> > >>
> > >>> Just a guess - it looks like that you are trying to create a index
> > with a
> > >>> name that is already existing.
> > >>>
> > >>> Possible solutions are :
> > >>>
> > >>> - check if the index is already created
> > >>> - delete the file-based storage (this approach is used in the unit
> > tests)
> > >>> - Use each time a new name
> > >>>
> > >>> What is the context of this "myapp" ?
> > >>>
> > >>> Cheers,
> > >>> jj
> > >>>
> > >>> 2015-06-09 13:23 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:
> > >>>
> > >>> > Paul (since you wrote this once upon a time),
> > >>> >
> > >>> > I get an exception every time the Elastic Search Extension is
> loaded,
> > >>> even
> > >>> > if I wipe the $HOME/Library/Application Support/myapp where it
> seems
> > >>> that
> > >>> > ES extension is using (oh, yeah I am using the file system store)
> > >>> >
> > >>> > Any ideas? Is it expected?
> > >>> >
> > >>> >
> > >>> > Caused by: org.elasticsearch.indices.IndexAlreadyExistsException:
> > >>> > [qi4j_index] already exists
> > >>> >     at
> > >>> >
> > >>> >
> > >>>
> >
> org.elasticsearch.cluster.metadata.MetaDataCreateIndexService.validateIndexName(MetaDataCreateIndexService.java:164)
> > >>> >     at
> > >>> >
> > >>> >
> > >>>
> >
> org.elasticsearch.cluster.metadata.MetaDataCreateIndexService.validate(MetaDataCreateIndexService.java:539)
> > >>> >     at
> > >>> >
> > >>> >
> > >>>
> >
> org.elasticsearch.cluster.metadata.MetaDataCreateIndexService.access$100(MetaDataCreateIndexService.java:89)
> > >>> >     at
> > >>> >
> > >>> >
> > >>>
> >
> org.elasticsearch.cluster.metadata.MetaDataCreateIndexService$2.execute(MetaDataCreateIndexService.java:229)
> > >>> >     at
> > >>> >
> > >>> >
> > >>>
> >
> org.elasticsearch.cluster.service.InternalClusterService$UpdateTask.run(InternalClusterService.java:328)
> > >>> >     at
> > >>> >
> > >>> >
> > >>>
> >
> org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedEsThreadPoolExecutor.java:153)
> > >>> >     at
> > >>> >
> > >>> >
> > >>>
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > >>> >     at
> > >>> >
> > >>> >
> > >>>
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > >>> >     ... 1 more
> > >>> >
> > >>> > Cheers
> > >>> > --
> > >>> > Niclas Hedhman, Software Developer
> > >>> > http://zest.apache.org - New Energy for Java
> > >>> >
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Niclas Hedhman, Software Developer
> > >> http://zest.apache.org - New Energy for Java
> > >>
> > >
> > >
> > >
> > > --
> > > Niclas Hedhman, Software Developer
> > > http://zest.apache.org - New Energy for Java
> > >
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://zest.apache.org - New Energy for Java
> >
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

--001a113bb0d85e57170518152052--