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 <[email protected]> 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
[email protected]
