On 2010-07-07 17:14, Tim Ellison wrote:
On 07/Jul/2010 05:49, Regis wrote:
On 2010-07-06 22:49, Jesse Wilson wrote:
On Sun, Jul 4, 2010 at 8:05 PM,<regi...@apache.org> wrote:
File.counter could be accessed by multiple threads, so use
AtomicInteger to
make
sure each thread using different int value to create temp file.
Is this a sufficient fix for the problem? The file system may be
shared by
multiple concurrently-executing VMs. Coordinating access to temp files
within a single VM doesn't prevent other processes from grabbing the same
file names.
A more robust solution might involve including the VM's process ID in the
filename. Or perhaps some kind of create-and-test protocol in a loop.
At r961242, I used counter value generated first time to identify
different VM instances, I think that's enough to avoid name conflicts.
Huh? adding more local counters into the string in this VM isn't going
to help.
How does this code identify the VM instance?
Regards,
Tim
I assume the following code can generate different values of counterBase for
different VMs:
int newInt = new SecureRandom().nextInt();
counter = ((newInt / 65535) & 0xFFFF) + 0x2710;
counterBase = counter;
counterBase do have chance to get the same value cross VM instances, but given
there would not be many VM instances running concurrently, this way can avoid
all most of conflicts with little extra efforts.
--
Best Regards,
Regis.
