Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Why do I get a "sandbox in use" error when nothing else is using the sandbox?

Questions
Tags
Users
Badges
Andy Jewell
(242●3●63●74) edited
Feb 19 '15, 2:47 p.m.
I had been using lscm for batch scripting and occasionally I would get a hung process.  Searching the forum provided some insights and a suggestion to use scm for scripting rather than lscm due to the risk of the lingering daemon process causing the JVM shell Process to think the process was not done.  So I changed to scm and now, ironically, I am getting this error: 

Caused by: org.gradle.internal.UncheckedException: ** LSCM ERROR:The sandbox is in use by another RCP process (an eclipse GUI or another Rational Team Concert source control command line client). **
I say ironic because now that I'm using scm there are no sandbox daemons running - AT ALL.  So why do I get this error?  I've tried deleting and reloading the sandbox but it doesn't help.

UPDATE 2/19/15: 

Based on suggestions of IBM tech (as well as Shashikant, below), I added some wait time in between commands and that helped quite a bit with the error code 27 (sandbox in use) problem.  The situation has not evolved into another one:

1.  I tried watching for a "metadata/.lock" file but none appeared (at least in the interval that I watched it for)
2.  I tried starting a daemon on the workspace by path but this didn't seem to have any effect
3.  I tried a 2 second delay but still ran into the problem
4.  I went up to a 5 second delay and things improved quite a bit, I have not received the error code 27.  However, I am seeing a lot of this error: Job found still running after platform shutdown.

I'm subscribed to workitem 49609 ("jobs founds still running") but I'm inclined to think that the first scm issue is a defect in its own right, wouldn't you say?  I should be able to execute a series of scm commands without putting in an arbitrary wait time.

In any case, if I had a working workaround, it wouldn't be a big deal but the .snap file resolution didn't seem to work.

- Andy

0 votes

1 answer
3,931 views
0 votes

One answer

Permanent link
Shashikant Padur
JAZZ DEVELOPER (4.3k●2●7) Feb 18 '15, 10:51 p.m.
Do you have any RTC Eclipse client running? If not, can you check if you have any java process running that was started by scm command line or RTC Eclipse client? At times these processes could linger if the application was terminated abruptly.

1 vote

Comments
Andy Jewell
Feb 19 '15, 2:46 p.m.

 HI, Shashikant... No, no Eclipse running but I was running a series of commands in the same sandbox which may have accounted for it.  I added a delay between commands which has helped but I'm getting a new problem (see updated question) with "jobs found still running".  If I don't need the workspace, can I just catch this error and delete the whole workspace?  Or put a better way, what's a good workaround for this issue?

Evan Hughes
JAZZ DEVELOPER Feb 19 '15, 4:53 p.m.

The CLI locks the entire sandbox while it's running, so you can't run two CLI instances on the same sandbox simultaneously. If you want to do that, you can use 'lscm' and a daemon. 


The lingering jobs thing shouldn't have an effect on the validity of the sandbox. 

1 vote

Andy Jewell
Feb 20 '15, 3:02 p.m.

Hmm, that's helpful but it's not my case, we are only using one CLI.  The commands are not ran in parallel, they are in sequence.  It will be rolling along just find and then at some point (it varies), will blow up with the error code 27.

Your answer

Register or log in to post 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 158

Question asked: Feb 18 '15, 1:02 p.m.

Question was seen: 3,931 times

Last updated: Feb 20 '15, 3:02 p.m.

Confirmation Cancel Confirm