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 <[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]
Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
[email protected]
------------------------------------------------------------------------
