From jeroenooms at gmail.com  Fri Jun 20 04:32:51 2014
From: jeroenooms at gmail.com (Jeroen Ooms)
Date: Thu, 19 Jun 2014 19:32:51 -0700
Subject: [Rd] problem using rJava with parallel::mclapply
In-Reply-To: <2EEA1904-0556-4D37-9492-A54D77EF3B52@r-project.org>
References: <CAMd4_Ac0=DvjjChhQ2SHxYeA3YNUKhsz7+vjZ=+VDtTR5ojJ6Q@mail.gmail.com>
	<2EEA1904-0556-4D37-9492-A54D77EF3B52@r-project.org>
Message-ID: <CABFfbXuxXeGR_a5tj3kjLsQFXo5QakYW7Vr-4hDt=BGxMUB5zg@mail.gmail.com>

On Mon, Nov 11, 2013 at 6:20 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
>
> It?s a limitation of the Java runtime - you cannot fork a JVM. This is true for most libraries that use long-lived threads or any kind if UI (see the warnings in mcfork).

Is there some way to reset or restart the JVM within the fork? For
example, the following code seems to work in the terminal on mac/linux
(not in macgui):

library(rJava)
library(parallel)
myfile <-  system.file("tests", "test_import.xlsx", package = "xlsx")
mccollect(mcparallel({xlsx::read.xlsx(myfile, 1)}))

But if we load the 'xlsxjars' package in the parent process, the
example does not work anymore as Simon explained:

library(xlsxjars)
mccollect(mcparallel({xlsx::read.xlsx(myfile, 1)}))

Would there be a way to work around this by manually forcing a reset
of the JVM in the child process, in order to get the similar behavior
as if the 'xlsxjars' package was not loaded in the parent process? I
tried unloading 'xlsxjars' with ?detach, but that seems to make things
worse.



[Rd] problem using rJava with parallel::mclapply
Jeroen Ooms