What would be the best practices to start/stop Windchill 12.0.2.21?

[DN_11160103]

Currently, our order of stopping a windchill through our batch file starts with Windchill Server>Windchill Apache> Windchill SolrServer> Windchill DS. when we run this batch file it takes a pretty long time (around 20+minutes) to stop windchill server. Even when everything stops windchill server will be on stopping mode. I tried re-ordering this in the batch file by stopping Windchill Server after Apache and DS and it took fairly less time (around 2 minutes) to stop. so, my question here is if I reorder the stop pattern will there be any impact in our system? I don't have any problem with Windchill start and I know it must follow the DS and Apache first before windchill server starts but just want a guidance on Windchill stop pattern.

[Marco_Tosin]

Take a look at this article

How to start Windchill windows services in the correct order in Windchill PDMLink

The order to stop services is exactly the opposite of the order to start them

[Fadel]

As service ; 

• To configure Windchill as a service
  1. Launch Windchill Shell (In Windows Server 2008 and later: right-click, "Run as administrator")
  2. As Administrator, Execute where <ServiceName> is what you want to name service.
     • To Install:

ant -buildfile <Windchill_Home>\opt\ntservice\WindchillService.xml install -DserviceName=<ServiceName>

• To Uninstall

ant -buildfile <Windchill_Home>\opt\ntservice\WindchillService.xml uninstall -DserviceName=<ServiceName>

[avillanueva]

Solr does not depend on anything so it can be done in any order before Windchill.  Even if Windchill was up and SOLR was not, it would complain about not being able to connect to it but when its up, it will starting working fine. You might get some failed index jobs however.

Windchill obviously depend upon Apache and Windchill DS (or OpenDJ or whatever LDAP you are using). Apache kind of depends upon your LDAP but I do not remember it not starting if it could not connect. It just would failed to process auth requests. Should be able to start and stop just fine regardless. 

I am not running Windows but aside from Windchill, start and stop times were never more than a 10 seconds for each. 

If you are looking for a safe order, then I would do Windchill first, then Apache and SOLR in parallel, then after Apache do LDAP. Now what I have seen is the Windchill stop service does take a long time if it cannot connect to issue the right stop command. For example, if Windchill failing to start properly and you issued the stop command, it might wait until it can get its attention to execute the stop. In this situation, stopping process might be advisable. It will get caught in a restart loop endlessly. 

[mmeadows-3]

You are seeing a lot of variation in the responses because it depends on your configuration.
You didn't say if this was production or a non-production system.  I'm guessing this is production because you are actually waiting for Windchill to stop.
Assuming a single Windchill instance, not some Dev box with multiple versions of Windchill installed...
Note: There is no reason to restart an application unless you made a change to it: DB, LDAP, SOLR, Apache, etc.

True dependencies...

• LDAP and DB can be considered persistent "appliances".  I removed them from restart scripts years ago because they are independent of each other, not dependent on Windchill, and practically never change.  They should always be running.  When installed on the same server as Windchill, I check to ensure they are running before starting Windchill.
• SOLR can also be considered a persistent appliance.  It is independent of Windchill but you will see a connection failure error in the MS Logs if SOLR is not running before starting Windchill.  Once SOLR is started, the error goes away.  Changes to SOLR are seldom outside of a patching or upgrade event.  Again, I just check to confirm it is running before starting Windchill.
• Windchill is dependent on DB and the LDAP that contains the default Site Administrator account (e.g. wcadmin).  If they are not running, Windchill will crash.  Windchill will start if other LDAP servers are down but those users will not be able to connect to Windchill.
• Apache is independent of Windchill but Apache must be running before any user can connect to Windchill.
• If configured for SSO, Shibboleth must be running before users attempt to connect.  Shibboleth could also be considered a persistent appliance.  There is no reason to restart Shibboleth unless changing the configuration.  Not entirely certain on the start order between Shibboleth and Apache.  I have made it a habit to start Shibboleth before Apache.

Stop scripts can be limited to just Windchill or Windchill and Apache, your preference.  Start scripts should check to ensure everything else is running before starting Windchill and Apache in either order.  Apache will start in seconds.  Windchill starts in minutes.  Users won't be able to connect until Windchill is ready for them.

It appears your real question is why does it take 20 minutes for Windchill to stop.  Great question and I don't know.  There is at least one article suggesting a network configuration issue (CS367229).  Another mentions the Windchill Extensions (CS446737).

I am impatient and I kill the Windchill Java processes when the Windows service doesn't stop in a short period of time.  I've never lost data or had a corruption caused by killing the Java processes that I am aware of.  This approach came about because sometimes Windchill leaves dangling processes when it crashes (CS186040) and Windchill cannot be restarted until those processes have been killed.  I name the Java processes so I know which ones to kill (CS126218).  My shut down scripts try to stop the Windchill service, followed by taskkill commands in case the shutdown was unsuccessful.

[anursingh]

Hi @DN_11160103,

I wanted to see if you got the help you needed.

If so, please mark the appropriate reply as the Accepted Solution. It will help other members who may have the same question.
Of course, if you have more to share on your issue, please pursue the conversation. 

Thanks,
Anurag