Skip to main content
D
dtkach11-Visitor
1-Visitor
July 12, 2010
Question

Anybody tried to use Java Real Time (RTSJ) for Windchill 9.1?

  • July 12, 2010
  • 5 replies
  • 912 views


Anybody tried to use Java Real Time (RTSJ) for Windchill 9.1?


D

5 replies

J
jessh12-Amethyst
12-Amethyst
July 12, 2010
In general it would seem to make very little sense to use Java Real Time
for a multi-user server application like Windchill.

Overall, real-time Java provides lower performance in terms of overall
throughput than non-real-time Java -- as even the most bullish
presentation on real-time Java will tell you.

That may not sound very much like "real-time," so a little copy-pasted
explanation is in order:

According to Greg Bollella, a distinguished engineer at Sun
Microsystems and one of the authors of the real-time Java
specification, real time means "the ability to reliably and
predictably reason about and control the temporal behavior of
program logic." Real time does not mean "fast," as many developers
might think; it means predictable and reliable when a reaction to
real-world events is required. The real-time computer will always
respond before a particular deadline that you've assigned it.
Depending on how you set your deadlines, numerous systems could be
called real-time.

A large domain of applications cannot afford delaying even for one
second; this domain includes, as mentioned earlier, many financial
applications, on-board aircraft software, nuclear power plant
software, and more. So this is all not about speed, although
real-time platform designers did their best to make it fast.

Moreover, RTSJ requires use of special RTSJ-specific APIs to attain such
reliable/predictable response latencies. These APIs place special
requirements on your code's behavior. You can't just take an arbitrary
multi-user application that allocates memory as needed, expects normal
GC, etc, run it under RTSJ and get "real-time" behavior.

In general, normal Java will have faster overall throughput. For most
server use cases (outside of high frequency trading
<),">http://en.wikipedia.org/wiki/High-frequency_trading>), normal Java
latency is predictable enough -- apart from GC. GC can be fairly
predictable given (1) recent JVMs and (2) proper tuning. If this is the
issue, then first and foremost I'd suggest getting on the latest
available Java 6 update (currently Update 21 on Windows, Solaris, and
Linux platforms) prior to tinkering with tuning. If your Windchill
version does not support Java 6 on the server, then it's time to move to
a version that does.

--
Jess Holle

J
jessh12-Amethyst
12-Amethyst
July 12, 2010
On 7/12/2010 1:48 PM, Jess Holle wrote:
> In general it would seem to make very little sense to use Java Real
> Time for a multi-user server application like Windchill.
>
> Overall, real-time Java provides lower performance in terms of overall
> throughput than non-real-time Java -- as even the most bullish
> presentation on real-time Java will tell you.
>
> That may not sound very much like "real-time," so a little copy-pasted
> explanation is in order:
>
> According to Greg Bollella, a distinguished engineer at Sun
> Microsystems and one of the authors of the real-time Java
> specification, real time means "the ability to reliably and
> predictably reason about and control the temporal behavior of
> program logic." Real time does not mean "fast," as many developers
> might think; it means predictable and reliable when a reaction to
> real-world events is required. The real-time computer will always
> respond before a particular deadline that you've assigned it.
> Depending on how you set your deadlines, numerous systems could be
> called real-time.
>
> A large domain of applications cannot afford delaying even for one
> second; this domain includes, as mentioned earlier, many financial
> applications, on-board aircraft software, nuclear power plant
> software, and more. So this is all not about speed, although
> real-time platform designers did their best to make it fast.
>
> Moreover, RTSJ requires use of special RTSJ-specific APIs to attain
> such reliable/predictable response latencies. These APIs place
> special requirements on your code's behavior. You can't just take an
> arbitrary multi-user application that allocates memory as needed,
> expects normal GC, etc, run it under RTSJ and get "real-time" behavior.
>
> In general, normal Java will have faster overall throughput. For most
> server use cases (outside of high frequency trading
> <),">http://en.wikipedia.org/wiki/High-frequency_trading>), normal Java
> latency is predictable enough -- apart from GC. GC can be fairly
> predictable given (1) recent JVMs and (2) proper tuning. If this is
> the issue, then first and foremost I'd suggest getting on the latest
> available Java 6 update (currently Update 21 on Windows, Solaris, and
> Linux platforms) prior to tinkering with tuning. If your Windchill
> version does not support Java 6 on the server, then it's time to move
> to a version that does.
P.S. In terms of sheer throughput performance (as opposed to predictable
response latency), recent versions of Java are /quite/ high performance
-- at least once they're warmed up (i.e. after the JIT compiler has
kicked in). If you're on an older version of Java, then you're
certainly leaving performance on the table, though.

D
dtkach11-VisitorAuthor
1-Visitor
July 12, 2010
Jess,

Thanks. Good explanation. I just wanted to check if somebody tried and
overall if its possible actually to use RTSJ for such architecture as
implemented in Windchill (not thinking about performance as for right
now, just overview of the ideas and the technical info - I believe in
numbers)


Thanks,
Dmitry

J
jessh12-Amethyst
12-Amethyst
July 12, 2010
I don't know if Windchill will run under RTSJ -- I've certainly not
tried it as every RTSJ expert I've seen/heard has strongly indicated
that RTSJ is not appropriate for this sort of usage.

RTSJ is appropriate for real-time hardware control, high frequency stock
trading [where traders play risky, perverse games with microsecond
timing of trades and measure the feet of cable from the trading floor],
telecom, and emergency response coordination -- not normal enterprise
software applications.

--
Jess Holle

D
dtkach11-VisitorAuthor
1-Visitor
July 12, 2010
Jess,

Thank you.

Dmitry
Terms & ConditionsAccessibility statement