Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: 209.147.113.130 is neither permitted
 nor denied by domain of mmcgrady@topiatechnology.com)
References: <862502422.8331290517859184.JavaMail.hudson@aegis>
 <112459958.8391290520715806.JavaMail.hudson@aegis> <4CEBDFC0.90506@qcg.nl>
 <AANLkTi=x13MS-gUsXMEWyrsm8UjCY-ghpTmO1WnQ+yjt@mail.gmail.com>
 <4CEBE8B0.2020806@qcg.nl> <4CEBED3F.3080504@acm.org>
 <77F1E32F67C8D5479858C0C7E93EB46503E19BB8@WAL-MAIL.global.avidww.com>
 <4CEC61DA.3030702@zeus.net.au> <4CECC1A5.7070804@qcg.nl>
 <4CED1D08.3030101@acm.org> <4CED23EA.1020208@qcg.nl>
 <4CF6688A.7070201@wonderly.org> <4CF685DA.3080000@acm.org>
 <4CF6D8B8.6090006@zeus.net.au> <4CF6E337.4050402@acm.org>
 <F5422BBB-9F0C-4936-AAF6-A90969644E3B@gmail.com> <4CF6F077.7030704@acm.org>
 <84380CFD-746A-4F3C-9F53-E1B2493CF71F@topiatechnology.com>
 <1291266017.16266.3373.camel@cameron>
 <75124B2C-1116-4A35-A186-FDA769E0BC52@topiatechnology.com>
 <EDBE9047-7BA9-4B1C-82F9-AE955428F5AE@gmail.com>
 <4CF88A67.5000606@zeus.net.au>
In-Reply-To: <4CF88A67.5000606@zeus.net.au>
Mime-Version: 1.0 (iPhone Mail 8C148a)
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <ED0F22E9-E5B3-416A-AECC-DE08A5FAB25C@topiatechnology.com>
Content-Transfer-Encoding: quoted-printable
Cc: "river-dev@incubator.apache.org" <river-dev@incubator.apache.org>
From: Mike McGrady <mmcgrady@topiatechnology.com>
Subject: Re: JVM version policy Was: Re: Build failed in Hudson:
 River-trunk-jdk1.5 #3
Date: Thu, 2 Dec 2010 22:28:32 -0800
To: "river-dev@incubator.apache.org" <river-dev@incubator.apache.org>

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.
>=20
> For example, EtherCAT supports real time networking, a client and server c=
ould set a real time constraint and communicate over EtherCAT.
>=20
> The question that Dennis has posed though is how much do you need?  This d=
oesn't have to be decided now, perhaps you can set up an issue on jira so we=
 can track it.
>=20
> The current release still runs on Java 5.  The next release due soon will t=
oo, the following release may not, but time will help us decide how solve th=
is problem.
>=20
> Cheers,
>=20
> Peter.
>=20
>=20
> Dennis Reedy wrote:
>> What boggles my mind here is adding real-time requirements in the same co=
ntext of Jini. While you may have real-time threads, once you touch the netw=
ork your real-time QoS goes out the window. You may be able to guarantee tha=
t the amount of time it takes to perform an operation will be done within a b=
ounded time, but you will not be able to guarantee (in a real-time context) t=
hat the result of that operation will be transmitted over the media to a req=
uesting client.
>>=20
>> What I'd like to find out from Michael here is what exactly are the RT re=
quirements for River?
>>=20
>> Service Infrastructure (JoinManager and the like...)
>> Services (Reggie, Mercury, Outrigger, etc...)
>>=20
>> Other?
>>=20
>>=20
>> On Dec 2, 2010, at 104AM, MICHAEL MCGRADY wrote:
>>=20
>> =20
>>> We do this now with Java 1.5, Greg.  Java RT 2.1 (64 bit) is compatible w=
ith Java 1.5.  http://preview.tinyurl.com/2bpjqfh  There would be no other t=
est than works-with-Java-1.5.  The simple answer is that if River does not c=
all real-time threads and uses Java 1.5 there is no issue.  There are other t=
hings that impact real-time but we can cover those.
>>>=20
>>> MG
>>>=20
>>> On Dec 1, 2010, at 9:00 PM, Greg Trasuk wrote:
>>>=20
>>>   =20
>>>> On Wed, 2010-12-01 at 23:33, Mike McGrady wrote:
>>>>     =20
>>>>> Like I said, Java 1.6 is incompatible with Java RTS and that os very s=
erious in my neighborhood.  We do QoS with Java RTS.
>>>>>=20
>>>>>       =20
>>>> 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?
>>>>=20
>>>> 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?
>>>>=20
>>>> Cheers,
>>>>=20
>>>> Greg.
>>>>=20
>>>>=20
>>>> Sent from my iPhone
>>>>     =20
>>>>> Michael McGrady
>>>>> Principal investigator AF081_028 SBIR
>>>>> Chief Architect
>>>>> Topia Technology, Inc
>>>>> Work 1.253.572.9712
>>>>> Cel 1.253.720.3365
>>>>>=20
>>>>> On Dec 1, 2010, at 5:03 PM, Patricia Shanahan <pats@acm.org> wrote:
>>>>>=20
>>>>>       =20
>>>>>> On 12/1/2010 4:53 PM, Dennis Reedy wrote:
>>>>>> ...
>>>>>>         =20
>>>>>>> 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.=

>>>>>>>           =20
>>>>>> 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.
>>>>>>=20
>>>>>> Patricia
>>>>>>         =20
>>>> --=20
>>>> Greg Trasuk, President
>>>> StratusCom Manufacturing Systems Inc. - We use information technology t=
o
>>>> solve business problems on your plant floor.
>>>> http://stratuscom.com
>>>>=20
>>>>     =20
>>> Michael McGrady
>>> Chief Architect
>>> Topia Technology, Inc.
>>> Cel 1.253.720.3365
>>> Work 1.253.572.9712 extension 2037
>>> mmcgrady@topiatechnology.com
>>>=20
>>>=20
>>>=20
>>>   =20
>>=20
>>=20
>> =20
>=20