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