Distributed SCM connection problems/timeouts. help! [solved]
just looking for anyones experience before involving support..
doing duplicate stream, 3.0.1.3 to 3.0.1.3 systems.
getting timeout and lock rollback errors.. not sure why the problems.. didn't happen last week.
have increased the timeout config on both servers.. no change.
all databases on Derby
|
2 answers
so, the answer is, increase the client timeout.. for PlainJava apps this is
ITeamRepository Server = TeamPlatform.getTeamRepositoryService().getTeamRepository(serverURI);
Server.registerLoginHandler(new LoginHandler(userId, password));
Server.setConnectionTimeout(master_connection_timeout);
Server.login(null);
this the ELAPSED time the client will stay connected. NOT per API call.
I also added error recovery, if the copy times out, I logoff, increase the prior timeout by 1 hour, and login again, then retry the failed operation. (after a little cleanup)
can someone mark this as the answer please
|
Hi Sam,
if the time out happens on the "client" side, how about configuring the timeout setting on the eclipse as the following jazz.net article described? (b. increase connection timeout section in the 5. Checklist) Flow changes cross repositories with Rational Team Concert https://jazz.net/library/article/535/ Comments
sam detweiler
commented Feb 02 '14, 5:03 a.m.
thanks..
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Sam,
given your high level of experience and outstanding reputation in our Jazz community I guess you have your own good reasons to run on Derby. Personally I have abandoned Derby even for demo and eval purposes.
Unfortunately I have no personal experience with distributed delivery timeouts - but I would highly recommend to involve support as early as possible rather than as late as possible. It comes free with maintenance and if they have the same fair chance as the board, it is an equal race to see who gets you the answer first.
- Arne
thanks.. I wouldn't use derby in production either. but the team that setup this one server used derby and I have to get their source off NOW, today, and their project stuff too.
:-)
Imagined it would be something like this. I am glad to hear the migration was successful and the team should be glad to have you as the able commander of their migration project.
Maybe just another example of the mantra taught to me by Ralph Schoon, to never use Derby even for an evaluation server, because most evaluation servers ends up being productive anyway.
oh how I wish! so far we have 3 of 150 workspaces.. even manual duplicate fails..
so close..
I really don't think this is a derby problem.. we are getting socket timeouts..
problem is I have no idea the DSCM code strategy. how the data objects move..
anyhow.. thx.. back to the grind stone today trying to figure out what to do. have a little over 48 hours to move the code twice. (ugh)