It's all about the answers!

Ask a question

Make lscm daemon forget about a sandbox?


Jeff Care (1.0k3233) | asked Feb 17 '11, 4:03 p.m.
retagged Dec 02 '13, 3:25 p.m. by David Lafreniere (4.1k7)
How do I make the lscm daemon forget about a sandbox that I loaded?

Consider this sequence:

$ lscm login ...

$ lscm load -r ... --all MY_WORKSPACE
$ rm -rf *
$ mkdir sourceroot
$ lscm load -r ... -d sourceroot -all MY_WORKSPACE


I loaded a workspace to my sandbox, then decided that I actually wanted to load it into a different directory that is one level below the current working directory. I thought that deleting the code and the Jazz/Eclipse metadata dirs would be enough, but when I go to do the load into the sub-directory I get this error:

Cannot load. Request overlaps with existing sandbox.

<redacted>
org.eclipse.core.runtime.OperationCanceledException
at com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager$1.run(ResourceSharingManager.java:204)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at com.ibm.team.filesystem.rcp.core.internal.resources.ResourceSharingManager.runWithinFileSystemLock(ResourceSharingManager.java:212)
at com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:164)
at com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.runWithinFileSystemLock(FileSystemOperation.java:144)
at com.ibm.team.filesystem.client.internal.operations.LoadOperation.execute(LoadOperation.java:657)
at com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:89)
at com.ibm.team.filesystem.cli.client.internal.subcommands.LoadCmd.run(LoadCmd.java:229)
at com.ibm.team.filesystem.cli.client.internal.subcommands.LoadCmdLauncher.run(LoadCmdLauncher.java:193)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(SubcommandLauncher.java:622)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.doStart(SubcommandLauncher.java:365)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(SubcommandLauncher.java:148)
at com.ibm.team.filesystem.cli.client.internal.daemon.CommandLineClient.handleRequest(CommandLineClient.java:135)
at com.ibm.team.filesystem.client.internal.http.ProtocolSwitchingHttpHandler.handle(ProtocolSwitchingHttpHandler.java:46)
at com.ibm.team.filesystem.client.internal.http.HttpConnection.readNextRequest(HttpConnection.java:628)
at com.ibm.team.filesystem.client.internal.http.HttpConnection$1.run(HttpConnection.java:470)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Problem running 'load':
Unexpected cancellation.


It seems that somehow the lscm daemon remembers that I loaded a the repository to a parent directory to where I want to load it now, even though I've deleted all of the content. How do I make lscm forget this? There doesn't seem to be an lscm unload command...

Accepted answer


permanent link
Evan Hughes (2.4k1018) | answered Feb 18 '11, 5:02 p.m.
JAZZ DEVELOPER
The daemon doesn't persist the sandbox locations, so stopping the daemon will flush its little mind.

Once the daemon is stopped, you can delete the sandbox that you want to get rid of.

See bug 92996 for an 'unload' feature request.
Jeff Care selected this answer as the correct answer

Comments
Andy Jewell commented Oct 16 '13, 1:54 p.m.

But how do we stop the daemon?  I'm getting the same issue, I tried logging out of lscm but when I logged back in, I get the same error but with a different port:

[tomcat@pzxdcc048 workspace]$ lscm load -r local -i -d arfpoc --force 'mbe release preprod build'
com.ibm.team.filesystem.client.rest.exceptions.SandboxRegistrationException: Sandbox /users/tomcat/.jenkins/jobs/ARFGENPOC/workspace/arfpoc already owned by daemon running on port 48526.
        at com.ibm.team.filesystem.rcp.core.internal.rest.FilesystemRestClient.countMySandboxes(FilesystemRestClient.java:1993)




Andy Jewell commented Oct 16 '13, 1:56 p.m. | edited Oct 16 '13, 1:57 p.m.

 Incidentally, I get the same error using scm:

[tomcat@pzxdcc048 workspace]$ scm load -r https://cn068brld240.wpoc.kp.org:9443/ccm/ -u userid -P 'passwd' -i -d arfpoc --force 'mbe release preprod build'
com.ibm.team.filesystem.client.rest.exceptions.SandboxRegistrationException: Sandbox /users/tomcat/.jenkins/jobs/ARFGENPOC/workspace/arfpoc already owned by daemon running on port 48526.
        at com.ibm.team.filesystem.rcp.core.internal.rest.FilesystemRestClient.countMySandboxes(FilesystemRestClient.java:1993)

Ugh!

One other answer



permanent link
Jonathan Weeks (1) | answered Nov 12 '12, 3:21 p.m.
This doesn't appear to be a problem with "scm".  I had the same issue as described above and changed my process to use "scm" instead of "lscm" and the directory was no longer recognized.

Comments
Jeff Care commented Nov 12 '12, 3:38 p.m.

Right - this isn't a problem for the scm command but then you don't get the performance benefits of lscm.

"Don't use lscm" isn't an acceptable answer.

Your answer


Register or to post your answer.