I agree, lot of users use --systemproperties , its better to fix this issue
Thanks,
Gopal
Jennifer Chou wrote:
> 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.
>