cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X

ProE embedded browser performance issue.

jessh
5-Regular Member

ProE embedded browser performance issue.

First off, the temp patches are to run Windchill *clients* with Java 6
Update 19 and higher.

Secondly, I believe the correct temp patch is 9.1-M050_TP23 -- but I'm
no expert on our temp patches.

Finally, the best solution overall is to move to R9.1 M060 as it
contains lots of other fixes (as all MORs do). I've seen numerous cases
where the customer and PTC technical support and R&D spent weeks working
together to troubleshoot and diagnose an issue -- only to find that it
was an issue that was already fixed in an MOR that was readily available
when the customer encountered the issue. Yes, it would be nice if we
could automatically say "that's issue ___" that we already fixed, but it
is often far from this obvious. Selectively applying temp patches
rather than moving to the latest available MOR is asking to fall into
this situation.

--
Jess Holle

16 REPLIES 16

Jess,
Thanks for the information...

I understand your comments. The reality is that installing an MOR is not something that can be taken lightly. While a temp patch can (and should) be tested in a development environment, that effort is typically far less involved than the testing and planning required for the installation of an MOR. Our system is relatively small and uses only a portion of the functionality available, yet it took weeks to plan and execute the last MOR installation - not to mention thousands of dollars to a PTC partner for help with the upgrade. I can only assume that complex installations would be even more difficult (and costly) to upgrade. I don't necessarily disagree with you, but from a customer perspective, "selectively applying temp patches" to correct known issues is often the best approach.

Take Care,
Mark

ddemay
1-Newbie
(To:jessh)

Ok...I'll aim into the wind. Hopefully it doesn't chill. Too much 😉

Does this issue affect any other WGM/embedded browser configs for those not using ProE for every model. We also use the CATIA WGM and based on the convo, wondering if this is applicable?

Thanks,
Dave

Sent from my Verizon Wireless BlackBerry
jessh
5-Regular Member
(To:jessh)

I'm not sure what' you're asking.

The temp patches are for Windchill Java applet and PSE usage --
irrespective of browser. [Sun/Oracle triggered some substantive
regressions with their security fixes in Java 6 Update 19 and 20.]

--
Jess Holle

ddemay
1-Newbie
(To:jessh)

You answered it thanks. I think half only understood the conversation from the beginning.


Sent from my Verizon Wireless BlackBerry
jessh
5-Regular Member
(To:jessh)

I believe PTC and customers need to work together to understand why MOR
"upgrade" is difficult/expensive and address sources of this difficulty
wherever possible.

Certainly on PTC's part /every /effort should be taken not only to
ensure no regressions, but to ensure that any end-user UI changes or
additions are opt-in so as to provide as seamless a transition as
possible. I believe that at least on the regression testing front,
recent MORs have been much better than those in the past. PTC certainly
needs detailed feedback regarding customer MOR update experiences if
MORs are going to improve.

The reason I put "upgrade" in quotes is that upgrade/migration to me
applies only to changes between major versions, i.e. those requiring a
database upgrade/migration. Applying an MOR update should not have any
similarity to that level of effort or risk.

--
Jess Holle

P.S. I am speaking only for myself -- and not in any official capacity
for PTC here.

mmeadows
1-Newbie
(To:jessh)

From an implementation specialist's point of view (please feel free to refute my point of view), many of us differentiate "patches" from "updates" from "upgrades". Patches are relatively simple as long as we follow the instructions. It would be wonderful if updates to MOR builds were equally as simple but they are not.

Updates are challenging because every MOR build requires patches (i.e. upgrades or re-installs) to one or more of the third-party components: web server, servlet engine, LDAP, and database. The move to 9.1 M030+ was particularly notable because of the replacement of Aphelion with Windchill Directory Server. These kinds of changes require implementation specialist expertise which many companies get from their VARs or PTC Global Services.

From a QA perspective a temp patch is a relatively isolated change that can be spot checked with targeted testing. Automated regression/performance testing (for those customers who have developed it from scratch) will validate nothing else was broken by the temp patch. The rest of us have to do manual regression testing. This can take hours to weeks. The longer the process takes, the less willing customers are to update.

