Monday 30 November 2009

Package deploy and locks and more info

I know that I’ve talked about deploying packages and locks and things before…  I don’t want to cover old ground, but I do want to record more information.  We’ve talked about a scenario where you have PD and PP installed on the one enterprise server.  If there are UBE’s running in PD, you can still deploy to PP without affecting business continuity. 

I believe that being a good technical consultant is balancing these two requirements (system availability and technical productivity).  That is that they can get the maximum amount of work done with minimum disruption to the business.

Anyway, off my soap box.  I had a situation the other day where I was deploying to PP in a similar environment as mentioned above.  The hardware was supporting two pathcodes with a instance of JDE.

I deployed the package and waited… and waited…  sweated… waited…

I got very nervous and looked at the deployment logs and saw that the package was trying to get locks on the server.  I looked at task manager and saw that one of the kernels was “spinning it’s wheels”, it has 100000’s of seconds on it’s runsheet, obviously a runaway.  I killed the kernel in question and almost immediately the system took a HUGE gulp of air and things were back to normal.

So, what does this mean…  We’ll it means that you definitely lock the entire instance of JDE when you deploy a package, not just the pathcode that you are using.  I guess the small justification is that if UBEs were running in PD, the package would still go through.

So, my recommendation is changing.  If you are deployed for a pathcode that shares the PD instance, don’t deploy until the system is quiet.  Check your UBE’s before hitting deploy, check for any kernels that are “spinning their wheels”.

<rant mode>

  • I personally think that the new 812 deployments are a huge step backwards.  I took in the marketing hype and thought that it was going to be magical, but in the hard light of day, the process is quite cumbersome and prone to errors. 
  • It takes way too long to deploy (although this is a configurable option). 
  • I get seemingly random “network errors”, “internal server” errors etc. 
  • I like the generation option, but let’s be honest…  Why is not on the deployment server and an option with the build / deploy?  Generate java objects should be another tick box when you are defining the build.  They should generate the objects to a couple of temp F98999% files and then copy then in when deploying.  Job done!  Generation server??  What a waste of resources and a burden on the environment!

</rant mode>

No comments: