Return-Path: X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 60E779114 for ; Thu, 12 Apr 2012 10:14:56 +0000 (UTC) Received: (qmail 27024 invoked by uid 500); 12 Apr 2012 10:14:55 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 26835 invoked by uid 500); 12 Apr 2012 10:14:50 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 26788 invoked by uid 99); 12 Apr 2012 10:14:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Apr 2012 10:14:49 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of fcarriedos@gmail.com designates 209.85.160.170 as permitted sender) Received: from [209.85.160.170] (HELO mail-gy0-f170.google.com) (209.85.160.170) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Apr 2012 10:14:41 +0000 Received: by ghbg2 with SMTP id g2so1655431ghb.1 for ; Thu, 12 Apr 2012 03:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=hFFojecR5MIIt16nJQlPm4vwKenTJCIesaZr0QJivp8=; b=hFklQAPlIZeHAw8J4tkHuN6N/Vl9WPlxtywHl+GjFHgxbTS2IDi/LgHoFx1plYCxyA Z3dcB5ir881uyJNFwAILPB6q/shb9CkHv3/0T0T5M7ei/alzUjJ+bMjS6v7yXiTDsHW/ 7AUqNXNfjOj4ZU9Pa7IBnMzs4gjaNEshs4GygPymArtk91Sazznc8trngy3C6qSjjzbn /2S1OaaZcEh+32jmBW534ZmVl8SAN6MQcHILcKsI0WgXnc1KV7nHMZ+viluac/ulvFn8 k3DV5rKaopp6g7Oh52vLI/3PcWScOLpGMetFFLPmurMxXuVKYScrqL4BRew1QL7wjU5h YhCA== Received: by 10.236.116.104 with SMTP id f68mr1452441yhh.57.1334225660488; Thu, 12 Apr 2012 03:14:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.13.20 with HTTP; Thu, 12 Apr 2012 03:14:00 -0700 (PDT) Reply-To: fcarriedos@gmail.com In-Reply-To: References: From: Francisco Carriedo Scher Date: Thu, 12 Apr 2012 12:14:00 +0200 Message-ID: Subject: Re: Method to check healthy session? To: Jukka Zitting Cc: users@jackrabbit.apache.org Content-Type: multipart/alternative; boundary=20cf303bf89c8b2afd04bd789ee7 --20cf303bf89c8b2afd04bd789ee7 Content-Type: text/plain; charset=ISO-8859-1 Thank you very much Jukka, i will switch from save() to a dummy query to a fixed common node. Additionally, we have observed the network traffic during tests and two questions arised: - after testing session.refresh(false) doesn't "forget" about the pending changes, the only way we found to really forget is to re-obtain the repository object each time. The issue on this is that happened that some operations got stuck (cached?) and the new ones could not be completed, as the old ones (those stuck) raised exceptions (i.e.: creating a new node, implied trying to perform previously another operations that failed. That is what i mean with enqueing. - based on what is stated above (getting a new session on every operation) both a complete list of the sons of the root node and a complete description of the node types (some KBs, easy to deal with) is transferred (about 100KB). The second one is what really matters, because we are expecting to receive a heavy load. The first idea is to delete all the nodes but the necessary ones (nt:base, nt:folder, nt:files...), then the XML will be lighter. Is there a better solution for this?. Thank you very much for your attention! Regards! 2012/4/11 Jukka Zitting > Hi, > > On Wed, Apr 11, 2012 at 10:19 PM, Francisco Carriedo Scher > wrote: > > i was talking about the Webdav one. The scenario is the following: > > > > 1) The repository is deployed and running within a JBoss 7 AS > > 2) There are client sessions operating it through Webdav > > 3) Suddenly the repository is undeployed (or the server shutdown) > > 4) The session.isLive() and session.refresh(true) methods return true > (and > > no exception arises) despite the repository being not accessible anymore > > > > Anyway, session.save() method does effectively throw an exception and > then > > re-obtaining the repository object and the session can be performed, but > > under heavy load that leads to lots of TCP connections in TIME_WAIT > state... > > OK, I see. > > I think ideally we should have Session.isLive() or Session.refresh() > ping the server for status, but I guess the current implementation > doesn't do that to avoid extra network roundtrips. Doing something > like a dummy query should force a network roundtrip regardless of the > caching layers without having to use a potentially unsafe operation > like save(). > > > Is there a better way to check the repository to be up and getting a new > > session if needed? > > Do you really need long-living sessions? If you rather organize your > client so that each separate operation (think of individual HTTP > requests to a web application) uses a new, separate JCR session, then > you don't need to worry about sessions becoming stale. > > BR, > > Jukka Zitting > --20cf303bf89c8b2afd04bd789ee7--