OD Fail for transactional two definitions

Win2k SP3
OD 5.6 p38020
Sorry guys, I need some help here.

I am trying find the best way to deploy to websphere.
I seem to be having problems deploying with two definitions transactionally.

Theres a few steps involved
1st Definition
- Deploy ear
- DNR to stop WAS, expand/install ear

2nd Definition
- Deploy config/JSP's to directory that the DNR created from 1st Definition
- DNR to start WAS

The ear is split up that way because java code is handled with pvcs and jsp's/configs are in TeamSite.

If I have transactional=no then it works fine
If its on then it fails. The logs seem to complain about line 50 in my profile regarding a directory that exists on the source where the contents is sent to another directory on the target that the 1st defintion DNR would create.

I really cant figure it out. Maybe there is another approach I should look at.
Also are the definitions handled one at a time? If not, then maybe thats why there is a failure.
Its just strange that it works when transactions are turned off, because the right files do end up in the right places. Im sure I have got something wrong.

Ive attached the logs and profile... any help would be great!!!!

John Cuiuli
Consultant
Sydney, Australia

Find more posts tagged with

Comments

Johnny

Sorry I posted an older profile... here is a newer one!

John Cuiuli
Consultant
Sydney, Australia

Adam Stoller

I'm a little confused by the filelist setting associated with targetFilesystem in the first definition - but that should be either getting ignored of showing up as a syntactic error and not causing a subtle problem like the one you are describing.

The second definition with multiple pathSpecifications each with their own filters for includes - should in theory work, but the added complexity here is that the second pathSpecification is a sub-component of the first pathSpecification - and that might trigger something odd (if it does, it should probably be filed as a bug to be dealt with - however, it is possible that this is *not* a problem - I'm just looking at *possibilities*)

We're then left with 2 definitions / 3 pathSpecifications / 3 targetAreas:
1) E:\Apps\WebSphere\AppServer\installableApps
2) E:\Apps\WebSphere\AppServer\installedApps
3) E:\Apps\WebSphere\AppServer\installedApps\InsideIAG.ear\InsideIAG.war\WEB-INF\classes

The first two are [subtly] distinct target directories - and as such shouldn't cause a problem regardless of the trascational setting.

The third one is, however, a sub-directory within the second target area - and if you are doing things transactionally, it is possible that a directory will get created separately (dir.iwnew) and then an attempt will be made to move it back into place (dir => dir.iwold, dir.iwnew => dir) and this might be where you are running into problems with the transactional deployment.

More investigation probably needs to be done to determine whether or not this is the source of your problems and what, if anything can be done about it.

--fish
(Interwoven Senior Technical Consultant)

Johnny

Interesting points, thanks for your help on this fish!

You are definately right about the filelist! hah! I remember choping and changing bits and piece while trying to debug the problem. I must have put it in the wrong place when adding it back. It definately didnt complain about it though!

Will fix that one!

The thing about the directories is a little odd.

In the first definition, the DNR should be creating all the directories under installedApps for the second definition. It basically expands the ear into installedApps.

Could there still be a problem with that scenario?

I might try putting the second pathspecification into a 3rd definition... what do you think??

I really seem confused with this all. Could you see a potential bug...

Also do you think that there may be another approach to the requirement? Perhaps Im not handling it in the best way. Id be keen to hear peoples thoughts! Its driving me nuts!! I was looking at multi tier deployment, but from what i read the second leg is deployed from the 1st target. I would like something similar where the sender controls all of it, that way I can break up the deployments into app and content, so app uses content, but I can also use content on its own. that would be nice, i wasnt able to find a way, but the above issue is what im most conerned about right now!!

Thanks again!

John Cuiuli
Consultant
Sydney, Australia

Migrateduser

If I understand, you want the first definition to run and do some prep work on the target for the second definition. Unfortunately, there isn't a way to sequence these definitions -- they run in parallel.

You're correct about how multi-tier works -- the "next deployment" is invoked on the target system.

I suppose if you want a second deployment to kick off at a certain point after the first deployment does something, you could set a source-side DNR trigger in the first one that calls iwodstart for the second one.

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Johnny

Thanks for that Todd,

This is what I suspected.

Its a real shame though, because I need it to work transactionally.

I was thinking about a dnr invoking another deployment.
Do you think calling iwodstart in the dnr is a good practice?
Or is it the only option I have...

I suppose I would have to wrap it up in a script so I can signal a failure to the first deployment if the second fails...

feature request for sequential definitions? Smiley Happy

Do you think my approach may not be ideal?

John Cuiuli
Consultant
Sydney, Australia

LDAPadmin_connection_profile.png

LDAPadmin_tools_import.png

ApplicationDomainEditor-Directory-Internal-Generic.png

internal_users-generic.ldif.txt

LDAPadmin_users_copy_dn.png

Johnny

Well I have one more question now.

I guess I can try it out.

Are DnR scrips executed in parallel?
Or will they be executed in order?

If its in parallel then it still will run into the same problem

John Cuiuli
Sydney, Australia

Adam Stoller

I *believe* the order in which DNR scripts are run is "logically ordered" - i.e.

There are N different trigger points - which themselves dictate an ordering, then for a given execDeploymentTask, the order in which the DNRs are specified, top-down, with respect to the trigger-point ordering, is the order in which they will be run:

Something like this:
- DnrDeploymentJob (prior to execDeploymentTask specifications - in order specified top-down)
- First triggerpoint (in order specified top-down)
...
- Nth triggerpoint (in order specified top-down)
- DnrDeploymentJob (specified *after* execDeploymentTasks, top-down)

However - as the execDeploymentTasks are run concurrently, the DNR scripts associated with the different execDeploymentTasks are *also* run concurrently - i.e. within a single execDeploymentTask the order in which the DNRs run may be deterministict, the same cannot be said when looking at a list of DNRs running from multiple execDeploymentTask specifications.

And of course, if you run any of the DNRs with async="yes" ...

--fish
(Interwoven Senior Technical Consultant)

Johnny

I knew I wasnt going to enjoy websphere deployment.

Thanks for the help guys, you've put me into the right direction!

John Cuiuli
Sydney, Australia

Johnny

Just some information for you.

I tried spliting the two pathspecifications into two seperate definitions.

It does actually work.

I repeated it quite a number of times and it never failed.

The only problem was that the directories were all created with lowercase.
EG InsideIAG became insideiag and WEB-INF became web-inf.

This is obviously a problem so I still may have to use the DnR approach.

I thought you may find it useful... not sure if its expected to behave this way.

Ive attached the profile.

Thanks!

John Cuiuli
Sydney, Australia

Adam Stoller

The issue with target directories being created in all lower case on Windows was recently identified by one of our customers - # 39926. For *most* applications on Windows this does not cause any problems, but there are apparently some applications that do distinguish case on Windows.
If your company, or the company for whom you are doing work, is affected by this issue, please contact Interwoven Support and have the company's name added to the issue.

--fish
(Interwoven Senior Technical Consultant)

Johnny

Well they are not affected as I took Todds' suggestion and kicked the second leg via a DnR.

I thought id post it as it seemed very strange -- incase somebody else goes down the same path.

I guess you just confirmed what I thought it was. Smiley Happy

John Cuiuli
Sydney, Australia

Migrateduser

Fyi, the DNR sequencing behavior for a particular trigger point as explained by Adam was recently confirmed. This should appear in the upcoming service pack documentation.

Also, a feature request for sequencing deployment tasks is on file: #37521

Cheers,

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Johnny

I appreciate your help guys...

I think that feature request would be very useful for our situation.

John Cuiuli
Sydney, Australia