The balance of investment vs. payback I have seen is updating to every third or fourth maintenance build. That averages out to one update a year.

Eliminating software components from the Windchill installation would help from a software perspective. The removal of Tomcat in 10.0 (embedded in the Method Server) is a step in the right direction. Finding a way to eliminate the LDAP software component from the base installation would significantly simplify backups, updates, upgrades, and rehosting activities.


In Reply to Jess Holle:

I believe PTC and customers need to work together to understand why MOR
"upgrade" is difficult/expensive and address sources of this difficulty
wherever possible.

Certainly on PTC's part /every /effort should be taken not only to
ensure no regressions, but to ensure that any end-user UI changes or
additions are opt-in so as to provide as seamless a transition as
possible. I believe that at least on the regression testing front,
recent MORs have been much better than those in the past. PTC certainly
needs detailed feedback regarding customer MOR update experiences if
MORs are going to improve.

The reason I put "upgrade" in quotes is that upgrade/migration to me
applies only to changes between major versions, i.e. those requiring a
database upgrade/migration. Applying an MOR update should not have any
similarity to that level of effort or risk.

--
Jess Holle

P.S. I am speaking only for myself -- and not in any official capacity
for PTC here.

jessh
5-Regular Member
(To:jessh)

On 1/9/2011 8:53 AM, Matt Meadows wrote:
>
> From an implementation specialist's point of view (please feel free to
> refute my point of view),many of us differentiate "patches" from
> "updates" from "upgrades". Patches are relatively simple as long as we
> follow the instructions. It would be wonderful if updates to MOR
> builds were equally as simple but they are not.
>
> Updates are challenging because every MOR build requires patches (i.e.
> upgrades or re-installs) to one or more of the third-party components:
> web server, servlet engine, LDAP, and database.
>
That's certainly not generally the intent. Upgrades of web server and
servlet engine are /encouraged/ at various MORs, but one should be able
to use the FCS/F000 Apache and Tomcat with the latest MOR -- or the
latest MORs Apache and Tomcat with FCS/F000 of everything else. Ideally
you'd use the latest MOR of everything to have all the fixes, but the
intent is to be flexible here.
>
> The move to 9.1 M030+ was particularly notable because of the
> replacement of Aphelion with Windchill Directory Server. These kinds
> of changes require implementation specialist expertise which many
> companies get from their VARs or PTC Global Services.
>
That was a rather exceptional case. There were very good reasons for
this, but it was still unfortunate.
>
> From a QA perspective a temp patch is a relatively isolated change
> that can be spot checked with targeted testing. Automated
> regression/performance testing (for those customers who have developed
> it from scratch) will validate nothing else was broken by the temp
> patch. The rest of us have to do manual regression testing. This can
> take hours to weeks. The longer the process takes, the less willing
> customers are to update.
>
In part this is a trust issue then, in that customers don't trust PTC to
do sufficient testing? Or is it simply that customers have no good
means of regression testing their customizations?

--
Jess Holle

mmeadows
1-Newbie
(To:jessh)

Jess,

We trust PTC QA to the extent that they can test software but customer testing is not optional. Look at the broader scope of hardware, software, and infrastructure. Add to this the integrated authoring tools, performance criteria, and the uniqueness of each company's data set. The configuration possibilities are limitless and beyond any software company's ability to QA completely. Only customer testing can truly qualify a customer environment and minimize deployment risk.

Maybe “MOR build requires” wasn’t the appropriate wording but it comes down to the same thing. Not updating these components to a software configuration that PTC has explicitly tested and qualified is additional risk that requires more rigorous customer QA. Our goal is to minimize the risk to the customer and minimize their in-house QA efforts.

I am interested in an out-of-the-box, easy-to-configure/use extensible QA tool for automated regression testing in the customer environment. I wouldn't complain if it addresses customizations but every customer must QA the post-update out-of-the-box software.

