You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Unico Hommes <un...@hippo.nl> on 2004/11/19 16:25:12 UTC
Unreleased database connections reading namespace
Hi guys,
I am struggling with a dead lock due to JDBC connections that don't
seems to get released. I did a very simple test where I iterate over all
nodes in the database and read their contents:
Iterator uris = new StructureIterator();
while(uris.hasNext()) {
String uri = (String) uris.next();
try {
final NodeRevisionDescriptors descriptors =
m_content.retrieve(m_token, uri);
final NodeRevisionDescriptor descriptor =
m_content.retrieve(m_token, descriptors);
final NodeRevisionContent content = m_content.retrieve(m_token,
descriptors, descriptor);
[snip stuff]
}
catch (SlideException e) {
System.err.println(e);
}
}
/**
* Iterates over all nodes within a Namespace
*/
class StructureIterator implements Iterator {
private final ArrayStack m_stack = new ArrayStack();
StructureIterator() {
m_stack.push(m_structure.retrieve(m_token, "/"));
}
public boolean hasNext() {
return !m_stack.empty();
}
public Object next() {
if (!hasNext()) {
throw new NoSuchElementException();
}
final ObjectNode node = (ObjectNode) m_stack.pop();
traverse(node);
return node.getUri();
}
private void traverse(ObjectNode node) {
try {
m_stack.addAll(Collections.list(m_structure.getChildren(m_token, node)));
}
catch (SlideException e) {
m_logger.error("Error iterating through repository", e);
}
}
}
It looks like each iteration "eats" a database connection. Probably it
is something I am doing wrong using the Slide API but this used to work.
Thoughts?
--
Unico
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Unreleased database connections reading namespace
Posted by Oliver Zeigermann <ol...@gmail.com>.
A close method for NodeRevisionContent sounds most reasonable for me.
Should be very easy to implement and would be backward compatible...
Oliver
On Fri, 19 Nov 2004 18:07:28 +0100, Unico Hommes <un...@hippo.nl> wrote:
> Perhaps the API would have been clearer without the NodeRevisionContent
> object and instead of Content.retrieve() we would have
> Content.retrieveAsBytes(), Content.retrieveAsStream(),
> Content.retrieveAsReader(). But I am not sure it is worth to change it.
> Another option is to add a close() method to NodeRevisionContent. Hmm.
>
> --
> Unico
>
>
>
> Oliver Zeigermann wrote:
>
> >Ah, this makes it clear!
> >
> >I know it is really not obvious that you have to close a stream you do
> >not even touch, but there really is no better solution I am afraid :(
> >
> >Same thing with the tx file store...
> >
> >Oliver
> >
> >On Fri, 19 Nov 2004 17:51:23 +0100, Unico Hommes <un...@hippo.nl> wrote:
> >
> >
> >>OK, I see now. It doesn't matter if you actually decide to use the
> >>NodeRevisionContent object. Once you retrieve it from the Content helper
> >>the stream must somehow be closed. I was conditionally using it and so
> >>connections were left open.
> >>
> >>Anyway, thanks again Oliver, you saved my day :-)
> >>
> >>--
> >>Unico
> >>
> >>
> >>
> >>Unico Hommes wrote:
> >>
> >>
> >>
> >>>Dude it worked! Thanks!
> >>>
> >>>I am reading the NodeRevisionContent like so:
> >>>
> >>>InputStream in = null;
> >>>try {
> >>> in = new ByteArrayInputStream(content.getContentBytes());
> >>>}
> >>>finally {
> >>> in.close();
> >>>}
> >>>
> >>>Perhaps something goes wrong during
> >>>NodeRevisionContent.getContentBytes() ? But it looks like that method
> >>>correctly closes the InputStream though.
> >>>
> >>>--
> >>>Unico
> >>>
> >>>Oliver Zeigermann wrote:
> >>>
> >>>
> >>>
> >>>>If you are not using compressed there will be an input stream in
> >>>>content that is the one from the JDBC driver and *must* be closed to
> >>>>close the connection. Try enabling compression if not already done and
> >>>>see if this changes anything.
> >>>>
> >>>>Oliver
> >>>>
> >>>>
> >>>>
> >>>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Unreleased database connections reading namespace
Posted by Unico Hommes <un...@hippo.nl>.
Perhaps the API would have been clearer without the NodeRevisionContent
object and instead of Content.retrieve() we would have
Content.retrieveAsBytes(), Content.retrieveAsStream(),
Content.retrieveAsReader(). But I am not sure it is worth to change it.
Another option is to add a close() method to NodeRevisionContent. Hmm.
--
Unico
Oliver Zeigermann wrote:
>Ah, this makes it clear!
>
>I know it is really not obvious that you have to close a stream you do
>not even touch, but there really is no better solution I am afraid :(
>
>Same thing with the tx file store...
>
>Oliver
>
>On Fri, 19 Nov 2004 17:51:23 +0100, Unico Hommes <un...@hippo.nl> wrote:
>
>
>>OK, I see now. It doesn't matter if you actually decide to use the
>>NodeRevisionContent object. Once you retrieve it from the Content helper
>>the stream must somehow be closed. I was conditionally using it and so
>>connections were left open.
>>
>>Anyway, thanks again Oliver, you saved my day :-)
>>
>>--
>>Unico
>>
>>
>>
>>Unico Hommes wrote:
>>
>>
>>
>>>Dude it worked! Thanks!
>>>
>>>I am reading the NodeRevisionContent like so:
>>>
>>>InputStream in = null;
>>>try {
>>> in = new ByteArrayInputStream(content.getContentBytes());
>>>}
>>>finally {
>>> in.close();
>>>}
>>>
>>>Perhaps something goes wrong during
>>>NodeRevisionContent.getContentBytes() ? But it looks like that method
>>>correctly closes the InputStream though.
>>>
>>>--
>>>Unico
>>>
>>>Oliver Zeigermann wrote:
>>>
>>>
>>>
>>>>If you are not using compressed there will be an input stream in
>>>>content that is the one from the JDBC driver and *must* be closed to
>>>>close the connection. Try enabling compression if not already done and
>>>>see if this changes anything.
>>>>
>>>>Oliver
>>>>
>>>>
>>>>
>>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Fwd: Unreleased database connections reading namespace
Posted by Oliver Zeigermann <ol...@gmail.com>.
Its not James' fault, my gmail account seems to mess up the reply-to
adress. If have seen this with other accounts as well, so it seems to
be a general gmail problem. Hopefully, it is fixed soon.
Oliver
On Mon, 22 Nov 2004 09:04:35 -0800, James Mason <ma...@apache.org> wrote:
> The button is fine, it's the user that's broken.
>
> Sometimes I forget to change the To: address when replying to Oliver's
> emails. I'm getting better, though :).
>
> -James
>
>
>
> On Mon, 2004-11-22 at 14:24 +0100, Unico Hommes wrote:
> > Hi James,
> >
> > Reply button broken? ;-)
> >
> > I prefer your solution to adding a close method NodeRevisionContent.
> > Because close would only be functional in a very small number of cases.
> > During normal useage - using the input stream (and closing it), or
> > getting the byte array - calling close would be superfluous. Another
> > possible solution is to subclass NodeRevisionContent and lazy-initialize
> > the input stream whenever it is used. This probably would need a change
> > to RDBMSAdapter interface (retrieveRevisionContent should return an
> > InputStream instead of NodeRevisionContent) and some changes to
> > NodeRevisionContent. WDYT?
> >
> > --
> > Unico
> >
> >
> > Oliver Zeigermann wrote:
> >
> > >---------- Forwarded message ----------
> > >From: James Mason <ma...@apache.org>
> > >Date: Fri, 19 Nov 2004 19:41:24 -0800
> > >Subject: Re: Unreleased database connections reading namespace
> > >To: ozeigermann@apache.org
> > >
> > >
> > >How about adding this to the javadoc for ContentHelper.retrieve() and
> > >NodeRevisionContent?
> > >
> > >-James
> > >
> > >
> > >
> > >On Fri, 2004-11-19 at 17:54 +0100, Oliver Zeigermann wrote:
> > >
> > >
> > >>Ah, this makes it clear!
> > >>
> > >>I know it is really not obvious that you have to close a stream you do
> > >>not even touch, but there really is no better solution I am afraid :(
> > >>
> > >>Same thing with the tx file store...
> > >>
> > >>Oliver
> > >>
> > >>On Fri, 19 Nov 2004 17:51:23 +0100, Unico Hommes <un...@hippo.nl> wrote:
> > >>
> > >>
> > >>>OK, I see now. It doesn't matter if you actually decide to use the
> > >>>NodeRevisionContent object. Once you retrieve it from the Content helper
> > >>>the stream must somehow be closed. I was conditionally using it and so
> > >>>connections were left open.
> > >>>
> > >>>Anyway, thanks again Oliver, you saved my day :-)
> > >>>
> > >>>--
> > >>>Unico
> > >>>
> > >>>
> > >>>
> > >>>Unico Hommes wrote:
> > >>>
> > >>>
> > >>>
> > >>>>Dude it worked! Thanks!
> > >>>>
> > >>>>I am reading the NodeRevisionContent like so:
> > >>>>
> > >>>>InputStream in = null;
> > >>>>try {
> > >>>> in = new ByteArrayInputStream(content.getContentBytes());
> > >>>>}
> > >>>>finally {
> > >>>> in.close();
> > >>>>}
> > >>>>
> > >>>>Perhaps something goes wrong during
> > >>>>NodeRevisionContent.getContentBytes() ? But it looks like that method
> > >>>>correctly closes the InputStream though.
> > >>>>
> > >>>>--
> > >>>>Unico
> > >>>>
> > >>>>Oliver Zeigermann wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>>If you are not using compressed there will be an input stream in
> > >>>>>content that is the one from the JDBC driver and *must* be closed to
> > >>>>>close the connection. Try enabling compression if not already done and
> > >>>>>see if this changes anything.
> > >>>>>
> > >>>>>Oliver
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>---------------------------------------------------------------------
> > >>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > >>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> > >>>
> > >>>
> > >>>
> > >>>
> > >>---------------------------------------------------------------------
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> > >>
> > >>
> > >>
> > >>
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Fwd: Unreleased database connections reading namespace
Posted by Unico Hommes <un...@hippo.nl>.
Hmm I see. Looking at Olivers mail headers I see two Reply-To headers.
The first is to slide-dev the other is to his gmail account. I guess he
is using the gmail option that allows you to set a custom reply-to
address. Whereas my mail client (thunderbird) seems to pick up the first
header value yours does the latter. Not sure if that is a bug though.
--
Unico
James Mason wrote:
>Most email is fine, but for some reason email coming from gmail.com has
>the Reply-To address set to the user rather than the mailing list. I
>don't know if the problem is with gmail, the mailing list or my client
>(I'm using Evolution 2), but it's a little annoying.
>
>-James
>
>On Mon, 2004-11-22 at 18:11 +0100, Unico Hommes wrote:
>
>
>>But if I reply to an email from Oliver - or from any mail that was sent
>>to slide-dev for that matter - it says slide-dev@jakarta.apache.org in
>>the to: field. Not with you?
>>
>>--
>>Unico
>>
>>James Mason wrote:
>>
>>
>>
>>>The button is fine, it's the user that's broken.
>>>
>>>Sometimes I forget to change the To: address when replying to Oliver's
>>>emails. I'm getting better, though :).
>>>
>>>-James
>>>
>>>On Mon, 2004-11-22 at 14:24 +0100, Unico Hommes wrote:
>>>
>>>
>>>
>>>
>>>>Hi James,
>>>>
>>>>Reply button broken? ;-)
>>>>
>>>>
>>>>
>>>>
>>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Fwd: Unreleased database connections reading namespace
Posted by James Mason <ma...@apache.org>.
Most email is fine, but for some reason email coming from gmail.com has
the Reply-To address set to the user rather than the mailing list. I
don't know if the problem is with gmail, the mailing list or my client
(I'm using Evolution 2), but it's a little annoying.
-James
On Mon, 2004-11-22 at 18:11 +0100, Unico Hommes wrote:
> But if I reply to an email from Oliver - or from any mail that was sent
> to slide-dev for that matter - it says slide-dev@jakarta.apache.org in
> the to: field. Not with you?
>
> --
> Unico
>
> James Mason wrote:
>
> >The button is fine, it's the user that's broken.
> >
> >Sometimes I forget to change the To: address when replying to Oliver's
> >emails. I'm getting better, though :).
> >
> >-James
> >
> >On Mon, 2004-11-22 at 14:24 +0100, Unico Hommes wrote:
> >
> >
> >>Hi James,
> >>
> >>Reply button broken? ;-)
> >>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Fwd: Unreleased database connections reading namespace
Posted by Unico Hommes <un...@hippo.nl>.
But if I reply to an email from Oliver - or from any mail that was sent
to slide-dev for that matter - it says slide-dev@jakarta.apache.org in
the to: field. Not with you?
--
Unico
James Mason wrote:
>The button is fine, it's the user that's broken.
>
>Sometimes I forget to change the To: address when replying to Oliver's
>emails. I'm getting better, though :).
>
>-James
>
>On Mon, 2004-11-22 at 14:24 +0100, Unico Hommes wrote:
>
>
>>Hi James,
>>
>>Reply button broken? ;-)
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Fwd: Unreleased database connections reading namespace
Posted by James Mason <ma...@apache.org>.
The button is fine, it's the user that's broken.
Sometimes I forget to change the To: address when replying to Oliver's
emails. I'm getting better, though :).
-James
On Mon, 2004-11-22 at 14:24 +0100, Unico Hommes wrote:
> Hi James,
>
> Reply button broken? ;-)
>
> I prefer your solution to adding a close method NodeRevisionContent.
> Because close would only be functional in a very small number of cases.
> During normal useage - using the input stream (and closing it), or
> getting the byte array - calling close would be superfluous. Another
> possible solution is to subclass NodeRevisionContent and lazy-initialize
> the input stream whenever it is used. This probably would need a change
> to RDBMSAdapter interface (retrieveRevisionContent should return an
> InputStream instead of NodeRevisionContent) and some changes to
> NodeRevisionContent. WDYT?
>
> --
> Unico
>
>
> Oliver Zeigermann wrote:
>
> >---------- Forwarded message ----------
> >From: James Mason <ma...@apache.org>
> >Date: Fri, 19 Nov 2004 19:41:24 -0800
> >Subject: Re: Unreleased database connections reading namespace
> >To: ozeigermann@apache.org
> >
> >
> >How about adding this to the javadoc for ContentHelper.retrieve() and
> >NodeRevisionContent?
> >
> >-James
> >
> >
> >
> >On Fri, 2004-11-19 at 17:54 +0100, Oliver Zeigermann wrote:
> >
> >
> >>Ah, this makes it clear!
> >>
> >>I know it is really not obvious that you have to close a stream you do
> >>not even touch, but there really is no better solution I am afraid :(
> >>
> >>Same thing with the tx file store...
> >>
> >>Oliver
> >>
> >>On Fri, 19 Nov 2004 17:51:23 +0100, Unico Hommes <un...@hippo.nl> wrote:
> >>
> >>
> >>>OK, I see now. It doesn't matter if you actually decide to use the
> >>>NodeRevisionContent object. Once you retrieve it from the Content helper
> >>>the stream must somehow be closed. I was conditionally using it and so
> >>>connections were left open.
> >>>
> >>>Anyway, thanks again Oliver, you saved my day :-)
> >>>
> >>>--
> >>>Unico
> >>>
> >>>
> >>>
> >>>Unico Hommes wrote:
> >>>
> >>>
> >>>
> >>>>Dude it worked! Thanks!
> >>>>
> >>>>I am reading the NodeRevisionContent like so:
> >>>>
> >>>>InputStream in = null;
> >>>>try {
> >>>> in = new ByteArrayInputStream(content.getContentBytes());
> >>>>}
> >>>>finally {
> >>>> in.close();
> >>>>}
> >>>>
> >>>>Perhaps something goes wrong during
> >>>>NodeRevisionContent.getContentBytes() ? But it looks like that method
> >>>>correctly closes the InputStream though.
> >>>>
> >>>>--
> >>>>Unico
> >>>>
> >>>>Oliver Zeigermann wrote:
> >>>>
> >>>>
> >>>>
> >>>>>If you are not using compressed there will be an input stream in
> >>>>>content that is the one from the JDBC driver and *must* be closed to
> >>>>>close the connection. Try enabling compression if not already done and
> >>>>>see if this changes anything.
> >>>>>
> >>>>>Oliver
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>
> >>
> >
> >
> >
> >
> >>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Fwd: Unreleased database connections reading namespace
Posted by Oliver Zeigermann <ol...@gmail.com>.
Just right! Should be fixed by latest CVS commit...
Oliver
On Mon, 22 Nov 2004 15:21:29 +0100, Unico Hommes <un...@hippo.nl> wrote:
> There is actually another - more serious - way that a connection will
> not be released during AbstractJDBCStore.retrieveRevisionContent. This
> is whenever it throws an exception. The client code has no way to
> release the connection in that case because although a connection was
> assigned it does not hold a reference to the NodeRevisionContent to
> cause it to be released.
>
> --
> Unico
>
>
>
> Unico Hommes wrote:
>
> > Hi James,
> >
> > Reply button broken? ;-)
> >
> > I prefer your solution to adding a close method NodeRevisionContent.
> > Because close would only be functional in a very small number of
> > cases. During normal useage - using the input stream (and closing it),
> > or getting the byte array - calling close would be superfluous.
> > Another possible solution is to subclass NodeRevisionContent and
> > lazy-initialize the input stream whenever it is used. This probably
> > would need a change to RDBMSAdapter interface (retrieveRevisionContent
> > should return an InputStream instead of NodeRevisionContent) and some
> > changes to NodeRevisionContent. WDYT?
> >
> > --
> > Unico
> >
> >
> > Oliver Zeigermann wrote:
> >
> >> ---------- Forwarded message ----------
> >> From: James Mason <ma...@apache.org>
> >> Date: Fri, 19 Nov 2004 19:41:24 -0800
> >> Subject: Re: Unreleased database connections reading namespace
> >> To: ozeigermann@apache.org
> >>
> >>
> >> How about adding this to the javadoc for ContentHelper.retrieve() and
> >> NodeRevisionContent?
> >>
> >> -James
> >>
> >>
> >>
> >> On Fri, 2004-11-19 at 17:54 +0100, Oliver Zeigermann wrote:
> >>
> >>
> >>> Ah, this makes it clear!
> >>>
> >>> I know it is really not obvious that you have to close a stream you do
> >>> not even touch, but there really is no better solution I am afraid :(
> >>>
> >>> Same thing with the tx file store...
> >>>
> >>> Oliver
> >>>
> >>> On Fri, 19 Nov 2004 17:51:23 +0100, Unico Hommes <un...@hippo.nl>
> >>> wrote:
> >>>
> >>>
> >>>> OK, I see now. It doesn't matter if you actually decide to use the
> >>>> NodeRevisionContent object. Once you retrieve it from the Content
> >>>> helper
> >>>> the stream must somehow be closed. I was conditionally using it and so
> >>>> connections were left open.
> >>>>
> >>>> Anyway, thanks again Oliver, you saved my day :-)
> >>>>
> >>>> --
> >>>> Unico
> >>>>
> >>>>
> >>>>
> >>>> Unico Hommes wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Dude it worked! Thanks!
> >>>>>
> >>>>> I am reading the NodeRevisionContent like so:
> >>>>>
> >>>>> InputStream in = null;
> >>>>> try {
> >>>>> in = new ByteArrayInputStream(content.getContentBytes());
> >>>>> }
> >>>>> finally {
> >>>>> in.close();
> >>>>> }
> >>>>>
> >>>>> Perhaps something goes wrong during
> >>>>> NodeRevisionContent.getContentBytes() ? But it looks like that method
> >>>>> correctly closes the InputStream though.
> >>>>>
> >>>>> --
> >>>>> Unico
> >>>>>
> >>>>> Oliver Zeigermann wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> If you are not using compressed there will be an input stream in
> >>>>>> content that is the one from the JDBC driver and *must* be closed to
> >>>>>> close the connection. Try enabling compression if not already
> >>>>>> done and
> >>>>>> see if this changes anything.
> >>>>>>
> >>>>>> Oliver
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>>
> >>
> >>
> >>
> >>
> >>
> >>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Fwd: Unreleased database connections reading namespace
Posted by Unico Hommes <un...@hippo.nl>.
There is actually another - more serious - way that a connection will
not be released during AbstractJDBCStore.retrieveRevisionContent. This
is whenever it throws an exception. The client code has no way to
release the connection in that case because although a connection was
assigned it does not hold a reference to the NodeRevisionContent to
cause it to be released.
--
Unico
Unico Hommes wrote:
> Hi James,
>
> Reply button broken? ;-)
>
> I prefer your solution to adding a close method NodeRevisionContent.
> Because close would only be functional in a very small number of
> cases. During normal useage - using the input stream (and closing it),
> or getting the byte array - calling close would be superfluous.
> Another possible solution is to subclass NodeRevisionContent and
> lazy-initialize the input stream whenever it is used. This probably
> would need a change to RDBMSAdapter interface (retrieveRevisionContent
> should return an InputStream instead of NodeRevisionContent) and some
> changes to NodeRevisionContent. WDYT?
>
> --
> Unico
>
>
> Oliver Zeigermann wrote:
>
>> ---------- Forwarded message ----------
>> From: James Mason <ma...@apache.org>
>> Date: Fri, 19 Nov 2004 19:41:24 -0800
>> Subject: Re: Unreleased database connections reading namespace
>> To: ozeigermann@apache.org
>>
>>
>> How about adding this to the javadoc for ContentHelper.retrieve() and
>> NodeRevisionContent?
>>
>> -James
>>
>>
>>
>> On Fri, 2004-11-19 at 17:54 +0100, Oliver Zeigermann wrote:
>>
>>
>>> Ah, this makes it clear!
>>>
>>> I know it is really not obvious that you have to close a stream you do
>>> not even touch, but there really is no better solution I am afraid :(
>>>
>>> Same thing with the tx file store...
>>>
>>> Oliver
>>>
>>> On Fri, 19 Nov 2004 17:51:23 +0100, Unico Hommes <un...@hippo.nl>
>>> wrote:
>>>
>>>
>>>> OK, I see now. It doesn't matter if you actually decide to use the
>>>> NodeRevisionContent object. Once you retrieve it from the Content
>>>> helper
>>>> the stream must somehow be closed. I was conditionally using it and so
>>>> connections were left open.
>>>>
>>>> Anyway, thanks again Oliver, you saved my day :-)
>>>>
>>>> --
>>>> Unico
>>>>
>>>>
>>>>
>>>> Unico Hommes wrote:
>>>>
>>>>
>>>>
>>>>> Dude it worked! Thanks!
>>>>>
>>>>> I am reading the NodeRevisionContent like so:
>>>>>
>>>>> InputStream in = null;
>>>>> try {
>>>>> in = new ByteArrayInputStream(content.getContentBytes());
>>>>> }
>>>>> finally {
>>>>> in.close();
>>>>> }
>>>>>
>>>>> Perhaps something goes wrong during
>>>>> NodeRevisionContent.getContentBytes() ? But it looks like that method
>>>>> correctly closes the InputStream though.
>>>>>
>>>>> --
>>>>> Unico
>>>>>
>>>>> Oliver Zeigermann wrote:
>>>>>
>>>>>
>>>>>
>>>>>> If you are not using compressed there will be an input stream in
>>>>>> content that is the one from the JDBC driver and *must* be closed to
>>>>>> close the connection. Try enabling compression if not already
>>>>>> done and
>>>>>> see if this changes anything.
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>
>>
>>
>>
>>
>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Fwd: Unreleased database connections reading namespace
Posted by Unico Hommes <un...@hippo.nl>.
Hi James,
Reply button broken? ;-)
I prefer your solution to adding a close method NodeRevisionContent.
Because close would only be functional in a very small number of cases.
During normal useage - using the input stream (and closing it), or
getting the byte array - calling close would be superfluous. Another
possible solution is to subclass NodeRevisionContent and lazy-initialize
the input stream whenever it is used. This probably would need a change
to RDBMSAdapter interface (retrieveRevisionContent should return an
InputStream instead of NodeRevisionContent) and some changes to
NodeRevisionContent. WDYT?
--
Unico
Oliver Zeigermann wrote:
>---------- Forwarded message ----------
>From: James Mason <ma...@apache.org>
>Date: Fri, 19 Nov 2004 19:41:24 -0800
>Subject: Re: Unreleased database connections reading namespace
>To: ozeigermann@apache.org
>
>
>How about adding this to the javadoc for ContentHelper.retrieve() and
>NodeRevisionContent?
>
>-James
>
>
>
>On Fri, 2004-11-19 at 17:54 +0100, Oliver Zeigermann wrote:
>
>
>>Ah, this makes it clear!
>>
>>I know it is really not obvious that you have to close a stream you do
>>not even touch, but there really is no better solution I am afraid :(
>>
>>Same thing with the tx file store...
>>
>>Oliver
>>
>>On Fri, 19 Nov 2004 17:51:23 +0100, Unico Hommes <un...@hippo.nl> wrote:
>>
>>
>>>OK, I see now. It doesn't matter if you actually decide to use the
>>>NodeRevisionContent object. Once you retrieve it from the Content helper
>>>the stream must somehow be closed. I was conditionally using it and so
>>>connections were left open.
>>>
>>>Anyway, thanks again Oliver, you saved my day :-)
>>>
>>>--
>>>Unico
>>>
>>>
>>>
>>>Unico Hommes wrote:
>>>
>>>
>>>
>>>>Dude it worked! Thanks!
>>>>
>>>>I am reading the NodeRevisionContent like so:
>>>>
>>>>InputStream in = null;
>>>>try {
>>>> in = new ByteArrayInputStream(content.getContentBytes());
>>>>}
>>>>finally {
>>>> in.close();
>>>>}
>>>>
>>>>Perhaps something goes wrong during
>>>>NodeRevisionContent.getContentBytes() ? But it looks like that method
>>>>correctly closes the InputStream though.
>>>>
>>>>--
>>>>Unico
>>>>
>>>>Oliver Zeigermann wrote:
>>>>
>>>>
>>>>
>>>>>If you are not using compressed there will be an input stream in
>>>>>content that is the one from the JDBC driver and *must* be closed to
>>>>>close the connection. Try enabling compression if not already done and
>>>>>see if this changes anything.
>>>>>
>>>>>Oliver
>>>>>
>>>>>
>>>>>
>>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>
>>
>
>
>
>
>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Fwd: Unreleased database connections reading namespace
Posted by Oliver Zeigermann <ol...@gmail.com>.
---------- Forwarded message ----------
From: James Mason <ma...@apache.org>
Date: Fri, 19 Nov 2004 19:41:24 -0800
Subject: Re: Unreleased database connections reading namespace
To: ozeigermann@apache.org
How about adding this to the javadoc for ContentHelper.retrieve() and
NodeRevisionContent?
-James
On Fri, 2004-11-19 at 17:54 +0100, Oliver Zeigermann wrote:
> Ah, this makes it clear!
>
> I know it is really not obvious that you have to close a stream you do
> not even touch, but there really is no better solution I am afraid :(
>
> Same thing with the tx file store...
>
> Oliver
>
> On Fri, 19 Nov 2004 17:51:23 +0100, Unico Hommes <un...@hippo.nl> wrote:
> > OK, I see now. It doesn't matter if you actually decide to use the
> > NodeRevisionContent object. Once you retrieve it from the Content helper
> > the stream must somehow be closed. I was conditionally using it and so
> > connections were left open.
> >
> > Anyway, thanks again Oliver, you saved my day :-)
> >
> > --
> > Unico
> >
> >
> >
> > Unico Hommes wrote:
> >
> > > Dude it worked! Thanks!
> > >
> > > I am reading the NodeRevisionContent like so:
> > >
> > > InputStream in = null;
> > > try {
> > > in = new ByteArrayInputStream(content.getContentBytes());
> > > }
> > > finally {
> > > in.close();
> > > }
> > >
> > > Perhaps something goes wrong during
> > > NodeRevisionContent.getContentBytes() ? But it looks like that method
> > > correctly closes the InputStream though.
> > >
> > > --
> > > Unico
> > >
> > > Oliver Zeigermann wrote:
> > >
> > >> If you are not using compressed there will be an input stream in
> > >> content that is the one from the JDBC driver and *must* be closed to
> > >> close the connection. Try enabling compression if not already done and
> > >> see if this changes anything.
> > >>
> > >> Oliver
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Unreleased database connections reading namespace
Posted by Oliver Zeigermann <ol...@gmail.com>.
Ah, this makes it clear!
I know it is really not obvious that you have to close a stream you do
not even touch, but there really is no better solution I am afraid :(
Same thing with the tx file store...
Oliver
On Fri, 19 Nov 2004 17:51:23 +0100, Unico Hommes <un...@hippo.nl> wrote:
> OK, I see now. It doesn't matter if you actually decide to use the
> NodeRevisionContent object. Once you retrieve it from the Content helper
> the stream must somehow be closed. I was conditionally using it and so
> connections were left open.
>
> Anyway, thanks again Oliver, you saved my day :-)
>
> --
> Unico
>
>
>
> Unico Hommes wrote:
>
> > Dude it worked! Thanks!
> >
> > I am reading the NodeRevisionContent like so:
> >
> > InputStream in = null;
> > try {
> > in = new ByteArrayInputStream(content.getContentBytes());
> > }
> > finally {
> > in.close();
> > }
> >
> > Perhaps something goes wrong during
> > NodeRevisionContent.getContentBytes() ? But it looks like that method
> > correctly closes the InputStream though.
> >
> > --
> > Unico
> >
> > Oliver Zeigermann wrote:
> >
> >> If you are not using compressed there will be an input stream in
> >> content that is the one from the JDBC driver and *must* be closed to
> >> close the connection. Try enabling compression if not already done and
> >> see if this changes anything.
> >>
> >> Oliver
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Unreleased database connections reading namespace
Posted by Unico Hommes <un...@hippo.nl>.
OK, I see now. It doesn't matter if you actually decide to use the
NodeRevisionContent object. Once you retrieve it from the Content helper
the stream must somehow be closed. I was conditionally using it and so
connections were left open.
Anyway, thanks again Oliver, you saved my day :-)
--
Unico
Unico Hommes wrote:
> Dude it worked! Thanks!
>
> I am reading the NodeRevisionContent like so:
>
> InputStream in = null;
> try {
> in = new ByteArrayInputStream(content.getContentBytes());
> }
> finally {
> in.close();
> }
>
> Perhaps something goes wrong during
> NodeRevisionContent.getContentBytes() ? But it looks like that method
> correctly closes the InputStream though.
>
> --
> Unico
>
> Oliver Zeigermann wrote:
>
>> If you are not using compressed there will be an input stream in
>> content that is the one from the JDBC driver and *must* be closed to
>> close the connection. Try enabling compression if not already done and
>> see if this changes anything.
>>
>> Oliver
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Unreleased database connections reading namespace
Posted by Oliver Zeigermann <ol...@gmail.com>.
What did the trick? Turning the compression on? Which database do you
use? Oracle?
Oliver
On Fri, 19 Nov 2004 17:41:31 +0100, Unico Hommes <un...@hippo.nl> wrote:
> Dude it worked! Thanks!
>
> I am reading the NodeRevisionContent like so:
>
> InputStream in = null;
> try {
> in = new ByteArrayInputStream(content.getContentBytes());
> }
> finally {
> in.close();
> }
>
> Perhaps something goes wrong during
> NodeRevisionContent.getContentBytes() ? But it looks like that method
> correctly closes the InputStream though.
>
> --
> Unico
>
>
>
> Oliver Zeigermann wrote:
>
> >If you are not using compressed there will be an input stream in
> >content that is the one from the JDBC driver and *must* be closed to
> >close the connection. Try enabling compression if not already done and
> >see if this changes anything.
> >
> >Oliver
> >
> >
> >On Fri, 19 Nov 2004 16:25:12 +0100, Unico Hommes <un...@hippo.nl> wrote:
> >
> >
> >>Hi guys,
> >>
> >>I am struggling with a dead lock due to JDBC connections that don't
> >>seems to get released. I did a very simple test where I iterate over all
> >>nodes in the database and read their contents:
> >>
> >>Iterator uris = new StructureIterator();
> >>while(uris.hasNext()) {
> >> String uri = (String) uris.next();
> >> try {
> >> final NodeRevisionDescriptors descriptors =
> >>m_content.retrieve(m_token, uri);
> >> final NodeRevisionDescriptor descriptor =
> >>m_content.retrieve(m_token, descriptors);
> >> final NodeRevisionContent content = m_content.retrieve(m_token,
> >>descriptors, descriptor);
> >>
> >> [snip stuff]
> >>
> >> }
> >> catch (SlideException e) {
> >> System.err.println(e);
> >> }
> >>}
> >>
> >>/**
> >> * Iterates over all nodes within a Namespace
> >> */
> >>class StructureIterator implements Iterator {
> >>
> >> private final ArrayStack m_stack = new ArrayStack();
> >>
> >> StructureIterator() {
> >> m_stack.push(m_structure.retrieve(m_token, "/"));
> >> }
> >> public boolean hasNext() {
> >> return !m_stack.empty();
> >> }
> >>
> >> public Object next() {
> >> if (!hasNext()) {
> >> throw new NoSuchElementException();
> >> }
> >> final ObjectNode node = (ObjectNode) m_stack.pop();
> >> traverse(node);
> >> return node.getUri();
> >> }
> >>
> >> private void traverse(ObjectNode node) {
> >> try {
> >>
> >>m_stack.addAll(Collections.list(m_structure.getChildren(m_token, node)));
> >> }
> >> catch (SlideException e) {
> >> m_logger.error("Error iterating through repository", e);
> >> }
> >> }
> >>
> >>}
> >>
> >>It looks like each iteration "eats" a database connection. Probably it
> >>is something I am doing wrong using the Slide API but this used to work.
> >>
> >>Thoughts?
> >>
> >>--
> >>Unico
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Unreleased database connections reading namespace
Posted by Unico Hommes <un...@hippo.nl>.
Dude it worked! Thanks!
I am reading the NodeRevisionContent like so:
InputStream in = null;
try {
in = new ByteArrayInputStream(content.getContentBytes());
}
finally {
in.close();
}
Perhaps something goes wrong during
NodeRevisionContent.getContentBytes() ? But it looks like that method
correctly closes the InputStream though.
--
Unico
Oliver Zeigermann wrote:
>If you are not using compressed there will be an input stream in
>content that is the one from the JDBC driver and *must* be closed to
>close the connection. Try enabling compression if not already done and
>see if this changes anything.
>
>Oliver
>
>
>On Fri, 19 Nov 2004 16:25:12 +0100, Unico Hommes <un...@hippo.nl> wrote:
>
>
>>Hi guys,
>>
>>I am struggling with a dead lock due to JDBC connections that don't
>>seems to get released. I did a very simple test where I iterate over all
>>nodes in the database and read their contents:
>>
>>Iterator uris = new StructureIterator();
>>while(uris.hasNext()) {
>> String uri = (String) uris.next();
>> try {
>> final NodeRevisionDescriptors descriptors =
>>m_content.retrieve(m_token, uri);
>> final NodeRevisionDescriptor descriptor =
>>m_content.retrieve(m_token, descriptors);
>> final NodeRevisionContent content = m_content.retrieve(m_token,
>>descriptors, descriptor);
>>
>> [snip stuff]
>>
>> }
>> catch (SlideException e) {
>> System.err.println(e);
>> }
>>}
>>
>>/**
>> * Iterates over all nodes within a Namespace
>> */
>>class StructureIterator implements Iterator {
>>
>> private final ArrayStack m_stack = new ArrayStack();
>>
>> StructureIterator() {
>> m_stack.push(m_structure.retrieve(m_token, "/"));
>> }
>> public boolean hasNext() {
>> return !m_stack.empty();
>> }
>>
>> public Object next() {
>> if (!hasNext()) {
>> throw new NoSuchElementException();
>> }
>> final ObjectNode node = (ObjectNode) m_stack.pop();
>> traverse(node);
>> return node.getUri();
>> }
>>
>> private void traverse(ObjectNode node) {
>> try {
>>
>>m_stack.addAll(Collections.list(m_structure.getChildren(m_token, node)));
>> }
>> catch (SlideException e) {
>> m_logger.error("Error iterating through repository", e);
>> }
>> }
>>
>>}
>>
>>It looks like each iteration "eats" a database connection. Probably it
>>is something I am doing wrong using the Slide API but this used to work.
>>
>>Thoughts?
>>
>>--
>>Unico
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Unreleased database connections reading namespace
Posted by Oliver Zeigermann <ol...@gmail.com>.
If you are not using compressed there will be an input stream in
content that is the one from the JDBC driver and *must* be closed to
close the connection. Try enabling compression if not already done and
see if this changes anything.
Oliver
On Fri, 19 Nov 2004 16:25:12 +0100, Unico Hommes <un...@hippo.nl> wrote:
> Hi guys,
>
> I am struggling with a dead lock due to JDBC connections that don't
> seems to get released. I did a very simple test where I iterate over all
> nodes in the database and read their contents:
>
> Iterator uris = new StructureIterator();
> while(uris.hasNext()) {
> String uri = (String) uris.next();
> try {
> final NodeRevisionDescriptors descriptors =
> m_content.retrieve(m_token, uri);
> final NodeRevisionDescriptor descriptor =
> m_content.retrieve(m_token, descriptors);
> final NodeRevisionContent content = m_content.retrieve(m_token,
> descriptors, descriptor);
>
> [snip stuff]
>
> }
> catch (SlideException e) {
> System.err.println(e);
> }
> }
>
> /**
> * Iterates over all nodes within a Namespace
> */
> class StructureIterator implements Iterator {
>
> private final ArrayStack m_stack = new ArrayStack();
>
> StructureIterator() {
> m_stack.push(m_structure.retrieve(m_token, "/"));
> }
> public boolean hasNext() {
> return !m_stack.empty();
> }
>
> public Object next() {
> if (!hasNext()) {
> throw new NoSuchElementException();
> }
> final ObjectNode node = (ObjectNode) m_stack.pop();
> traverse(node);
> return node.getUri();
> }
>
> private void traverse(ObjectNode node) {
> try {
>
> m_stack.addAll(Collections.list(m_structure.getChildren(m_token, node)));
> }
> catch (SlideException e) {
> m_logger.error("Error iterating through repository", e);
> }
> }
>
> }
>
> It looks like each iteration "eats" a database connection. Probably it
> is something I am doing wrong using the Slide API but this used to work.
>
> Thoughts?
>
> --
> Unico
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org