river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Sat, 04 Dec 2010 15:24:29 GMT
We cannot throw our functionality into a client.  We are resident in the space.

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 3, 2010, at 6:45 PM, Peter Firmstone <jini@zeus.net.au> wrote:

> As I suspected the suggestion would reveal Michael's needs for RTSJ.
> 
> We've established no one needs a real time server PLATFORM service, this means that the
existing service implementations don't need to run on RTSJ, only the proxy's and a core platform
for producing application services.
> 
> If we make River modular, Patricia can work on the Javaspace server implementation so
it can utilise the latest platform concurrency features.  Therefore to run a Javaspace server,
it must be installed the Java 1.6 platform.  The same can apply for Reggie, Mahalo and all
the other service servers.
> 
> You can still use a Javaspace service on a RTSJ client, to produce information for the
Javaspace cloud, where it can be processed using the producer consumer pattern.
> 
> Modularity is the Solution to multi platform support.
> 
> Where earlier Java platforms can participate, but don't provide platform services, only
consume them.
> 
> The Service Implementations need to be separated from the River Jini Platform codebase.
> 
> This massively reduces the maintenance required to support earlier platforms.
> 
> I don't need to run any Platform service on BlueRay either.
> 
> Even if we don't call it modularity, River should be broken up, all the services can
be subprojects, they can evolve at their own pace and needs, without being held back by earlier
Java platform support requirements.
> 
> Cheers,
> 
> Peter.
> 
> MICHAEL MCGRADY wrote:
>> 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