Vaultpro JavaCLC runs out of memory when using -repository

[arthur5005]

Writing a plugin for my text editor in OS X.

I find that calling any command that requires for a repository to be defined causes the Java command line client to hang, then run out of memory. I can call commands such as LISTREPOSITORY and LISTUSERS just fine.

Also, important to note, if I define a repository that doesn't exists, the JavaCLC properly throws an exception telling me that the repository doesn't exist on the server. So this only happens when the client actually finds and connects to a repository.

=Environment=
OS:
Mac OS X 10.6.6

Vault JavaCLC:
vaultproJavaCLC_5_1_1_19216

Java Version:
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)


Example:
vaultpro LISTFOLDER -host vault.lmi-tech.com:9090 -user agoldsmith -password ******** -repository rd -norecursive $/Sensors/dev/RD/Gocator/Software/www

(15 minutes pass)
output:

Exception in thread "Poller SunPKCS11-Darwin" java.lang.OutOfMemoryError: Java heap space
at sun.security.pkcs11.wrapper.PKCS11.C_GetSlotInfo(Native Method)
at sun.security.pkcs11.SunPKCS11.initToken(SunPKCS11.java:767)
at sun.security.pkcs11.SunPKCS11.access$100(SunPKCS11.java:42)
at sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:700)
at java.lang.Thread.run(Thread.java:680)
<vault>
<error>
<exception>java.lang.OutOfMemoryError: Java heap space
at sun.util.calendar.CalendarDate.clone(CalendarDate.java:417)
at java.util.GregorianCalendar.clone(GregorianCalendar.java:1888)
at java.util.GregorianCalendar.getActualMaximum(GregorianCalendar.java:1823)
at java.util.GregorianCalendar.getMaximum(GregorianCalendar.java:1481)
at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2315)
at java.util.Calendar.updateTime(Calendar.java:2468)
at java.util.Calendar.complete(Calendar.java:1525)
at java.util.Calendar.get(Calendar.java:1131)
at system.DateTime.__Ctor__(Unknown Source)
at system.DateTime.__Ctor__(Unknown Source)
at VaultLib.VaultDate.__CreateClass__0x00000001(Unknown Source)
at VaultLib.VaultDate.EmptyDateTime(Unknown Source)
at VaultLib.VaultDateTime.<init>(Unknown Source)
at VaultLib.VaultDateTime.__CreateClass__0x00000001(Unknown Source)
at VaultLib.VaultDateTime.ToLocalTime(Unknown Source)
at VaultClientNetLib.VaultConnection.ReadFileDeltaFromStream(Unknown Source)
at VaultClientNetLib.VaultConnection.ReadFolderDeltaFromStream(Unknown Source)
at VaultClientNetLib.VaultConnection.ReadFolderDeltaFromStream(Unknown Source)
at VaultClientNetLib.VaultConnection.ReadFolderDeltaFromStream(Unknown Source)
at VaultClientNetLib.VaultConnection.ReadFolderDeltaFromStream(Unknown Source)
at VaultClientNetLib.VaultConnection.ReadFolderDeltaFromStream(Unknown Source)
at VaultClientNetLib.VaultConnection.ReadFolderDeltaFromStream(Unknown Source)
at VaultClientNetLib.VaultConnection.ReadFolderDeltaFromStream(Unknown Source)
at VaultClientNetLib.VaultConnection.ReadFolderDeltaFromStream(Unknown Source)
at VaultClientNetLib.VaultConnection.ReadFolderDeltaFromStream(Unknown Source)
at VaultClientNetLib.VaultConnection.GetRepositoryStructure(Unknown Source)
at VaultClientOperationsLib.ClientInstance.Refresh(Unknown Source)
at VaultClientOperationsLib.ClientInstance.Refresh(Unknown Source)
at VaultClientOperationsLib.ClientInstance.Refresh(Unknown Source)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Unknown Source)
at VaultClientIntegrationLib.ServerOperations.SetRepository(ServerOperations.cs:3518)
at VaultClientIntegrationLib.ServerOperations.SetRepository(ServerOperations.cs:3489)
</exception>
</error>
<result>
<success>False</success>
</result>

[Beth]

If you run the command line from another machine, does the same thing happen?

If you run the Windows command line from a Windows machine does the same thing happen?

The listfolder function is going to return far more data than the listuser or listrepository, so it's possible that you don't have the available memory to handle that much data. Compare a few machines and maybe try the command on the server as well.

[jclausius]

Another thing you could try is to increase the JVM heap size.

The -Xms### and -Xmx### may help.

For instance, adding "-Xms64M -Xmx768M" to the java command line will start the JVM with a heap of 64MB and allow it to grow to 768MB. Fine tuning those params may help getting the command line running on larger repositories.

[arthur5005]

Another thing you could try is to increase the JVM heap size.

The -Xms### and -Xmx### may help.

For instance, adding "-Xms64M -Xmx768M" to the java command line will start the JVM with a heap of 64MB and allow it to grow to 768MB. Fine tuning those params may help getting the command line running on larger repositories.

I tried this, and I've tried using the JavaCLC on a number of machines, nothing seems to have helped. We do work with a very, very large repo, although I will say, I'm surprised that this would have an effect; I'm asking the client to perform operations on much smaller subsets of the repository (for example, in a directory containing about a dozen files).

Is there something else I can try?

[jclausius]

How big did you try with the -Xmx argument? On the other machines did you use the Java client or the native .NET CLC?