VCS Executor thread pool size configuration

Is there a property in internal.properties that I can use to increase the default VCS thread pool size of ten?

I have a bunch of CVS VCS roots, and the teamcity-vcs.log indicates the server is spending several minutes collecting changes on the VCS root.
On the CVS server side, the check does to take that long- and I always see exactly ten threads with established socket connections to the CVS server.
I'd like to increase the number of established connections from Teamcity to our CVS server.

here's one of the ten threads, named "VCS Executor [1-10]":

"11:48:35 Collect changes for cvs: :pserver:ecommbuild@cvs.dev.prognet.com:/home/np app/ecommerce/ecws {instance id=23407, parent id=487}; revs: [2011/11/13 12:22:54 -0800->null]; 11:48:35 Loading VCS changes for cvs: :pserver:ecommbuild@cvs.dev.prognet.com:/home/np app/ecommerce/ecws {instance id=23407, parent id=487}; VCS executor 9 {id=23407} {id=23407}" prio=10 tid=0x7e5bf400 nid=0x6742 runnable [0x7d80b000]

   java.lang.Thread.State: RUNNABLE

        at java.net.SocketInputStream.socketRead0(Native Method)

        at java.net.SocketInputStream.read(SocketInputStream.java:129)

        at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

        at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)

        at java.io.BufferedInputStream.read(BufferedInputStream.java:317)

        - locked <0xf39a9db8> (a java.io.BufferedInputStream)

        at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:221)

        at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:141)

        at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:105)

        at jetbrains.buildServer.buildTriggers.vcs.cvs.CvsCommandSessionBase$3.read(CvsCommandSessionBase.java:89)

        at jetbrains.buildServer.buildTriggers.vcs.cvs.CvsCommandSessionBase$3.read(CvsCommandSessionBase.java:100)

        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)

        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)

        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)

        - locked <0xf39aa088> (a java.io.InputStreamReader)

        at sun.nio.cs.StreamDecoder.read0(StreamDecoder.java:107)

        - locked <0xf39aa088> (a java.io.InputStreamReader)

        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:93)

        at java.io.InputStreamReader.read(InputStreamReader.java:151)

        at org.netbeans.lib.cvsclient.RequestProcessor.readResponse(RequestProcessor.java:267)

        at org.netbeans.lib.cvsclient.RequestProcessor.handleResponses(RequestProcessor.java:247)

        at org.netbeans.lib.cvsclient.RequestProcessor.processRequests(RequestProcessor.java:172)

        at org.netbeans.lib.cvsclient.RequestProcessor.processRequests(RequestProcessor.java:90)

        at jetbrains.buildServer.buildTriggers.vcs.cvs.RlogCommand.execute(RlogCommand.java:44)

        at jetbrains.buildServer.buildTriggers.vcs.cvs.CvsCommandExecutor.executeServerCommand(CvsCommandExecutor.java:93)

2 comments
Comment actions Permalink

Of course there is :)
The property is called: teamcity.threadpool.vcsexecutor.threads.max, default value is 10.
You need to specify it in .BuildServer/config/internal.properties file. Server must be restarted to pick up the change.

To speedup changes collecting and if your CVS server supports history command you can try to enable "history command" support in VCS root, usually it works faster than cvs rlog. If it is already enabled, then probably your CVS server does not support this command.

0

Please sign in to leave a comment.