So users will have problems with load-balancing if they use
--systemproperties with create-instance/create-local-instance (unless
they define all the ports in the system properties)?
If so, then maybe we should try to fix
http://java.net/jira/browse/GLASSFISH-15683 for 3.1.
On 1/25/2011 2:04 PM, Ken wrote:
> On 01/25/11 11:01 AM, Gopal Jorapur wrote:
>> Ken wrote:
>>
>>> On 01/25/11 08:36 AM, Ken Cavanaugh wrote:
>>>
>>>> On Jan 25, 2011, at 8:27 AM, Tom Mueller wrote:
>>>>
>>>>
>>>>> The reason for this is that there is a bug in the code that
>>>>> replicates the system property information for instances. As long
>>>>> as no --systemproperties option is provided on the create-instance
>>>>> or create-local-instance command, then the replication works fine.
>>>>> However, if there is a --systemproperties option, then only that
>>>>> system property is replicated to the other instances. A restart of
>>>>> the instance that does a resync will bring over the rest of the
>>>>> properties.
>>>>>
>>>>> I created issue 15683 for this:
>>>>> http://java.net/jira/browse/GLASSFISH-15683
>>>>>
>>>>> As with the other problem with system properties, the work-around
>>>>> is again to not use the --systemproperties option on the
>>>>> create-instance command.
>>>>>
>>>>> Is 15683 a stopper for 3.1?
>>>>
>>
>>>>
>>>> I'm not sure. I can probably rewrite the test framework to specify
>>>> IIOP_LISTENER_PORT using create-system-properties,
>>>> and work around this. Will create-system-property --targetserver
>>>> testInstance0 IIOP_LISTENER_PORT=20037
>>>> (not sure about the syntax) replicate the value of
>>>> IIOP_LISTENER_PORT for testInstance0 to all other instances in
>>>> the cluster?
>>>> I'll try this later this morning and let you know.
>>>>
>>>> If I have a workaround, this at least needs to be covered in the
>>>> release notes, to keep other from failing into the same hole.
>>>> By the way, I think this also affects Server.isRunning, which is
>>>> possibly getting the wrong admin port when it attempts
>>>> to verify the instance is up by checking for admin listening on a
>>>> particular port.
>>>>
>>>
>>> The workaround works for me. I no longer set system properties on
>>> the create instance command.
>>> It turns out that I do use system properties for one other purpose:
>>> turning on ORB debug flags in
>>> instances. So I just changed the code to use
>>> create-system-properties for that purpose.
>>> My test is now passing, so I should be able to commit a few changes
>>> for 14687 (avoiding
>>> Server.isRunning on the instances, which fails because of 15683) and
>>> (finally!) resolve the issue.
>>>
>>> Looks like 15683 just needs a release note for GF 3.1.
>>>
>>> Gopal, please make sure that you don't specify system properties on
>>> any create-instance calls
>>> in your tests.
>>
>>
>> My tests dont specify system properties, they use default
>> create-instance, the test is still failing, have you made any fixes ?
>> I am using 24th nightly
>>
> Yes. I am putting together a commit right now.
>
> Ken.