It's all about the answers!

Ask a question

Distributed SCM connection problems/timeouts. help! [solved]


sam detweiler (12.5k6189201) | asked Jan 31 '14, 8:13 a.m.
edited Feb 02 '14, 9:26 a.m.
 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

Comments
Arne Bister commented Jan 31 '14, 4:12 p.m. | edited Jan 31 '14, 4:13 p.m.
JAZZ DEVELOPER

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


1
sam detweiler commented Jan 31 '14, 5:17 p.m.

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.


the project stuff has been successfully migrated..  workitems are loading now, link fixup to go tonight.. source is the problem.. 

the interim server is derby cause its supposed to last at most a couple days.. 
and it matches the incoming system..

I appreciate your answer however.. thank you.. 


Arne Bister commented Feb 01 '14, 3:02 a.m.
JAZZ DEVELOPER

:-)
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.


sam detweiler commented Feb 01 '14, 6:30 a.m.

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)

2 answers



permanent link
sam detweiler (12.5k6189201) | answered Feb 02 '14, 9:15 a.m.
edited Feb 02 '14, 9:25 a.m.
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


permanent link
Shuhichi Saitoh (20048) | answered Feb 02 '14, 1:30 a.m.
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..

sadly the timeout error does not say where.

even when we use the Eclipse UI, with timeout set to 9999 we still encounter the error sometimes.

now. working with  with support we did change the config on both servers to increase the JVM memory.  AND I found the api to set the connection timeout in my plainjava app.

the default timeout of 480 seconds (8 mins) turns out to be the magic number indicator,

in my initial testing a few weeks back, nearly all the copies finished in 2-3 minutes.

with the prioritized list of users, the master build users workspaces take 9-12 minutes.
all beyond the 8 minute default!..

changing the timeout to 9999 seconds (2hrs 50 mins) has allowed the utility to process large workspaces (12 in  row as of when I left at 10pm last night) without problem.
(I go back in to resume the migration in an hour)

if the error had had ONE more word.. 'client' socket timeout.

Your answer


Register or to post your answer.