You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by st...@apache.org on 2007/02/07 18:21:02 UTC
svn commit: r504623 -
/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/SessionImpl.java
Author: stefan
Date: Wed Feb 7 09:21:01 2007
New Revision: 504623
URL: http://svn.apache.org/viewvc?view=rev&rev=504623
Log:
minor performance tweaking
Modified:
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/SessionImpl.java
Modified: jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/SessionImpl.java
URL: http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/SessionImpl.java?view=diff&rev=504623&r1=504622&r2=504623
==============================================================================
--- jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/SessionImpl.java (original)
+++ jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/SessionImpl.java Wed Feb 7 09:21:01 2007
@@ -432,12 +432,20 @@
*/
public Node getNodeByUUID(UUID uuid) throws ItemNotFoundException, RepositoryException {
NodeImpl node = getNodeById(new NodeId(uuid));
+ // since the uuid of a node is only exposed through jcr:uuid declared
+ // by mix:referenceable it's rather unlikely that a client can possibly
+ // know the internal uuid of a non-referenceable node; omitting the
+ // check for mix:referenceable seems therefore to be a reasonable
+ // compromise in order to improve performance.
+/*
if (node.isNodeType(QName.MIX_REFERENCEABLE)) {
return node;
} else {
// there is a node with that uuid but the node does not expose it
throw new ItemNotFoundException(uuid.toString());
}
+*/
+ return node;
}
/**
Re: svn commit: r504623 - /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/SessionImpl.java
Posted by Stefan Guggisberg <st...@gmail.com>.
On 2/8/07, Stefan Guggisberg <st...@gmail.com> wrote:
> On 2/7/07, Jukka Zitting <ju...@gmail.com> wrote:
> > Hi,
> >
> > On 2/7/07, stefan@apache.org <st...@apache.org> wrote:
> > > public Node getNodeByUUID(UUID uuid) throws ItemNotFoundException, RepositoryException {
> > > NodeImpl node = getNodeById(new NodeId(uuid));
> > > + // since the uuid of a node is only exposed through jcr:uuid declared
> > > + // by mix:referenceable it's rather unlikely that a client can possibly
> > > + // know the internal uuid of a non-referenceable node; omitting the
> > > + // check for mix:referenceable seems therefore to be a reasonable
> > > + // compromise in order to improve performance.
> > > +/*
> > > if (node.isNodeType(QName.MIX_REFERENCEABLE)) {
> > > return node;
> > > } else {
> > > // there is a node with that uuid but the node does not expose it
> > > throw new ItemNotFoundException(uuid.toString());
> > > }
> > > +*/
> > > + return node;
> > > }
> >
> > Sounds reasonable, but I'm not convinced that the performance gain is
> > noticeable enough to justify the change. What's the access pattern
> > we're trying to speed up?
>
> well, applications that make *heavy* use of Node.getNodeByUUID do
of course i meant Session.getNodeByUUID...
cheers
stefan
> benefit considerably as shown by our profiling data.
>
> cheers
> stefan
>
> >
> > BR,
> >
> > Jukka Zitting
> >
>
Configuring log4j from a URL
Posted by Tushar Vijay Apshankar <tu...@yahoo.com>.
Hi Developers,
We are using JackRabbit in one of our project.
We need to specify the logging configuration dynamically through a URL.
Currently JackRabbit does not support it. We looked into the LoggingServlet.java and want to modify the configure() method in following way(please see the highlighted code below) so that it starts supporting URL as well:
private void configure() throws ServletException {
// setup log4j
String log4jConfig = getServletConfig().getInitParameter(INIT_PARAM_LOG4J_CONFIG);
if (log4jConfig.startsWith("http://")) {
configureURL(log4jConfig);
return;
}
InputStream in = getServletContext().getResourceAsStream(log4jConfig);
......
......
......
}
/**
* Configures the log4j from a URL using the {@link DOMConfigurator}
* @param urlString
* @throws ServletException
*/
private void configureURL(String urlString) throws ServletException {
try {
DOMConfigurator.configure(new URL(urlString));
} catch (MalformedURLException e) {
throw new ServletException("Invalid URL: " + e.toString());
}
}
Can you advice how can we get this code checked in into the code-base?
Thanks and regards,
Tushar
---------------------------------
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
Configuring log4j from a URL
Posted by Tushar Vijay Apshankar <tu...@yahoo.com>.
Hi Developers,
We are using JackRabbit in one of our project.
We need to specify the logging configuration dynamically through a URL.
Currently JackRabbit does not support it. We looked into the LoggingServlet.java and want to modify the configure() method in following way(please see the highlighted code below) so that it starts supporting URL as well:
private void configure() throws ServletException {
// setup log4j
String log4jConfig = getServletConfig().getInitParameter(INIT_PARAM_LOG4J_CONFIG);
if (log4jConfig.startsWith("http://")) {
configureURL(log4jConfig);
return;
}
InputStream in = getServletContext().getResourceAsStream(log4jConfig);
......
......
......
}
/**
* Configures the log4j from a URL using the {@link DOMConfigurator}
* @param urlString
* @throws ServletException
*/
private void configureURL(String urlString) throws ServletException {
try {
DOMConfigurator.configure(new URL(urlString));
} catch (MalformedURLException e) {
throw new ServletException("Invalid URL: " + e.toString());
}
}
Can you advice how can we get this code checked in into the code-base?
Thanks and regards,
Tushar
Jukka Zitting <ju...@gmail.com> wrote: Hi,
On 2/8/07, Stefan Guggisberg wrote:
> On 2/7/07, Jukka Zitting wrote:
> > Sounds reasonable, but I'm not convinced that the performance gain is
> > noticeable enough to justify the change. What's the access pattern
> > we're trying to speed up?
>
> well, applications that make *heavy* use of Node.getNodeByUUID do
> benefit considerably as shown by our profiling data.
My assumption is that the isNodeType() call should be pretty fast
since the NodeState with the type information has already been loaded.
Perhaps there's a performance issue with the EffectiveNodeType
handling?
I would assume that an application that uses getNodeByUUID() will also
do something with the returned Node. This change obviously speeds up
the getNodeByUUID() method call especially if the NodeState is already
cached, but is the speedup big enough to have a noticeable effect on
any composite operation? Intuitively I'd assume isNodeType() to be
faster than things like getNode() or getProperty(). If this assumption
is true, then removing the call would only have a marginal effect on
the overall performance.
BR,
Jukka Zitting
---------------------------------
Don't get soaked. Take a quick peak at the forecast
with theYahoo! Search weather shortcut.
Re: svn commit: r504623 - /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/SessionImpl.java
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 2/8/07, Stefan Guggisberg <st...@gmail.com> wrote:
> On 2/7/07, Jukka Zitting <ju...@gmail.com> wrote:
> > Sounds reasonable, but I'm not convinced that the performance gain is
> > noticeable enough to justify the change. What's the access pattern
> > we're trying to speed up?
>
> well, applications that make *heavy* use of Node.getNodeByUUID do
> benefit considerably as shown by our profiling data.
My assumption is that the isNodeType() call should be pretty fast
since the NodeState with the type information has already been loaded.
Perhaps there's a performance issue with the EffectiveNodeType
handling?
I would assume that an application that uses getNodeByUUID() will also
do something with the returned Node. This change obviously speeds up
the getNodeByUUID() method call especially if the NodeState is already
cached, but is the speedup big enough to have a noticeable effect on
any composite operation? Intuitively I'd assume isNodeType() to be
faster than things like getNode() or getProperty(). If this assumption
is true, then removing the call would only have a marginal effect on
the overall performance.
BR,
Jukka Zitting
Re: svn commit: r504623 - /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/SessionImpl.java
Posted by Stefan Guggisberg <st...@gmail.com>.
On 2/7/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 2/7/07, stefan@apache.org <st...@apache.org> wrote:
> > public Node getNodeByUUID(UUID uuid) throws ItemNotFoundException, RepositoryException {
> > NodeImpl node = getNodeById(new NodeId(uuid));
> > + // since the uuid of a node is only exposed through jcr:uuid declared
> > + // by mix:referenceable it's rather unlikely that a client can possibly
> > + // know the internal uuid of a non-referenceable node; omitting the
> > + // check for mix:referenceable seems therefore to be a reasonable
> > + // compromise in order to improve performance.
> > +/*
> > if (node.isNodeType(QName.MIX_REFERENCEABLE)) {
> > return node;
> > } else {
> > // there is a node with that uuid but the node does not expose it
> > throw new ItemNotFoundException(uuid.toString());
> > }
> > +*/
> > + return node;
> > }
>
> Sounds reasonable, but I'm not convinced that the performance gain is
> noticeable enough to justify the change. What's the access pattern
> we're trying to speed up?
well, applications that make *heavy* use of Node.getNodeByUUID do
benefit considerably as shown by our profiling data.
cheers
stefan
>
> BR,
>
> Jukka Zitting
>
Re: svn commit: r504623 - /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/SessionImpl.java
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 2/7/07, stefan@apache.org <st...@apache.org> wrote:
> public Node getNodeByUUID(UUID uuid) throws ItemNotFoundException, RepositoryException {
> NodeImpl node = getNodeById(new NodeId(uuid));
> + // since the uuid of a node is only exposed through jcr:uuid declared
> + // by mix:referenceable it's rather unlikely that a client can possibly
> + // know the internal uuid of a non-referenceable node; omitting the
> + // check for mix:referenceable seems therefore to be a reasonable
> + // compromise in order to improve performance.
> +/*
> if (node.isNodeType(QName.MIX_REFERENCEABLE)) {
> return node;
> } else {
> // there is a node with that uuid but the node does not expose it
> throw new ItemNotFoundException(uuid.toString());
> }
> +*/
> + return node;
> }
Sounds reasonable, but I'm not convinced that the performance gain is
noticeable enough to justify the change. What's the access pattern
we're trying to speed up?
BR,
Jukka Zitting