jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francisco Carriedo Scher <fcarrie...@gmail.com>
Subject Re: Method to check healthy session?
Date Thu, 12 Apr 2012 10:14:00 GMT
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 <jukka.zitting@gmail.com>

> Hi,
>
> On Wed, Apr 11, 2012 at 10:19 PM, Francisco Carriedo Scher
> <fcarriedos@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message