Slide Tomcat Sessions - Closing them
Hi, I posted a question a few days ago about Slide sessions within Tomcat not being closed, when using the client Java API. I didn't notice any replies so thought I'd post again under a different subject. Anyway, if anyone has experiences of trying to close sessions within Tomcat from within the client API then I'd be glad to hear about it. The .close() method of a WebdavResource doesn't seem to be working. (I'm currently using verion 2.0rc1 on the client side - does the final version fix this?). Cheers Luke. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
Sorry, but I cannot see why reportMethod() should cause a new session to be created. Btw., it is an inconsistency in the API that those methods take a HttpURL argument instead of a simple path string like the other methods. That should be resolved in CVS HEAD soon. Coming back to the problem: The only methods that open a new session, at least as far as I can see, are the optionsMethod() calls. Are you sure you are not calling something like setHttpURL() before or after invoking one of the report methods? Ingo > Hi, > > I did a bit more investigate and found I had made a mistake. It wasn't > getHttpURL() that was creating a new session, it was the methods of > WebdavResource that used the HttpURL I had got (for example > reportMethod) that were causing a new session to be created. > > So, it seems it is not getHttpURL() that is creating the session, but > instead methods such as reportMethod() that take a HttpURL as a > parameter. > > > Cheers > > Luke. > - > > > > On 10 May 2004, at 18:15, Ingo Brunberg wrote: > > > This is indeed worth investigating. Calling getHttpURL() should really > > not create a new session. Maybe you can post a code snippet? > > > > Ingo > > > >> After a bit more investigation, it seems that constructing a new > >> HttpURL or > >> using the getHttpURL() method of WebdavResource also creates a new > >> session. > >> > >> Should it be doing this? > >> > >> Is there a way to avoid it doing so? > >> > >> There are some cases where I can see no way of doing what I want > >> without > >> constructing a new WebdavResource or a HttpURL. > >> > >> > >> Cheers > >> > >> Luke. > >> - > >> > >> > >> > >> Quoting luke noel-storr <[EMAIL PROTECTED]>: > >> > >>> > >>> Hmm, either I misunderstood what you meant, or it doesn't quite fix > >>> things > >>> the > >>> way I expected. > >>> > >>> I now only construct one webdav resource in my code, however, after > >>> running > >>> just > >>> a few simple getMethods, propFindMethods and reportMethods 5 > >>> sessions are > >>> created when I expected only one to be created. > >>> > >>> Any further suggestions? > >>> > >>> > >>> Cheers > >>> > >>> Luke. > >>> - > >>> > >>> > >>> > >>> > >>> Quoting luke noel-storr <[EMAIL PROTECTED]>: > >>> > Hi, > > I don't have a problem in terms of errors or crashes or anything; > however, > >>> I > was > in fear of the rapidly increasing session count (into several > thousands > after > just a few calls to a servlet I had). > > I shall now recode based on your advice though - thank you for your > help. > > > Cheers > > Luke. > - > > > > Quoting Ingo Brunberg <[EMAIL PROTECTED]>: > > > Do you actually have a problem with open sessions or is you > > interest > > rather theoretical? > > > > As I explained some time ago, you should use WebdavResource in > > such a > > way that you call a WebdavResource constructor only once in your > > application. This way you have no more than one connection, so you > > should hit no resource limits, hence my question above. > > > > The reason that WebdavResouce.close() does not really close the > > connection is that this would lead to having to reconnect if a > > parent > > or a child obtained by calling listWebdavResources() or > > getChildResources() issues the next request. > > > > You may call this a design deficiency, but this is how you are > > cuurently supposed to work with the client library. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > >>> > >>> > >>> -- > >>> > >>> - > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> > >> -- > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
Hi,
Here is an example of some test code I wrote:
Credentials credentials = new
UsernamePasswordCredentials("luke", "password");
String url =
"http://localhost:8080/slide2-db/files/iplus/data/funds/";;
WebdavResource wdr = new WebdavResource(url, credentials);
wdr.reportMethod(wdr.getHttpURL(), 0);
wdr.reportMethod(wdr.getHttpURL(), 0);
This creates THREE sessions in Tomcat. Adding another call to
reportMethod() creates a new session.
Any ideas?
I'm going to download 2.0 final now - hopefully this may fix it, but I'm
suspecting it won't.
Cheers
Luke.
-
Ingo Brunberg wrote:
Sorry, but I cannot see why reportMethod() should cause a new session
to be created. Btw., it is an inconsistency in the API that those
methods take a HttpURL argument instead of a simple path string like
the other methods. That should be resolved in CVS HEAD soon.
Coming back to the problem: The only methods that open a new session,
at least as far as I can see, are the optionsMethod() calls. Are you
sure you are not calling something like setHttpURL() before or after
invoking one of the report methods?
Ingo
Hi,
I did a bit more investigate and found I had made a mistake. It wasn't
getHttpURL() that was creating a new session, it was the methods of
WebdavResource that used the HttpURL I had got (for example
reportMethod) that were causing a new session to be created.
So, it seems it is not getHttpURL() that is creating the session, but
instead methods such as reportMethod() that take a HttpURL as a
parameter.
Cheers
Luke.
-
On 10 May 2004, at 18:15, Ingo Brunberg wrote:
This is indeed worth investigating. Calling getHttpURL() should really
not create a new session. Maybe you can post a code snippet?
Ingo
After a bit more investigation, it seems that constructing a new
HttpURL or
using the getHttpURL() method of WebdavResource also creates a new
session.
Should it be doing this?
Is there a way to avoid it doing so?
There are some cases where I can see no way of doing what I want
without
constructing a new WebdavResource or a HttpURL.
Cheers
Luke.
-
Quoting luke noel-storr <[EMAIL PROTECTED]>:
Hmm, either I misunderstood what you meant, or it doesn't quite fix
things
the
way I expected.
I now only construct one webdav resource in my code, however, after
running
just
a few simple getMethods, propFindMethods and reportMethods 5
sessions are
created when I expected only one to be created.
Any further suggestions?
Cheers
Luke.
-
Quoting luke noel-storr <[EMAIL PROTECTED]>:
Hi,
I don't have a problem in terms of errors or crashes or anything;
however,
I
was
in fear of the rapidly increasing session count (into several
thousands
after
just a few calls to a servlet I had).
I shall now recode based on your advice though - thank you for your
help.
Cheers
Luke.
-
Quoting Ingo Brunberg <[EMAIL PROTECTED]>:
Do you actually have a problem with open sessions or is you
interest
rather theoretical?
As I explained some time ago, you should use WebdavResource in
such a
way that you call a WebdavResource constructor only once in your
application. This way you have no more than one connection, so you
should hit no resource limits, hence my question above.
The reason that WebdavResouce.close() does not really close the
connection is that this would lead to having to reconnect if a
parent
or a child obtained by calling listWebdavResources() or
getChildResources() issues the next request.
You may call this a design deficiency, but this is how you are
cuurently supposed to work with the client library.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
Ok, I think I have found the reason you end up creating new sessions
everytime. But that should not be specific to reportMethod() but all
WebDAV methods you call from WebdavResource.
Try putting your username and password into your URL. You can then
omit the Credentials.
There's a strange test in WebdavResource, that gets executed before
every method call to check if the current credentials have changed.
This method is broken if you don't put them into the URL. This check
could be omitted if the URL and userinfo within WebdavResource were
protected from foreign mutations. I would like to see these
restrictions introduced in the post 2.0 code as
1) I see no benefit in being able to change those parameters after a
WebdavResource is being created.
2) you could easily cache the decoded path and name to avoid decoding
the path on every call to getPath(), getName() and when executing a
WebDAV method for the current resource.
Ingo
> Hi,
>
> Here is an example of some test code I wrote:
>
> Credentials credentials = new
> UsernamePasswordCredentials("luke", "password");
> String url =
> "http://localhost:8080/slide2-db/files/iplus/data/funds/";;
>
> WebdavResource wdr = new WebdavResource(url, credentials);
>
> wdr.reportMethod(wdr.getHttpURL(), 0);
> wdr.reportMethod(wdr.getHttpURL(), 0);
>
> This creates THREE sessions in Tomcat. Adding another call to
> reportMethod() creates a new session.
>
> Any ideas?
>
> I'm going to download 2.0 final now - hopefully this may fix it, but I'm
> suspecting it won't.
>
>
> Cheers
>
> Luke.
> -
>
>
> Ingo Brunberg wrote:
>
> >Sorry, but I cannot see why reportMethod() should cause a new session
> >to be created. Btw., it is an inconsistency in the API that those
> >methods take a HttpURL argument instead of a simple path string like
> >the other methods. That should be resolved in CVS HEAD soon.
> >
> >Coming back to the problem: The only methods that open a new session,
> >at least as far as I can see, are the optionsMethod() calls. Are you
> >sure you are not calling something like setHttpURL() before or after
> >invoking one of the report methods?
> >
> >Ingo
> >
> >
> >
> >>Hi,
> >>
> >>I did a bit more investigate and found I had made a mistake. It wasn't
> >>getHttpURL() that was creating a new session, it was the methods of
> >>WebdavResource that used the HttpURL I had got (for example
> >>reportMethod) that were causing a new session to be created.
> >>
> >>So, it seems it is not getHttpURL() that is creating the session, but
> >>instead methods such as reportMethod() that take a HttpURL as a
> >>parameter.
> >>
> >>
> >>Cheers
> >>
> >>Luke.
> >>-
> >>
> >>
> >>
> >>On 10 May 2004, at 18:15, Ingo Brunberg wrote:
> >>
> >>
> >>
> >>>This is indeed worth investigating. Calling getHttpURL() should really
> >>>not create a new session. Maybe you can post a code snippet?
> >>>
> >>>Ingo
> >>>
> >>>
> >>>
> After a bit more investigation, it seems that constructing a new
> HttpURL or
> using the getHttpURL() method of WebdavResource also creates a new
> session.
>
> Should it be doing this?
>
> Is there a way to avoid it doing so?
>
> There are some cases where I can see no way of doing what I want
> without
> constructing a new WebdavResource or a HttpURL.
>
>
> Cheers
>
> Luke.
> -
>
>
>
> Quoting luke noel-storr <[EMAIL PROTECTED]>:
>
>
>
> >Hmm, either I misunderstood what you meant, or it doesn't quite fix
> >things
> >the
> >way I expected.
> >
> >I now only construct one webdav resource in my code, however, after
> >running
> >just
> >a few simple getMethods, propFindMethods and reportMethods 5
> >sessions are
> >created when I expected only one to be created.
> >
> >Any further suggestions?
> >
> >
> >Cheers
> >
> >Luke.
> >-
> >
> >
> >
> >
> >Quoting luke noel-storr <[EMAIL PROTECTED]>:
> >
> >
> >
> >>Hi,
> >>
> >>I don't have a problem in terms of errors or crashes or anything;
> >>however,
> >>
> >>
> >I
> >
> >
> >>was
> >>in fear of the rapidly increasing session count (into several
> >>thousands
> >>after
> >>just a few calls to a servlet I had).
> >>
> >>I shall now recode based on your advice though - thank you for your
> >>help.
> >>
> >>
> >>Cheers
> >>
> >>Luke.
> >>-
> >>
> >>
> >>
> >>Quoting Ingo Brunberg <[EMAIL PROTECTED]>:
> >>
> >>
> >>
> >>>Do you actually have a problem with open sessions or is you
> >>>interest
> >>>rather theoretical?
> >>>
> >>>As I explained some time ago, you should use WebdavResource
Re: Slide Tomcat Sessions - Closing them
I had just downloaded the source and discovered that it was this check that was causing the problem. Thank you for the solution to the problem, I will give it a go. At first glance though it would seem there are more security implications arround this solution - is this the case? Cheers Luke. - Ingo Brunberg wrote: Ok, I think I have found the reason you end up creating new sessions everytime. But that should not be specific to reportMethod() but all WebDAV methods you call from WebdavResource. Try putting your username and password into your URL. You can then omit the Credentials. There's a strange test in WebdavResource, that gets executed before every method call to check if the current credentials have changed. This method is broken if you don't put them into the URL. This check could be omitted if the URL and userinfo within WebdavResource were protected from foreign mutations. I would like to see these restrictions introduced in the post 2.0 code as 1) I see no benefit in being able to change those parameters after a WebdavResource is being created. 2) you could easily cache the decoded path and name to avoid decoding the path on every call to getPath(), getName() and when executing a WebDAV method for the current resource. Ingo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
OK, I'm sure I'm probably being stupid, but how do I put my username and password into the URL? I've tried sticking "?user=luke&password=password" (and variations of this) at the end of the URL, but that doesn't seem to work. Cheers Luke. - Luke Noel-Storr wrote: I had just downloaded the source and discovered that it was this check that was causing the problem. Thank you for the solution to the problem, I will give it a go. At first glance though it would seem there are more security implications arround this solution - is this the case? Cheers Luke. - Ingo Brunberg wrote: Ok, I think I have found the reason you end up creating new sessions everytime. But that should not be specific to reportMethod() but all WebDAV methods you call from WebdavResource. Try putting your username and password into your URL. You can then omit the Credentials. There's a strange test in WebdavResource, that gets executed before every method call to check if the current credentials have changed. This method is broken if you don't put them into the URL. This check could be omitted if the URL and userinfo within WebdavResource were protected from foreign mutations. I would like to see these restrictions introduced in the post 2.0 code as 1) I see no benefit in being able to change those parameters after a WebdavResource is being created. 2) you could easily cache the decoded path and name to avoid decoding the path on every call to getPath(), getName() and when executing a WebDAV method for the current resource. Ingo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slide Tomcat Sessions - Closing them
Hi Luke, The best way to do this is to set the setEscapedUserinfo() on the HttpURL. Alternativley, the username and password info in a url goes in this format: http://username:[EMAIL PROTECTED]/stuff hope that helps. Ryan- -Original Message- From: Luke Noel-Storr [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 11, 2004 11:13 AM To: Slide Users Mailing List Subject: Re: Slide Tomcat Sessions - Closing them OK, I'm sure I'm probably being stupid, but how do I put my username and password into the URL? I've tried sticking "?user=luke&password=password" (and variations of this) at the end of the URL, but that doesn't seem to work. Cheers Luke. - Luke Noel-Storr wrote: > I had just downloaded the source and discovered that it was this check > that was causing the problem. > > Thank you for the solution to the problem, I will give it a go. > > At first glance though it would seem there are more security > implications arround this solution - is this the case? > > > Cheers > > Luke. > - > > Ingo Brunberg wrote: > >> Ok, I think I have found the reason you end up creating new sessions >> everytime. But that should not be specific to reportMethod() but all >> WebDAV methods you call from WebdavResource. >> >> Try putting your username and password into your URL. You can then >> omit the Credentials. >> >> There's a strange test in WebdavResource, that gets executed before >> every method call to check if the current credentials have changed. >> This method is broken if you don't put them into the URL. This check >> could be omitted if the URL and userinfo within WebdavResource were >> protected from foreign mutations. I would like to see these >> restrictions introduced in the post 2.0 code as >> 1) I see no benefit in being able to change those parameters after a >> WebdavResource is being created. >> 2) you could easily cache the decoded path and name to avoid decoding >> the path on every call to getPath(), getName() and when executing a >> WebDAV method for the current resource. >> >> Ingo >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
If you just want to add your credentials to the url, you have to do it like this... http://user:[EMAIL PROTECTED]:8080/sharedfolder NOTE: The latest http-commons doesn't set credentials correctly (see prior e-mail chain with my name), I had to manually insert the username and password into the ur (a hack, but it works) Jeff From: Luke Noel-Storr <[EMAIL PROTECTED]> Reply-To: "Slide Users Mailing List" <[EMAIL PROTECTED]> To: Slide Users Mailing List <[EMAIL PROTECTED]> Subject: Re: Slide Tomcat Sessions - Closing them Date: Tue, 11 May 2004 16:13:24 +0100 OK, I'm sure I'm probably being stupid, but how do I put my username and password into the URL? I've tried sticking "?user=luke&password=password" (and variations of this) at the end of the URL, but that doesn't seem to work. Cheers Luke. - Luke Noel-Storr wrote: I had just downloaded the source and discovered that it was this check that was causing the problem. Thank you for the solution to the problem, I will give it a go. At first glance though it would seem there are more security implications arround this solution - is this the case? Cheers Luke. - Ingo Brunberg wrote: Ok, I think I have found the reason you end up creating new sessions everytime. But that should not be specific to reportMethod() but all WebDAV methods you call from WebdavResource. Try putting your username and password into your URL. You can then omit the Credentials. There's a strange test in WebdavResource, that gets executed before every method call to check if the current credentials have changed. This method is broken if you don't put them into the URL. This check could be omitted if the URL and userinfo within WebdavResource were protected from foreign mutations. I would like to see these restrictions introduced in the post 2.0 code as 1) I see no benefit in being able to change those parameters after a WebdavResource is being created. 2) you could easily cache the decoded path and name to avoid decoding the path on every call to getPath(), getName() and when executing a WebDAV method for the current resource. Ingo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Express yourself with the new version of MSN Messenger! Download today - it's FREE! http://messenger.msn.com/go/onm00200471ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
Hi, I don't have a problem in terms of errors or crashes or anything; however, I was in fear of the rapidly increasing session count (into several thousands after just a few calls to a servlet I had). I shall now recode based on your advice though - thank you for your help. Cheers Luke. - Quoting Ingo Brunberg <[EMAIL PROTECTED]>: > Do you actually have a problem with open sessions or is you interest > rather theoretical? > > As I explained some time ago, you should use WebdavResource in such a > way that you call a WebdavResource constructor only once in your > application. This way you have no more than one connection, so you > should hit no resource limits, hence my question above. > > The reason that WebdavResouce.close() does not really close the > connection is that this would lead to having to reconnect if a parent > or a child obtained by calling listWebdavResources() or > getChildResources() issues the next request. > > You may call this a design deficiency, but this is how you are > cuurently supposed to work with the client library. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
Hmm, either I misunderstood what you meant, or it doesn't quite fix things the way I expected. I now only construct one webdav resource in my code, however, after running just a few simple getMethods, propFindMethods and reportMethods 5 sessions are created when I expected only one to be created. Any further suggestions? Cheers Luke. - Quoting luke noel-storr <[EMAIL PROTECTED]>: > Hi, > > I don't have a problem in terms of errors or crashes or anything; however, I > was > in fear of the rapidly increasing session count (into several thousands > after > just a few calls to a servlet I had). > > I shall now recode based on your advice though - thank you for your help. > > > Cheers > > Luke. > - > > > > Quoting Ingo Brunberg <[EMAIL PROTECTED]>: > > > Do you actually have a problem with open sessions or is you interest > > rather theoretical? > > > > As I explained some time ago, you should use WebdavResource in such a > > way that you call a WebdavResource constructor only once in your > > application. This way you have no more than one connection, so you > > should hit no resource limits, hence my question above. > > > > The reason that WebdavResouce.close() does not really close the > > connection is that this would lead to having to reconnect if a parent > > or a child obtained by calling listWebdavResources() or > > getChildResources() issues the next request. > > > > You may call this a design deficiency, but this is how you are > > cuurently supposed to work with the client library. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
After a bit more investigation, it seems that constructing a new HttpURL or using the getHttpURL() method of WebdavResource also creates a new session. Should it be doing this? Is there a way to avoid it doing so? There are some cases where I can see no way of doing what I want without constructing a new WebdavResource or a HttpURL. Cheers Luke. - Quoting luke noel-storr <[EMAIL PROTECTED]>: > > Hmm, either I misunderstood what you meant, or it doesn't quite fix things > the > way I expected. > > I now only construct one webdav resource in my code, however, after running > just > a few simple getMethods, propFindMethods and reportMethods 5 sessions are > created when I expected only one to be created. > > Any further suggestions? > > > Cheers > > Luke. > - > > > > > Quoting luke noel-storr <[EMAIL PROTECTED]>: > > > Hi, > > > > I don't have a problem in terms of errors or crashes or anything; however, > I > > was > > in fear of the rapidly increasing session count (into several thousands > > after > > just a few calls to a servlet I had). > > > > I shall now recode based on your advice though - thank you for your help. > > > > > > Cheers > > > > Luke. > > - > > > > > > > > Quoting Ingo Brunberg <[EMAIL PROTECTED]>: > > > > > Do you actually have a problem with open sessions or is you interest > > > rather theoretical? > > > > > > As I explained some time ago, you should use WebdavResource in such a > > > way that you call a WebdavResource constructor only once in your > > > application. This way you have no more than one connection, so you > > > should hit no resource limits, hence my question above. > > > > > > The reason that WebdavResouce.close() does not really close the > > > connection is that this would lead to having to reconnect if a parent > > > or a child obtained by calling listWebdavResources() or > > > getChildResources() issues the next request. > > > > > > You may call this a design deficiency, but this is how you are > > > cuurently supposed to work with the client library. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
This is indeed worth investigating. Calling getHttpURL() should really not create a new session. Maybe you can post a code snippet? Ingo > After a bit more investigation, it seems that constructing a new HttpURL or > using the getHttpURL() method of WebdavResource also creates a new session. > > Should it be doing this? > > Is there a way to avoid it doing so? > > There are some cases where I can see no way of doing what I want without > constructing a new WebdavResource or a HttpURL. > > > Cheers > > Luke. > - > > > > Quoting luke noel-storr <[EMAIL PROTECTED]>: > > > > > Hmm, either I misunderstood what you meant, or it doesn't quite fix things > > the > > way I expected. > > > > I now only construct one webdav resource in my code, however, after running > > just > > a few simple getMethods, propFindMethods and reportMethods 5 sessions are > > created when I expected only one to be created. > > > > Any further suggestions? > > > > > > Cheers > > > > Luke. > > - > > > > > > > > > > Quoting luke noel-storr <[EMAIL PROTECTED]>: > > > > > Hi, > > > > > > I don't have a problem in terms of errors or crashes or anything; however, > > I > > > was > > > in fear of the rapidly increasing session count (into several thousands > > > after > > > just a few calls to a servlet I had). > > > > > > I shall now recode based on your advice though - thank you for your help. > > > > > > > > > Cheers > > > > > > Luke. > > > - > > > > > > > > > > > > Quoting Ingo Brunberg <[EMAIL PROTECTED]>: > > > > > > > Do you actually have a problem with open sessions or is you interest > > > > rather theoretical? > > > > > > > > As I explained some time ago, you should use WebdavResource in such a > > > > way that you call a WebdavResource constructor only once in your > > > > application. This way you have no more than one connection, so you > > > > should hit no resource limits, hence my question above. > > > > > > > > The reason that WebdavResouce.close() does not really close the > > > > connection is that this would lead to having to reconnect if a parent > > > > or a child obtained by calling listWebdavResources() or > > > > getChildResources() issues the next request. > > > > > > > > You may call this a design deficiency, but this is how you are > > > > cuurently supposed to work with the client library. > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slide Tomcat Sessions - Closing them
Hi Luke, I recently dug into the WebdavResource while trying to solve my own problems. I ended up making my own method calls using HttpClient and some of the Webdav methods. Doing it this way, I was able to reuse the same instance of the HttpClient for all of my method calls and only 1 session is created. Ryan- -Original Message- From: luke noel-storr [mailto:[EMAIL PROTECTED] Sent: Monday, May 10, 2004 11:51 AM To: Slide Users Mailing List Subject: Re: Slide Tomcat Sessions - Closing them Hmm, either I misunderstood what you meant, or it doesn't quite fix things the way I expected. I now only construct one webdav resource in my code, however, after running just a few simple getMethods, propFindMethods and reportMethods 5 sessions are created when I expected only one to be created. Any further suggestions? Cheers Luke. - Quoting luke noel-storr <[EMAIL PROTECTED]>: > Hi, > > I don't have a problem in terms of errors or crashes or anything; however, I > was > in fear of the rapidly increasing session count (into several thousands > after > just a few calls to a servlet I had). > > I shall now recode based on your advice though - thank you for your help. > > > Cheers > > Luke. > - > > > > Quoting Ingo Brunberg <[EMAIL PROTECTED]>: > > > Do you actually have a problem with open sessions or is you interest > > rather theoretical? > > > > As I explained some time ago, you should use WebdavResource in such a > > way that you call a WebdavResource constructor only once in your > > application. This way you have no more than one connection, so you > > should hit no resource limits, hence my question above. > > > > The reason that WebdavResouce.close() does not really close the > > connection is that this would lead to having to reconnect if a parent > > or a child obtained by calling listWebdavResources() or > > getChildResources() issues the next request. > > > > You may call this a design deficiency, but this is how you are > > cuurently supposed to work with the client library. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
Hi, I did a bit more investigate and found I had made a mistake. It wasn't getHttpURL() that was creating a new session, it was the methods of WebdavResource that used the HttpURL I had got (for example reportMethod) that were causing a new session to be created. So, it seems it is not getHttpURL() that is creating the session, but instead methods such as reportMethod() that take a HttpURL as a parameter. Cheers Luke. - On 10 May 2004, at 18:15, Ingo Brunberg wrote: This is indeed worth investigating. Calling getHttpURL() should really not create a new session. Maybe you can post a code snippet? Ingo After a bit more investigation, it seems that constructing a new HttpURL or using the getHttpURL() method of WebdavResource also creates a new session. Should it be doing this? Is there a way to avoid it doing so? There are some cases where I can see no way of doing what I want without constructing a new WebdavResource or a HttpURL. Cheers Luke. - Quoting luke noel-storr <[EMAIL PROTECTED]>: Hmm, either I misunderstood what you meant, or it doesn't quite fix things the way I expected. I now only construct one webdav resource in my code, however, after running just a few simple getMethods, propFindMethods and reportMethods 5 sessions are created when I expected only one to be created. Any further suggestions? Cheers Luke. - Quoting luke noel-storr <[EMAIL PROTECTED]>: Hi, I don't have a problem in terms of errors or crashes or anything; however, I was in fear of the rapidly increasing session count (into several thousands after just a few calls to a servlet I had). I shall now recode based on your advice though - thank you for your help. Cheers Luke. - Quoting Ingo Brunberg <[EMAIL PROTECTED]>: Do you actually have a problem with open sessions or is you interest rather theoretical? As I explained some time ago, you should use WebdavResource in such a way that you call a WebdavResource constructor only once in your application. This way you have no more than one connection, so you should hit no resource limits, hence my question above. The reason that WebdavResouce.close() does not really close the connection is that this would lead to having to reconnect if a parent or a child obtained by calling listWebdavResources() or getChildResources() issues the next request. You may call this a design deficiency, but this is how you are cuurently supposed to work with the client library. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide Tomcat Sessions - Closing them
Do you actually have a problem with open sessions or is you interest rather theoretical? As I explained some time ago, you should use WebdavResource in such a way that you call a WebdavResource constructor only once in your application. This way you have no more than one connection, so you should hit no resource limits, hence my question above. The reason that WebdavResouce.close() does not really close the connection is that this would lead to having to reconnect if a parent or a child obtained by calling listWebdavResources() or getChildResources() issues the next request. You may call this a design deficiency, but this is how you are cuurently supposed to work with the client library. Ingo > Hi, > > I posted a question a few days ago about Slide sessions within Tomcat not being > closed, when using the client Java API. > > I didn't notice any replies so thought I'd post again under a different subject. > > Anyway, if anyone has experiences of trying to close sessions within Tomcat from > within the client API then I'd be glad to hear about it. The .close() method of > a WebdavResource doesn't seem to be working. > > (I'm currently using verion 2.0rc1 on the client side - does the final version > fix this?). > > > Cheers > > Luke. > - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
