Running Java remotely using PowerShell

Question

When I run PowerShell in a remote session (etsn {servername}), I sometimes can't seem to run Java processes, even the most simple:

[chi-queuing]: PS C:\temp> java -cp .\hello.jar Hello
Error occurred during initialization of VM
Could not reserve enough space for object heap

Hello.jar is an "Hello, world!" application that should just print "Hello" to standard output.

So, the question is, is there something special about running processes on the other side of a PowerShell session? Is there something special about how the Java VM works that might not allow treatment like this? The memory is allocated on the remote computer, right? Here is a readout on the physical memory available:

[chi-queuing]: PS C:\temp> $mem = Get-wmiobject -class Win32_OperatingSystem
[chi-queuing]: PS C:\temp> $mem.FreePhysicalMemory
1013000

But, when I remote desktop to the server and ask the OS how much free memory there is, it says 270 MB physical memory free. Let me know what you think!

Answer 1

According to this: http://msdn.microsoft.com/en-us/library/aa384372(VS.85).aspx

MaxMemoryPerShellMB Specifies the maximum amount of memory allocated per shell, including the shell's child processes. The default is 150 MB.

Increase Max Memory Per Shell MB

winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="1000"}' 

Answer 2

I have a different answer to share with you guys. I found myself in the same situation and increasing memory min/max for Java.exe or using winrm did NOT solve my issue.

I compared two servers: one working and one not working.

I used this link https://technet.microsoft.com/en-us/library/ff520073%28v=ws.10%29.aspx to check my Windows Management Foundation wich is needed to run WINRS and also remote powershell.

the result: Both servers running Windows Server 2008 R2. One server running WMF 2.0, one running WMF 3.0.

To my surprise, the server running 2.0 was working and the one running 3.0 was NOT!

My solution: I upgraded the 3.0 WMF to 4.0!

Answer 3

Just a fyi: we suffered the same symptoms, and had an endless investigation based on the other two answers. The actual solution for us was changing jdk1.8.0_31 to jdk1.8.0_51.