river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Fri, 03 Dec 2010 07:38:15 GMT
I think we may be getting distracted from the key objective if this 
thread, nailing down our JVM version policy for the next few releases.

Do we have any indication of a need for real time constraints in River? 
I don't think Michael has asked for anything beyond keeping River JVM 
version compatible with Java RT.

Patricia


On 12/2/2010 10:50 PM, Peter Firmstone wrote:
> What I'm trying to say is, that a Service and Client each running on
> RTSJ, could set real time constraints, as we now might set a
> ServerMinPrincipal constraint, meaning that if real time was required
> over EtherCAT, this could be supported by some services and clients that
> require it while others may not require it in the same environment.
>
> Currently constraints are used to enforce:
>
> 1. Confidentiality
> 2. Integrity
> 3. Authentication
> 4. Authorization
>
> If we supported RTSJ we could add:
>
> 5. Real Time
>
> Just a thought.
>
>
>
> Mike McGrady wrote:
>> Abandoning Java RT is not in the cards for us.
>>
>> Sent from my iPhone
>>
>> Michael McGrady
>> Principal investigator AF081_028 SBIR
>> Chief Architect
>> Topia Technology, Inc
>> Work 1.253.572.9712
>> Cel 1.253.720.3365
>>
>> On Dec 2, 2010, at 10:12 PM, Peter Firmstone <jini@zeus.net.au> wrote:
>>
>>> It may be possible to add real time constraints.
>>>
>>> For example, EtherCAT supports real time networking, a client and
>>> server could set a real time constraint and communicate over EtherCAT.
>>>
>>> The question that Dennis has posed though is how much do you need?
>>> This doesn't have to be decided now, perhaps you can set up an issue
>>> on jira so we can track it.
>>>
>>> The current release still runs on Java 5. The next release due soon
>>> will too, the following release may not, but time will help us decide
>>> how solve this problem.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>> Dennis Reedy wrote:
>>>> What boggles my mind here is adding real-time requirements in the
>>>> same context of Jini. While you may have real-time threads, once you
>>>> touch the network your real-time QoS goes out the window. You may be
>>>> able to guarantee that the amount of time it takes to perform an
>>>> operation will be done within a bounded time, but you will not be
>>>> able to guarantee (in a real-time context) that the result of that
>>>> operation will be transmitted over the media to a requesting client.
>>>>
>>>> What I'd like to find out from Michael here is what exactly are the
>>>> RT requirements for River?
>>>>
>>>> Service Infrastructure (JoinManager and the like...)
>>>> Services (Reggie, Mercury, Outrigger, etc...)
>>>>
>>>> Other?
>>>>
>>>>
>>>> On Dec 2, 2010, at 104AM, MICHAEL MCGRADY wrote:
>>>>
>>>>
>>>>> We do this now with Java 1.5, Greg. Java RT 2.1 (64 bit) is
>>>>> compatible with Java 1.5. http://preview.tinyurl.com/2bpjqfh There
>>>>> would be no other test than works-with-Java-1.5. The simple answer
>>>>> is that if River does not call real-time threads and uses Java 1.5
>>>>> there is no issue. There are other things that impact real-time but
>>>>> we can cover those.
>>>>>
>>>>> MG
>>>>>
>>>>> On Dec 1, 2010, at 9:00 PM, Greg Trasuk wrote:
>>>>>
>>>>>> On Wed, 2010-12-01 at 23:33, Mike McGrady wrote:
>>>>>>> Like I said, Java 1.6 is incompatible with Java RTS and that
os
>>>>>>> very serious in my neighborhood. We do QoS with Java RTS.
>>>>>>>
>>>>>> That's certainly an interesting comment... I'm curious though: I
>>>>>> haven't
>>>>>> looked at RT Java for several years, but I recall that the first
pass
>>>>>> allowed plain Java (i.e. non-real-time) to be executed. Would River
>>>>>> components need some other evaluation or testing to be accepted as
>>>>>> "real-time" (which I doubt would be an easy task), or would you
>>>>>> just be
>>>>>> looking for compatibility with the run-time environment, but without
>>>>>> real-time guarantees?
>>>>>>
>>>>>> Also, what would be the impact if the RT system called services that
>>>>>> were resident in a non-RT virtual machine? Specifically, would the
>>>>>> registrar and/or JavaSpaces implementation need to be hosted in a
>>>>>> Java
>>>>>> RTS virtual machine?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Greg.
>>>>>>
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>> Michael McGrady
>>>>>>> Principal investigator AF081_028 SBIR
>>>>>>> Chief Architect
>>>>>>> Topia Technology, Inc
>>>>>>> Work 1.253.572.9712
>>>>>>> Cel 1.253.720.3365
>>>>>>>
>>>>>>> On Dec 1, 2010, at 5:03 PM, Patricia Shanahan <pats@acm.org>
wrote:
>>>>>>>
>>>>>>>> On 12/1/2010 4:53 PM, Dennis Reedy wrote:
>>>>>>>> ...
>>>>>>>>> Some of the discussion has referenced Java CDC on BlueRay.
Should
>>>>>>>>> these platforms have an overriding influence on whether
River
>>>>>>>>> moves
>>>>>>>>> forward and adopts 1.6 as a baseline? I'm not so sure
at this
>>>>>>>>> point.
>>>>>>>> Is the relevant Java dialect identical to 1.4? If not, we
would
>>>>>>>> need a separate project to make portions of River run on
it.
>>>>>>>>
>>>>>>>> Patricia
>>>>>> --
>>>>>> Greg Trasuk, President
>>>>>> StratusCom Manufacturing Systems Inc. - We use information
>>>>>> technology to
>>>>>> solve business problems on your plant floor.
>>>>>> http://stratuscom.com
>>>>>>
>>>>> Michael McGrady
>>>>> Chief Architect
>>>>> Topia Technology, Inc.
>>>>> Cel 1.253.720.3365
>>>>> Work 1.253.572.9712 extension 2037
>>>>> mmcgrady@topiatechnology.com
>>>>>
>>>>>
>>>>>
>>>>
>>
>
>


Mime
View raw message