From users-return-5943-archive-asf-public=cust-asf.ponee.io@isis.apache.org Thu Feb 1 08:39:24 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id C1C68180652 for ; Thu, 1 Feb 2018 08:39:24 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id B1D5A160C44; Thu, 1 Feb 2018 07:39:24 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 03F79160C26 for ; Thu, 1 Feb 2018 08:39:23 +0100 (CET) Received: (qmail 60342 invoked by uid 500); 1 Feb 2018 07:39:23 -0000 Mailing-List: contact users-help@isis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@isis.apache.org Delivered-To: mailing list users@isis.apache.org Received: (qmail 60330 invoked by uid 99); 1 Feb 2018 07:39:22 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Feb 2018 07:39:22 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 51331DEA9E for ; Thu, 1 Feb 2018 07:39:22 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.972] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id lPb8kQWSaLRu for ; Thu, 1 Feb 2018 07:39:21 +0000 (UTC) Received: from vie01a-dmta-pe03-2.mx.upcmail.net (vie01a-dmta-pe03-2.mx.upcmail.net [62.179.121.161]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 5C8B15FE18 for ; Thu, 1 Feb 2018 07:37:24 +0000 (UTC) Received: from [172.31.216.44] (helo=vie01a-pemc-psmtp-pe02) by vie01a-dmta-pe03.mx.upcmail.net with esmtp (Exim 4.88) (envelope-from ) id 1eh9Qs-0004WS-Lz for users@isis.apache.org; Thu, 01 Feb 2018 08:37:18 +0100 Received: from [192.168.0.4] ([84.114.31.41]) by vie01a-pemc-psmtp-pe02 with SMTP @ mailcloud.upcmail.net id 5KdC1x00h0tE6K001KdDU5; Thu, 01 Feb 2018 08:37:13 +0100 X-SourceIP: 84.114.31.41 To: users@isis.apache.org References: <5a72a005.c768240a.35f9e.5436@mx.google.com> Subject: Re: RE: Swagger / Apache Isis response batching From: Andi Huber Message-ID: Date: Thu, 1 Feb 2018 08:37:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5a72a005.c768240a.35f9e.5436@mx.google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Ok, thanks Nikhil, this sounds like an issue - worth investigating - to me. Clarification: Tanancy logic is handled by the 'security' module that's provided by the 'incode platform', which is not part of Isis 'core'. Just to let you know: It's unlikely, that I myself, will look into incode's source-code, but hopefully someone else will help out! Regards, Andi On 2018/02/01 05:05:08, Nikhil Dhamapurkar wrote: > Hi Andi,> > > I believe the issue should be easy to reproduce and gets elevated in an application which supports tenancy because when the object is going to be rendered for UI or sent to client it will pass through the implementation of interface ApplicationTenancyEvaluator which will need to read data from user or roles.> > > If you publish bulk insert requests 20-30 via swagger you will notice the data will get inserted in DB much ahead than the responses received on the client handler.> > I added small instrumentation in code with stop watch which had total time taken for the request /response, Time spent in tenancy checks , time spent in Menu calls in Apache ISIS but the total client time is much more than sum of tenancy + method call execution time.> > > Regards> > Nikhil> > > From: Andi Huber> > Sent: 31 January 2018 14:46> > To: users@isis.apache.org> > Subject: Re: Swagger / Apache Isis response batching> > > Hi Nikhil,> > > I guess there is no such option, but I might be wrong.> > > From my understanding, any request you send to Isis (and swagger), is> > processed within a transaction Likely you don't get a response unless> > this particular transaction has completed (either with success or not).= > > > Not sure if this applies to your use-case, but you might solve this by>= > reducing the number of records done per batch.> > > If you believe this is an issue with Isis, we could look into it, but> > would need more information on how to reproduce the issue.> > > regards, Andi> > > > On 2018/01/29 16:04:12, Nikhil Dhamapurkar >= > wrote:> > >> > > Hi,>> > >> > > We are persisting data in DB using isis / swagger URI around 5500> > records. I can see the inserts in Database are being done at acceptable= > > times; in a few milliseconds.>> > >> > > But I can see that swagger / apache isis is batching the responses an= d> > not sending them asap this delays the client from getting the response>= > back in time.>> > >> > > Since he response is not received the client in its next cycle send> > the same request, is there a property where I can disable this batching ?>> > >> > > I have tried adding c3p0 for connection pooling and cached tenancy> > changes ins some cases to gain performance improvement but its not> > helping much.>> > >> > >> > > Statistics :>> > > DB insert per record ~ 2ms.>> > > The response time seen in client increases ( maybe queued ?) =3D 30 s= ec> > and more for later inserts.>> > >> > > Regards>> > > Nikhil>> > >> > >> > > >