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 Sat, 04 Dec 2010 02:45:56 GMT
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 

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 

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 



> 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
>>>>>> touch the network your real-time QoS goes out the window. You may
>>>>>> 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
>>>>>>> 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
>>>>>>> there is no issue. There are other things that impact real-time
>>>>>>> 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
>>>>>>>> That's certainly an interesting comment... I'm curious though:
>>>>>>>> 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
>>>>>>>> components need some other evaluation or testing to be accepted
>>>>>>>> "real-time" (which I doubt would be an easy task), or would
>>>>>>>> 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
>>>>>>>> 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>
>>>>>>>>>> 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
> ------------------------------------------------------------------------

View raw message