> -----Ursprüngliche Nachricht-----
> Von: Bert Huijben [mailto:bert_at_qqmail.nl]
> Gesendet: Mittwoch, 13. August 2008 15:11
> An: Michael Pfob; dev_at_subversion.tigris.org
> Betreff: RE: Problem with many svn operations in a short time
>
> > -----Original Message-----
> > From: Michael Pfob [mailto:m.pfob_at_3s-software.com]
> > Sent: woensdag 13 augustus 2008 13:43
> > To: dev_at_subversion.tigris.org
> > Subject: Problem with many svn operations in a short time
> >
> > Hello Subversion Developers,
> >
> > In my application, that is based on subversion, it is possible that
> > many
> > svn-operations are issued in a short period of time. In a windows
> > environment, problems will appear when you try to execute ~4000 svn
> > commands (like svn_client_log, svn_client_cat) using the svn protocol.
> > The reason for this problem is that windows does not allow to reuse the
> > client side of the sockets until about 4 minutes have passed. This
> > means
> > that it is not possible to execute more than 4000 subversion operations
> > in less than 4 minutes in a windows system.
>
> Hi Michael,
>
> Are you sure the limit is in Windows and not in some kind of firewall
> product?
>
> I know that ISA server imposes some of these limits and probably many
> other
> firewalls and maybe even routers do. (I had to lift those rules before we
> introduced a batch processing webrequest in one of our products at work).
Hello Bert,
As I have seen after my research, this is a limit of windows (could be adapted using the registry entry "MaxUserPort"). It looks like it is only possible to open about 4000 client sockets in a period of about 4 minutes ("TcpTimedWaitDelay").
>
> I can't imagine a case where executing 4000 svn_client_* function calls
> would really make sense.
> Most commands I would repeat allow multiple targets in 1.5. (But I know
> some
> of those are implemented as a top level loop over the parameter, so this
> wouldn't really help in this case.. But without those variants there is
> not
> much that can change as the client api doesn't keep connections open over
> different function calls).
The problem in our application is that we have a wrapper layer around the subversion interface. This wrapper does not work recursively (which is the default behaviour of subversion) and thus there may be those many requests in our System because every single file is requested using it's own svn_client_* call.
>
> (Maybe you should look at the lower level c-APIs to take advantage of a
> reusable session for your specific use case)
Thank you, this could be an idea for a better workaround to the problem.
>
> > I think this behaviour could also be reproduced using a script
> > triggering
> > the svn command line client.
> > In my opinion, this problem would disappear, when the client side
> > sockets
> > would be used with the socket option DONT_LINGER or REUSEADDR. Is there
> > a technical reason why these options are not used? In other words,
> > would it be possible to fix this issue in a future version of the
> > subversion libraries.
>
> DONT_LINGER is the default setting if I read the winsock documentation
> correctly and REUSEADDR is only valid on incoming connections (which the
> client has none).
>
> So, unless your question applies to the server side I think neither of
> those
> settings apply?
I am not a real socket expert but as I have read in some webpages (eg. http://forums.sun.com/thread.jspa?messageID=4377478), this limit might cause an error when opening too many client sockets too. In this case the error EADDRINUSE is returned as result to a connect call. This could be prevented using the REUSEADDR option.
>
> > During my research I have found a discussion with the title
> > "[Subclipse-dev] Excessive use of TCP sockets" about a similar problem
> > on this mailing list, but I was not able to extract a solution for my
> > problem.
> >
> > Do you have a hint for my problem? At the moment I am using an ugly
> > workaroung to prevent this problem (waiting until sockets can be opened
> > again).
> >
> > If you have further questions, please don't hesitate to ask.
>
> Bert
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-13 17:45:12 CEST