river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MICHAEL MCGRADY <mmcgr...@topiatechnology.com>
Subject Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Fri, 03 Dec 2010 14:06:05 GMT
That is correct.  I do not think that River would be interested at this time in real-time constraints.
 It is too big a jump for this place in the history and I am just asking for an incremental
move to Java 1.5 from Java 1.4 to remain consistent with real-time JVMs.

MG

On Dec 2, 2010, at 11:38 PM, Patricia Shanahan wrote:

> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>> 
>> 
> 

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