From user-return-22190-archive-asf-public=cust-asf.ponee.io@karaf.apache.org Thu Apr 30 23:44:10 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 1B194180630 for ; Fri, 1 May 2020 01:44:10 +0200 (CEST) Received: (qmail 79156 invoked by uid 500); 30 Apr 2020 23:44:09 -0000 Mailing-List: contact user-help@karaf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@karaf.apache.org Delivered-To: mailing list user@karaf.apache.org Received: (qmail 79140 invoked by uid 99); 30 Apr 2020 23:44:09 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Apr 2020 23:44:09 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 5DECF181443 for ; Thu, 30 Apr 2020 23:44:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.021 X-Spam-Level: *** X-Spam-Status: No, score=3.021 tagged_above=-999 required=6.31 tests=[KAM_DMARC_STATUS=0.01, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=3, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=disabled Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 7dDHleT4FcP8 for ; Thu, 30 Apr 2020 23:44:07 +0000 (UTC) Received-SPF: Permerror (mailfrom) identity=mailfrom; client-ip=209.17.115.42; helo=atl4mhob04.registeredsite.com; envelope-from=slewis@composent.com; receiver= Received: from atl4mhob04.registeredsite.com (unknown [209.17.115.42]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id 2C0E77D3FA for ; Thu, 30 Apr 2020 23:43:45 +0000 (UTC) Received: from mailpod.hostingplatform.com (atl4qobmail01pod5.registeredsite.com [10.30.71.94]) by atl4mhob04.registeredsite.com (8.14.4/8.14.4) with ESMTP id 03UNhZq4018683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 30 Apr 2020 19:43:35 -0400 Received: (qmail 25022 invoked by uid 0); 30 Apr 2020 23:43:35 -0000 X-TCPREMOTEIP: 97.115.0.167 X-Authenticated-UID: slewis@composent.com Received: from unknown (HELO ?192.168.1.127?) (slewis@composent.com@97.115.0.167) by 0 with ESMTPA; 30 Apr 2020 23:43:35 -0000 Subject: Re: Karaf as micro service container To: user@karaf.apache.org References: From: Scott Lewis Message-ID: <26a6a354-a177-c0dc-6ef8-b096ac2468e2@composent.com> Date: Thu, 30 Apr 2020 16:43:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Howdy, Apologies if I'm misinterpreting Mike's comments below as I was not able to attend this presentation (but will watch it when available). On 4/30/2020 2:20 PM, Mike Hummel wrote: > Hello, > > > > - A common topic for clustering is a common cache and locking. It's possible with hazelcast. But I was not able use hazelcasts caching service - lots of class loader issues. I was able to use ehcache (no locking) and redis for this features. It's a shame that specially 'java caching api' is not possible in OSGi using hazelcast. It's also not easy with ehcache but I found a workaround. [Scott] It seems possible to me that remote services could be useful for creating such a 'java caching api', and ECF has a distribution provider based upon hazelcast [1]...allowing a nice separation between 'caching api' (set of interacting osgi services), implementation (OSGi service impls) and distribution (Hazelcast and/or other distribution providers). > > > I found the presentation of Dimitry very helpful. I will try not to divide each service in a separate container. In this scenario it's also possible to share database entities in the same JVM engine - this will even boost the performance - instead of using it via rest all the time. > > Also interesting is the support of API gateways. For me a big problem is the service discovery. It's absolutely stupid to configure each service manually in the API gateway. A more comfortable way would be some kind of discovery. Karaf could automatically configure/update the gateway depending on the provided jax rs resources. WRT service discovery...remote services specifies service discovery using an arbitrary comm protocol, and ECF has a discovery provider based upon etcd [1], which is also used in Kubernetes I believe.�� With this etcd provider [2], I expect that creating a Kubernetes remote service publish/discovery would be straightforward. Scott [1] https://github.com/ECF/HazelcastProvider [2] https://github.com/ECF/etcd-provider