CBS build process and Dirty DCs

[Former Member]

We are using JDI and we are facing the Dirty DCs problem for a long time. Can anybody provide me possible reasons for the creation of this type of DCs. The build log shows no reason and looks clean yet the Dirty DCs are formed. When we restart the server there are no Dirty DCs and everything looks o.k. We created about 25 Dcs or so only some DCs are causing the problem.

I have already posted this issue sometime ago but I could not solve the problem.

I would appreciate any help in resolving this.

[sid-desh]

Hi Rao Kavuri,

Dirty DC's are marked by CBS and they are rebuilt automatically. So you dont have to worry about those. Dirty DC's are formed because you changed a component which was used by some other components. Hence in this all the components that are using your DC are marked dirty so that they are rebuilt again by CBS service.

Also there may be a possibility that administrator may request a rebuild of some DC via WebUi or commandline tool. In this case also the DC's may be marked as Dirty.

However CBS service will rebuild them. It may not be instantaneous but it places all the requests in the queue and then rebuilds them at some point in time.

Hope this helps.

Regards

Sidharth

[Former Member]

Hi sidharth,

I still can not understand why they are formed as I have not changed the component. This is how they are forming.

1. Inially I built a DC which has dependency on an External Library DC.

2. Tested and transported all the way to Prod.

3. I have to make some changes yesterday. I checked out, made the changes activated and released.

4. I have to make another change after a while and checked out the files made the changes and activated and released.

5. I had to do this another time.

6. I imported my first change into CONS.

7 Then tried the second change and import failed. This DC is maked as Dirty.

Is this the right way to do it. My assumption is that I am not removing the DC from the client once it is released and making changes to it.

If CBS rebuilds this in its own time our change management process suffers. Is there a good solution for this? The documentation about JDI from SAP is poor.

-Rao

[sid-desh]

Hi rao kavuri,

This problem we have been facing for quite some time now. Whenever we change and release the changes the DC's are marked as dirty. CBS takes some time building it and in the by that time CMS import fails.

I think it is better if you open an OSS message with SAP and request them for a solution.

In the mean time you can also check in the TCS deployer after the CBS has built the dirty DC's (in its own time) whether the request has been marked for deployment.

Regards

Sidharth

[Former Member]

How do I check the TCS deployer ?

[sid-desh]

http://<host>:<port>/TCS/Deployer

Regards

Sidharth

[Former Member]

what is this for 'Trigger autodeployment'?

[sid-desh]

Hi Rao Kavuri,

Once CBS finishes building the DC it sends a message across to TCS regarding the deployment of particular request. TCS then gets in touch with CMS and CBS again to get the SDM details and the archive to be deployed.

However from TCS also for a particular buildspace you can trigger the deployment to a particular runtime system.

Hope this helps.

Regards

Sidharth

[Former Member]

hi sidarth,

I checked the logs for INTERNAL_BUILD and for all the failed build requests there is an error.

-

---

Prepare build environment in the file system... started at 2005-10-14 04:49:03.010 GMT

Synchronize development configuration... finished at 2005-10-14 04:49:03.024 GMT and took 14 ms

Unknown platform detected (OperatingSystem="AIX", Architecture="ppc64").

Prepare build environment in the file system... finished at 2005-10-14 04:49:04.753 GMT and took 1 s 743 ms

===== Pre-Processing ===== finished at 2005-10-14 04:49:04.756 GMT and took 2 s 17 ms

Change request state from PROCESSING to FAILED

ERROR! The following problem(s) occurred during request processing:

ERROR! The following error occurred during request processing:java.lang.NullPointerException

at com.tssap.dtr.client.lib.vfs.fileservice.VirtualFile.setWritable(VirtualFile.java:257)

at com.tssap.dtr.client.lib.vfs.impl.SyncRemoveFeature.sync(SyncRemoveFeature.java:1060)

at com.tssap.dtr.client.lib.vfs.impl.VfsFile.sync(VfsFile.java:843)

at com.sap.tc.cbs.server.rt.dtr.impl.VFSCacheAssistant.refreshCache(VFSCacheAssistant.java:156)

at com.sap.tc.cbs.server.dao.impl.RequestDC.syncCache(RequestDC.java:370)

at com.sap.tc.cbs.server.dao.impl.RequestDC.syncMetadata(RequestDC.java:202)

at com.sap.tc.cbs.server.dao.impl.BuildRequest.syncMetadata(BuildRequest.java:541)

at com.sap.tc.cbs.server.proc.impl.BuildPreProcessor.prepareBuildEnvironment(BuildPreProcessor.java:793)

at com.sap.tc.cbs.server.proc.impl.BuildPreProcessor._process(BuildPreProcessor.java:156)

at com.sap.tc.cbs.server.proc.impl.Processor.process(Processor.java:139)

at com.sap.tc.cbs.server.proc.RequestHandler.doProcessing(RequestHandler.java:624)

at com.sap.tc.cbs.server.proc.RequestHandler.doPreProcess(RequestHandler.java:196)

at com.sap.tc.cbs.server.proc.RequestHandler.process(RequestHandler.java:149)

at com.sap.tc.cbs.server.proc.RequestHandler.run(RequestHandler.java:128)

at com.sap.tc.cbs.server.rt.threads.PerpetualRunnable.run(PerpetualRunnable.java:84)

Unknown reason (java.lang.NullPointerException)

REQUEST PROCESSING finished at 2005-10-14 04:49:04.759 GMT and took 2 s 39 ms

-

---

Any clue why this error occurs?

Thanks

Rao

[sid-desh]

Hi Rao Kavuri,

Would request you to please open a message with SAP because they will be able to solve your problem.

Regards

Sidharth

[Former Member]

Hi

I am having the same problem with dirty dc's.. when i do import after 2-3 days...the import was sucessfull. i dont know why it is taking such a long time for CBS...

My version is sp12. if you are having the same version..probably it is bug from sp12..

Thank you

[Former Member]

Hi Sidharth,

I have created a DC and activated it. Everything is going smoothly except that Buildreqeuests is sitting in queue. I can deploy it by triggering Trigger autodeployment but why is this happening. We never had to deploy it in this way. Some thing has changed in the JDI configuration.

The parameter <b>Output Queue </b> mode is set to <i>Not Queued</i> in both dev and Cons.

Do you have any clue?

Thanks in advance

Rao

[sid-desh]

Hi Rao Kavuri,

While defining the runtime systems did you check whether you have checked the box for disabling automatic deployment. Please check that.

Regards

Sidharth

[Former Member]

I verified the run time systems and automatic deployment is not disabled. The box is <b>not</b> checked.

Rao

[sid-desh]

Hi Rao Kavuri,

Did you check the logs after the import process. Does your import end in error. If so logs will be available after selecting the particular row in the table and clicking on details button.

Maybe that can tell you why deployment didnt take place. Also you can refer to these notes: 793935,732921,766224,808677,514156,793508.

Regards

Sidharth

[Former Member]

Hi Sidharth, I figured it out(SDM is locked out). Thanks for the very useful SAP notes.