FusionReactor 6.2.7

87 views
Skip to first unread message

eleni_grosdouli

unread,
Dec 14, 2016, 5:59:21 AM12/14/16
to FusionReactor
Hi all,

The latest version of FusionReactor 6.2.7 has been released.

For more information about the release notes, please check out the link, FusionReactor 6.2.7 Release Notes. If you want to download the latest version available, check out the link, Download FusionReactor or access your FusionReactor Portal account, FusionReactor Portal.

Feel free to contact the FusionReactor Support Team (sup...@fusion-reactor.com) if you encounter any issues or if you have further questions about the new release.

Eleni

Tom Chiverton

unread,
Dec 23, 2016, 4:30:16 AM12/23/16
to FusionReactor
I see there is an update, FR6259, to do with cloned servers ? This is what we are using, so I wondered if you had some more details to share on that ?

Tom

Darren Pywell

unread,
Dec 23, 2016, 7:03:51 AM12/23/16
to FusionReactor
Hi Tom,

An issue that we run into sometimes is that people clone VMs with a completely configured FusionReactor. The problem is that FusionReactor generates and stores a unique ID in the reactor.conf file each for instance but the clones use the same one. When FusionReactor checks it's license, each of the clones check with the same ID causing issues in instances not being correctly licensed and sometimes loosing the activation. 

We've added a -Dfr.id option that allows the user to specify a unique ID for the instance instead of having to edit the reactor.conf file. This is easier to use in some environments if you can set something dynamically in the startup arguments of the VM. 

A good value for the option is to use the Hostname combined with the full path to the FusionReactor instance folder e.g.


The value needs to be unique for every instance and server to avoid the overlap even between servers, so you couldn't just use the instance path for example.

We are working on removing the need for this completely; we understand it's a pain for anyone that has cloned VM's etc, with FR pre-configured and licensed.

Cheers,
Darren

Tom Chiverton

unread,
Jan 17, 2017, 3:54:05 AM1/17/17
to FusionReactor
Thanks. At the moment we have to change several different FR config files after a clone in order to be able to put the clone into a cluster (think of how AWS ELBs start a new EC2 instance when load is high).
If that's now just a single parameter in the ColdFusion JVM settings that's much easier to manage.

Sounds like it's really just a environment finger print. If it doesn't have to mean anything ?
What's the result of setting this to a random value each time the JVM is started e.g.

-Drd.id=`$RANDOM`

Darren Pywell

unread,
Jan 17, 2017, 6:30:38 AM1/17/17
to FusionReactor
Hi Tom,

Using a RANDOM value for every restart of the JVM will mean that the JVM will be seen as a different instance. That's could cause issues with licensing eventually, so it would really be better to use something like the $HOSTNAME/instancepath We are aiming to have the same id each time restart so that the instance can be identified.

Cheers,
Darren
Reply all
Reply to author
Forward
0 new messages