river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Fri, 03 Dec 2010 06:50:18 GMT
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