In reality, the default embedded instance of Elasticsearch is just a separate WAR deployed to Wildfly. It's just there for convenience in the quickstart - not intended to go into production. In order to remove it, all you need to do is remove the apiman-es.war file from wildfly's deployments directory: [ewittman@host ~]$ cd ~/apiman-1.2.9.Final/wildfly- 10.1.0.Final/standalone/deployments/ [ewittman@host deployments]$ rm apiman-es.war Restart Wildfly, and you're done! :) -Eric On Tue, Mar 21, 2017 at 1:51 PM, Balu S <sbalu27(a)gmail.com&gt; wrote: > Hi Eric, > Thanks for your response. > > One question though. I have noticed that during the server startup, even > though we specify standalone ES instance running (port configured in > apiman.properties), the default embedded instance is anyway started as well. > > 2017-03-21 18:42:21,915 INFO [org.elasticsearch.http] (ServerService > Thread Pool -- 64) [Norrin Radd] bound_address {inet[/10.12.129.105:19201]}, > publish_address {inet[/1x.xx.xxx.1xx:19201]} > > http://localhost:19201/_nodes/?pretty -- works (shows apiman specific > cluster) > > http://localhost:19200/_nodes/?pretty -- works (shows application > cluster) > > So ultimately. there are two ES instances running. Although during the > actual operation It seems to use the standalone ES instance that is > mentioned in apiman.properties. But why does the need to start embedded > instance if there is already instance is running ? > > regards > Balu. > > > > > > > > On Fri, Mar 17, 2017 at 5:33 PM, Eric Wittmann <eric.wittmann(a)redhat.com&gt; > wrote: > >> Glad that you found an acceptable workaround. If anyone on this list is >> interested in identifying the list of incompatibilities between ES versions >> (so that we can upgrade support in apiman to the latest version) then we'd >> be happy to make those changes. >> >> As I'm sure everyone is already aware, the full apiman solution is now >> in maintenance-only mode. This means that major functionality will not be >> added (by us). However, with some community support for something like >> this, I think we would be able to make time for it. >> >> Please note that Marc (msavy) continues to actively work on the Gateway, >> with a focus on releasing (soon) a vert.x based version. So the project >> isn't entirely silent! :) >> >> -Eric >> >> >> On Fri, Mar 17, 2017 at 9:51 AM, Balu S <sbalu27(a)gmail.com&gt; wrote: >> >>> Ok, So option 3) is not straightforward. The build fails as there is >>> bunch of API incompatibility between 1.7 and 2.4 versions. Unless one >>> wiling to refactor the apiman-es source to use 2.4 API or may be latest 5.2. >>> >>> I have gone ahead with option 1 and used a separate ES instance running >>> with 2.4.4 (cannot go higher than this version due to incompatibility with >>> bundled ES API in apiman) version and it seems fine. Since I'm not worried >>> about the old indices, this looks like straightforward option. >>> >>> But if someone want to use old indices, then you may need to dig deeper >>> to re-index may be (?). >>> >>> regards >>> Balu >>> >>> On Thu, Mar 16, 2017 at 10:06 AM, Balu S <sbalu27(a)gmail.com&gt; wrote: >>> >>>> Hello, >>>> I'm trying to gather metrics (using Kibana tool) from the ES instance >>>> that is being used by apiman. But what I found is the ES instance that is >>>> bundled inside the apiman is 1.7.x version which seems to be too old for >>>> current trending tools to index upon. Of course we can use old versions of >>>> those tools, for ex. Kibana 4.1.x version to index and gather metrics. But >>>> the older version are limited in functionality and I would like to use the >>>> latest if possible. >>>> >>>> Hence I have following options. >>>> >>>> 1) Use separate ElasticSearch instance with latest versions and >>>> update apiman.properties to point to this instance. And with this new >>>> version instance, I can use the latest tools. >>>> >>>> Question : Do you think the ES API 1.7.x is compatible and write >>>> indices to ES database running in latest version ? >>>> >>>> 2) Migrate the ES indices to new versions. But the below article, >>>> clearly says that the ES version must be at least 2.4.x for smooth >>>> migration using their migration tool. >>>> >>>> https://www.elastic.co/guide/en/elasticsearch/reference/curr >>>> ent/reindex-upgrade.html >>>> >>>> 3) Upgrade bundled ES API 1.7.x to 5.2.x (latest version) or at least >>>> 2.4.x version >>>> >>>> >>>> I think it is practical to upgrade bundled ES version to 2.4.x at >>>> least (if not for latest 5.2.x) just to make it compatible for migrating >>>> indices easily. >>>> >>>> What are your thoughts? I'm happy to see any alternative options other >>>> than mentioned above. Thanks. >>>> >>>> regards >>>> Balu >>>> >>>> >>> >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> >>> >> >