Regards,

Matt

we experience many embedded browser freeze ups where a user initiates a workspace task i.e. check-in, update etc and after the task is completed the browser doesn't refresh, we look in the stand alone browser and see the task has been completed, we have to kill the pro/e process and restart to see the workspace has been updated. The current configuration is PDMLink 9.1 build M030 and java 1.6.22. This behavior is for all machines, 32 & 64 bit windows on XP & windows 7. It is random and totally unpredictable and not easily repeated but is restricted to the embedded browser.
davehaigh
11-Garnet
(To:jessh)

Have you add the registry edits for xtop? TPI 133412
davehaigh
11-Garnet
(To:jessh)

One more thing you ought to look at is the Windchill Client Inspector. You can download it from PTC and then run it on the client machine.

There's also a Windhill Configuration Assistant to test your server

David Haigh

If you use un supported software versions in conjunction with PTC’s software you will traditionally see a lot of anomalies like this. I’m not saying that is 100% of your issue but certainly getting on a supported version of Java is extremely important, especially if you are seeing problems.

Latest Supported Java - 1_6_18
Windows 7 32bit 64bit Not fully supported on M030 of PDMLink 9.1 (I think it starts with M040) with the Pro/E WGM

I think your testing verifies a lot of this as well. You are only seeing problems when using the more complex WGM functions within Pro/E (i.e. Checkin -out).

It’s very important to always consult the reference documentation (software matrixes) for PDMLink as there are so many working pieces that go together when using a web based tool.

jessh
5-Regular Member
(To:jessh)

On 1/11/2011 8:41 AM, Steve Vinyard wrote:
>
> If you use un supported software versions in conjunction with PTC’s
> software you will traditionally see a lot of anomalies like this. I’m
> not saying that is 100% of your issue but certainly getting on a
> supported version of Java is extremely important, especially if you
> are seeing problems.
>
> Latest Supported Java - 1_6_18
>
This is inaccurate. Wherever (i.e. in whichever product versions and
client vs. server) Windchill supports Java 6 we support all updates of
Java 6 from the minimum version stated in the platform support matrix to
the very latest update. Currently the latest Java 6 release is Java 6
Update 23, which is thus supported wherever we support Java 6.

As already noted, Oracle caused some client regressions with changes
they made in Java 6 Update 19 and 20. These have been addressed by
readily available temp patches.

It should also be clear that when Java is not being used by the client
whichever version of the Java Plug-In you have installed won't impact
the client. Rather, the Java Plug-In version will only impact pages
containing applets and/or Java Web Start applications (PSE).

--
Jess Holle

Good to know, for sure. Unfortunately none of that is on the reference documentation and temp patches, as a PTC best practice, should be run through on your development env. - tested and validated which can be quite a bit of effort and not everyone has a dev environment. I think for the most part sticking with the documentation is certainly the easiest\safest route to stay with.

At a core, an uncontrolled client environment can lead to poor client experience with Windchill as it depends on several third party applications. Too many Java versions are left to automatically update, web browsers are updated without thought to Windchill’s compatibility and finally operating systems can move beyond Windchill’s support without upgrades. These are things that in the end need to be controlled, tested and considered when moving forward with the other critical components to ensure a more worry free environment.


[cid:image001.gif@01CBB169.E8EBEFD0]

Steve Vinyard
Application Engineer
jessh
5-Regular Member
(To:jessh)

The documentation is rather explicit about the "or higher" policy when
it comes to Java version support -- unless this changed recently.

But, in general, yes, uncontrolled updates on the client may push one
past what PTC has managed to test and/or support at that point.

It’s only ever said that higher versions are “expected” to work to the best of my knowledge. All just trivial details, but I certainly encourage my users to avoid staying with anything other than what the documentation supports as it avoids the headaches like we’ve seen Java cause this year. Yeah it can be trivial for some but in a larger environment it can certainly create a lot of headaches.

[cid:image001.gif@01CBB17A.FF8EDBB0]

Steve Vinyard
Application Engineer
Top Tags