12-Amethyst

Question

ProE embedded browser performance issue.

Forum|Forum|15 years ago
January 7, 2011
16 replies
2036 views

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

Other

M

mnelson-2

1-Visitor

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

D

ddemay

1-Visitor

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

J

jessh

Author

12-Amethyst

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

D

ddemay

1-Visitor

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

Sent from my Verizon Wireless BlackBerry

J

jessh

Author

12-Amethyst

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.

M

mmeadows

1-Visitor

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.

J

jessh

Author

12-Amethyst

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

M

mmeadows

1-Visitor

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

K

kjohns101

1-Visitor

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.

D

davehaigh