severe problem, using wrong SVN URL

Hello,

this is a really severe bug, that caused some real frustration here,
and also consumed a lot of time.
Guys, you are causing some people to work on weekends here...

1. we use SVN repository with one directory as svn:external (don't know if this is relevant)
2. when we need a build on a new branch, we use some existing project,
copy it, then edit the SVN URL, save it.
we have the "enable VCS triggered build" check marked.
upon saving, TC immediately starts to build - all looks well.
3. you wait 30 minutes, then take your fresh build to the target,
start some debugging and then you start to wonder.
after lot of frustration you realize that teamCity has not built from the URL
that it stated, but instead from the original URL.

Arrrrrghhh - sorry! ;)

Let me know what I can provide you, to maybe fix this!!!!

I should add that this is tc version 4261
and (I think) svnserve, Version 1.4.2 (r22196) on Fedora Core 6

Message was edited by:
Michael Damberger

46 comments
Comment actions Permalink

Hi Pavel,

I try to answer the questions:
the password is not entered at all. This happens during copy project,
and the old password is just reused (no typing involved).
the browser character encoding is german, locale on tc server is german too.
- no firefox plugins.

Maybe this is a performance problem - I will try to get an additional build machine
set up (currently we use 2, one server AND agent), see my other post.


Best regards,
Michael

0
Comment actions Permalink

... just recognized that I missed some posts here, sorry.
I will try to get the build agent on the server "outsourced", and when this will not fix the problem, then I will file a JIRA issue.


Bye,
Michael

0
Comment actions Permalink

found this on the console:
WARN - org.apache.xmlrpc.WebServer2 - java.net.Soc
ketTimeoutException: Read timed out

0
Comment actions Permalink

queue; name=RADIO DI_VAG_HMI_7.0V36 :: ARM build, requestor=Stephan ABCDEF, comment=null, user=null
INFO - r.serverSide.impl.BuildStarter - jetbrains.buildServer.serverSide.ExecutionException: jetbrains.buildServer.xmlrpc.RemoteCallException: Call http://192.168.23.162:9090/RPC2 buildAgent.run: java.net.SocketTimeoutException: Read timed out
jetbrains.buildServer.serverSide.ExecutionException: jetbrains.buildServer.xmlrpc.RemoteCallException: Call http://192.168.23.162:9090/RPC2 buildAgent.run: java.net.SocketTimeoutException: Read timed out
at jetbrains.buildServer.serverSide.impl.XmlRpcBasedAgent.run(XmlRpcBasedAgent.java:14)
at jetbrains.buildServer.serverSide.impl.BuildStarter$1.run(BuildStarter.java:7)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: jetbrains.buildServer.xmlrpc.RemoteCallException: Call http://192.168.23.162:9090/RPC2 buildAgent.run: java.net.SocketTimeoutException: Read timed out
at jetbrains.buildServer.xmlrpc.AbstractXmlRpcTarget.call(AbstractXmlRpcTarget.java:23)
at jetbrains.buildServer.serverSide.impl.XmlRpcBasedAgent.run(XmlRpcBasedAgent.java:70)
... 7 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStrea

0
Comment actions Permalink

What java version do you use for your TeamCity server? If you are using Java
1.6 could you please try to switch to the latest Java 1.5 and check whether
the problem appears?

--
Pavel Sher
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"



"Michael Damberger" <michael.damberger@t-online.de> wrote in message
news:242773.1192704592677.JavaMail.itn@is.intellij.net...

Hi Pavel,

>

I try to answer the questions:
the password is not entered at all. This happens during copy project,
and the old password is just reused (no typing involved).
the browser character encoding is german, locale on tc server is german
too.
- no firefox plugins.

>

Maybe this is a performance problem - I will try to get an additional
build machine
set up (currently we use 2, one server AND agent), see my other post.

>
>

Best regards,
Michael



0
Comment actions Permalink

java version "1.5.0_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)

0
Comment actions Permalink

Michael,

Performance issues, CPU load should not be relevant.
The connection errors in the log are "normal" - these are errors communicating with some clients and should not affect the server.

The problem also does not seem to be connected with the build agent anyhow... At least for the time being. So let's investigate server environment at first.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

Michael,

Sorry for the inconvenience with the issue: we just have no clues for now as to what may be it's origin.

The environment seems quite typical...
Do you use .exe TeamCity distribution?

The current workaround seems to manually reenter the password each time the VCS root is copied.

It would help a lot if you can find/describe the steps to reproduce the problem.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

hm, no. i think teamcity's own jre is used via the runall.bat
C:\TeamCity2.1.1\jre\bin

Maybe this is in some way relevant: we do not use the windows services,
but start via runAll.bat instead.

0
Comment actions Permalink

thanks for the replies...

Yes, I used the windows installer.

The problem is not occuring 100% reproducable, only from time to time.
But when it occurs, the steps are easy:
1. copy project
2. edit SVN URL -> BANG!

0
Comment actions Permalink

confirmed that CPU load is not the problem.
I had the build agent on the server machine deactivated,
yet the problem just occured again with a different user, different password, on a different machine.

Unfortunately the user made no screenshot of the error popup in the browser, which he received. I immediately restarted teamcity, which probably was a mistake regarding reproducability. Because when trying afterwards, the problem did not reappear.

I instructed everybody to make a screenshot next time.... to capture this beast ;)


M.

0
Comment actions Permalink

just to be on the safe side
now installed jdk1.5_13 and rebooted the server.
Let's see... ;)

0
Comment actions Permalink

Michael,

Investigating the issue we have made several changes to improve processing user-supplied data in respect to codepages and this can fix the problem you encountered. But since we cannot reproduce the problem at our side, we can't be sure.

The next EAP build is planned to be released within the next two weeks, so I would appreciate if you can try it then and let us know if the issue comes back again.

For the time being, reentering the password on any VCS root saving should help.

Sorry for the inconvenience.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

I got a screenshot now. the browser was IE7, editVcsRoot.html the error popup said
"error accessing server"
then another followed, saying
" 'null' is null or no object"

0
Comment actions Permalink

Michael,

Thank you.

I've created an issue to ensure such errors are reported in some user-friendly way to a user: http://www.jetbrains.net/jira/browse/TW-3620

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Please sign in to leave a comment.