nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Synchonized deployment

fiquebem

We are running an OD 6.0.2 Base Server on a TS 6.5, Solaris 9 box. We need to (synchronously and transactionally) deploy files to a Web server (running OD 6.0.2 Receiver on Solaris 9) and their metadata to and Oracle server. The Oracle server is accessible from the TS box, but not from the Web server box. There won't be an OD Receiver on the Oracle box.

Since Synchronized Deployments seem to be available only with Target-Side Deployments, I'm thinking of having 2 Definitions. One to deploy files to the Web server and one to deploy those files' EAs to Oracle. The 2nd Definition's target node would be the Base Server itself. Looks like I'd need to specify a target area as well for the metadata deployment. I don't quite understand that -- why does OD/DD need to (re)deploy the file assets to deploy the EAs -- can't it build the "EA manifest" or whatever without deploying the files themselves? The Synchronized Deployments section of the Database Deployment for OD Admin Guide seems to suggest that either 2 Definitions or 2 "pathSpecification" elements be used. However, the sample OpenDeployNG/examples/conf-od/oddd_xml_to_db_and_fs.xml has only 1 of each.

Incidentally, we want to do Edition-based Directory-Comparison deployments. I assume the OD/DD dynamic duo will take care of comparing the metadata too and just deploying the differences to Oracle.

Thanks,

S.

Find more posts tagged with

Comments

jed

The 2nd Definition's target node would be the Base Server itself. Looks like I'd need to specify a target area as well for the metadata deployment. I don't quite understand that -- why does OD/DD need to (re)deploy the file assets to deploy the EAs -- can't it build the "EA manifest" or whatever without deploying the files themselves?

We currently have this same issue. I would love to be able to deploy metadata only w/ a dbLoader-type deploy. Yes, we can use DD in a standalone mode, but then we have two sets of configs files and two different deployment architectures. In fact, this is what we currently do and it is a pain. (The DD config files for dbLoader and stadalone DD are slightly different if you have not noticed yet.) Going forward, we hope to have only dbLoader-type deploys. We will probably have a DNR that deletes all the content we just deployed for one of our deploys. A bit lame, but it will work.

Also, when using dbLoader, be aware that it tends to leak memory. You will have to do frequent restarts on your receiver and/or pump up the max heap size for the JVM. I have found that our receiver that does the dbLoading runs out of memory after ~900 deploys. Since you are doing loopback, it may be a bit different, but if I were you, I would run deploys in a loop to check for memory leaks.

Finally, if I get a moment, I am going to file a feature request regarding the optional supression of content when doing a dbLoader deploy. If you happen to beat me to this, let me know.

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems

fiquebem

Thanks for your comments!

Before I forget, let me mention that I was a little confused about the expression "Synchronized Deployment." In the OD Admin Guide, it seems to mean the concurrent deployment of 2 types of files -- ones with DB-related data and ones without it -- along with the deployment of the DB-related data to a DB. But what I had in mind was "integrated deployment" of files and their metadata.

>Going forward, we hope to have only dbLoader-type deploys. We will probably have a DNR that deletes all the content we just deployed for one of our deploys. A bit lame, but it will work.

In our case, we are doing Directory Comparison deployments. We want only metadata for the CHANGED (see) files to be deployed. Thus, we need the files on the target side too for OD to decide which files to deploy and subsequently give DD a file-list to deploy the metada (pertaining only to the files in the given file-list). So we can't delete the files on the target -- they'll be needed during the next comparison.

Incidentally, to make the "differential" deployments of metadata work, I added the following to iw.cfg:

force_EA_mod_times=true

(That insures that files where only the metadata changed are not skipped during directory comparisons by OD.)

>Finally, if I get a moment, I am going to file a feature request regarding the optional supression of content when doing a dbLoader deploy.

Please do : ). And how about a feature that would allow integrated deployments that do not require "Target-Side Deployments"?

Anyway, I'm glad to deploy both files and their metadata at once without having to resort to a DNR script. Well done, Interwoven!

S.

Migrateduser

> Finally, if I get a moment, I am going to file a feature request regarding the optional supression of content when doing a dbLoader deploy.

Hey Jed,
I've added the content suppression bit to existing FR #57077.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

jed

Excellent. Thanks!

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems

FurnaceFace

The 2nd Definition's target node would be the Base Server itself. Looks like I'd need to specify a target area as well for the metadata deployment. I don't quite understand that -- why does OD/DD need to (re)deploy the file assets to deploy the EAs -- can't it build the "EA manifest" or whatever without deploying the files themselves?
We currently have this same issue. I would love to be able to deploy metadata only w/ a dbLoader-type deploy. Yes, we can use DD in a standalone mode, but then we have two sets of configs files and two different deployment architectures. In fact, this is what we currently do and it is a pain. (The DD config files for dbLoader and stadalone DD are slightly different if you have not noticed yet.) Going forward, we hope to have only dbLoader-type deploys. We will probably have a DNR that deletes all the content we just deployed for one of our deploys. A bit lame, but it will work.

Also, when using dbLoader, be aware that it tends to leak memory. You will have to do frequent restarts on your receiver and/or pump up the max heap size for the JVM. I have found that our receiver that does the dbLoading runs out of memory after ~900 deploys. Since you are doing loopback, it may be a bit different, but if I were you, I would run deploys in a loop to check for memory leaks.

Finally, if I get a moment, I am going to file a feature request regarding the optional supression of content when doing a dbLoader deploy. If you happen to beat me to this, let me know.

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems

Hi Jed,

We are having issues with our receiver (using dbLoader as well) and find we have to restart it ever so often as well. This memory leak - was this ever resolved? If not, is there a bug # attached to it?

Thanks,
/FF

jed

Hi Jed,

We are having issues with our receiver (using dbLoader as well) and find we have to restart it ever so often as well. This memory leak - was this ever resolved? If not, is there a bug # attached to it?

Thanks,
/FF

The memory leak we experienced was fixed last December. If you are on the latest patch rev for OD 6.02, you should be golden:

/app/suncom/opendeploy/OpenDeployNG/bin/iwodservergetversion
Version 6.0.2.1.1 Build 53981 Interwoven 20051201

OD6.1 should also contain the fix, but we don't run that so I cannot really comment.

FurnaceFace

The memory leak we experienced was fixed last December. If you are on the latest patch rev for OD 6.02, you should be golden:

/app/suncom/opendeploy/OpenDeployNG/bin/iwodservergetversion
Version 6.0.2.1.1 Build 53981 Interwoven 20051201

OD6.1 should also contain the fix, but we don't run that so I cannot really comment.

Thanks for the response Jed - we are running into a problem where the receiver is going down every so often during our QA testing. I saw this and though - hmmm this could be it. I'm going to run some tests with some loops and monitor the memory to see what happens...

Thanks agian for the response - I'll get back to you on this..
/FF