CBS make fails of SAP_ESS SCA file fails in NWDI 7.0 SP14 after ~4 hours

[Former Member]

Hi,

We wish to do ESS customization in our new NWDI 7.0 SP14 system (on RHEL 4.7). Importing the SAPESS09P_3-20000512.SCA (after importing its dependicies) in a ESS track completed in the Repository-import phase but fails in the next CBS-make phase with a timeout of 14430 seconds (~4 hours). The exact error i am getting is listed below. Is their some way to bump up this timeout value?

I am new to this and am very interested in what more experienced folks suggest about this.

thanks in advance,

Steven McElwee, Duke University

20080224153849 Info :Starting Step CBS-make at 2008-02-24 15:38:49.0310 -5:00

20080224153850 Info :wait until CBS queue of buildspace NDI_XSSTrack_D is completely processed, before starting the import

20080224153850 Info :waiting for CBS queue activity

20080224153921 Info :build process already running: waiting for another period of 30000 ms

20080224153951 Info :build process already running: waiting for another period of 30000 ms

20080224154021 Info :build process already running: waiting for another period of 30000 ms

.......... lots more messages

20080224193917 Info :build process already running: waiting for another period of 30000 ms

20080224193947 Info :build process already running: waiting for another period of 30000 ms

20080224194017 Info :no changes on the CBS request queue (NDI_XSSTrack_D) after a waiting time of 14430000 ms

20080224194017 Fatal :The request queue is not processed by the CBS during the given time intervall => TCS cannot import the request because queue is not empty

20080224194017 Fatal :Please look after the operational status of the CBS.

20080224194018 Info :Step CBS-make ended with result 'fatal error' ,stopping execution at 2008-02-24 19:40:18.0480 -5:00

[Former Member]

Hi Steven

Have you got success in importing SAP_ESS SCA file?

I am in the same situation as you.

regards,

Bharat Talreja

[Former Member]

Not yet. I opened a message with Sap about this. They recommended that i delete the track and recreate it with the identical name. i did that and now i have 5 queued requests and get the same error for anything that i try to import in the track in CMS.

Now, I am trying to re-group and get a better understanding of CMS. I would like to understand why there are queued requests which do not go away, even though the import failed, and i do not seem to be able to remove them with the CBS WEBUI regardless of whether i restart the J2EE or restart the CBS service in visual admin. Perhaps one can do this from the command line?

If anyone can shed some light on this, i would be very appreciative.

Steven

[dick_dijk]

Hi,

I think I had the same problem. It turned out that my CBS properties were not OK. See als note 1031182.

I had to customize 3 properties:

BUILD_TOOL_JDK_HOME

JDK_HOME_PATHS

idleStart

In my case I set them to the following values (your values will be different for the paths!)

BUILD_TOOL_JDK_HOME=D:\j2sdk1.4.2_16-x64

JDK_HOME_PATHS=JDK1.3.1_HOME=D:\j2sdk1.4.2_16-x64;

idleStart=false

You have to restart the cluster before they have affect.

Dick

[Former Member]

Well, I restored our NWDI system from an archive backup taken just prior to defining the new XSS Track. I then carefully followed the ESS NWDI Cookbook instructions to create the XSS Track and to import everything (SAP-JEE, SAP-BUILDT, SAP-JTECHS, and SAP-PCUI) except for SAP_ESS. I then archived to tape everything again. That was yesterday.

Today, I kicked off the import of SAP_ESS. So far, so good- it imported into the repository and is now in the process of Activation in the CBS. There have been no problems with threads stuck in the CBS queue in the QUEUED state.

Of course, it has been only 2 hours so far.

About the CBS properties for BUILD_TOOL_JDK_HOME,

JDK_HOME_PATHS and idleStart. Aside from idleStart, i have left them unchanged. But will keep this in mind should the previously mentioned wierd CBS behavior return.

Disk space is a little tight right now. I had 4 GB free before the import of SAP_ESS. Now i have 2 GB free, which seems to be holding. We have a script running to archive and delete the oracle redo logs since they are being generated at a pretty fast rate.

Once i know one way or the other about the success of this, i will post a message.

thank you everyone for your help so far!

Steven

[Former Member]

The 250 MB SAP_ESS file (SAPESS09_0-20000512.SCA) took just under 2 hours to import. I am importing the patch file (SAPESS09P_3-20000512.SCA)

now.

--Steven

[Former Member]

Hi Steven,

just a quick remark regarding BUILD_TOOL_JDK_HOME and JDK_HOME_PATHS: If you do not explicitly configure them then CBS will use the default JDK on the machine as default.

As long as you are building for a single target runtime version this is usually OK. It gets critical if you want to build something on the same CBS that is for example targeted for CE (which then requires JDK5). I'd rather recommend an explicit configuration, but since you should never touch a running system I'd not reconfigure the system before ESS is working as it should.

Regards,

Marc

[Former Member]

hi Marc,

This sounds like excellent advice. Thank you very much. One question though- what does CE stand for? I feel like i ought know but for some reason cannot place it ....

Steven

[Former Member]

Hi Steven,

CE = NetWeaver Composition Environment 7.1

See for example https://www.sdn.sap.com/irj/sdn/nw-ce-downloads

BTW: Reconfiguring those properties will not trigger rebuilds. If you change them to a different JDK version you have to manually trigger rebuilds. This can be a nasty pitfall.

Regards,

Marc

[Former Member]

Marc,

All i can say is thanks again. I had no idea that Sap had yet another product that we might have to implement that at least uses a 1.5 JDK rather than a 1.4.2 JDK. Very interesting.

thanks,

Steven

[Former Member]

Hi Steven,

just to avoid misunderstandings: If you want to use ESS there is currently no need to implement/use CE.

I was just mentioning CE as it is based on a newer JDK version than ERP05 and while CBS is capable of building with different JDKs the configuration can be a bit tricky. (See https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/7014086d-3fd9-2910-80bd-be341781... for all the nasty details )

No need to worry, though, I was just using that as an example.

Regards,

Marc

[Former Member]

Hi,

well, if you're new to this you should:

1. Check if somebody already had a similar problem

2. Check your CBS. Communication between CMS and CBS is not the best, so either CBS takes longer than CMS is willing to wait or CBS is not really doing anything (idleStart flag?). Even if CMS aborts the import you can restart it and it will only do the necessary steps.

Regards,

Marc

[Former Member]

Hi Marc,

Thanks for your suggestion about setting the idleStart to false. I also happened upon OSS Note 1031182 which also includes useClassicSync being set to false as well.

Those changes being made, however, did not fix my problem. I am still getting the error mentioned above-

20080225153017 Info :build process already running: waiting for another period of 30000 ms

20080225153047 Info :no changes on the CBS request queue (NDI_XSSTrack_D) after a waiting time of 14430000 ms

20080225153047 Fatal :The request queue is not processed by the CBS during the given time intervall => TCS cannot import the request because queue is not empty

20080225153048 Fatal :Please look after the operational status of the CBS.

20080225153048 Info :Step CBS-make ended with result 'fatal error' ,stopping execution at 2008-02-25 15:30:48.0370 -5:00

Any additional ideas will be much appreciated!!!

thanks again,

Steven

[Former Member]

It turns out that there were 2 requests that were queued up in CBS from previous import attempts. I restarted the CBS service via Visual Administrator and that seemed to clear the queue completely. I am now re-trying the import of SAP_ESS and hope that this will work.

I have heard from others that such an import requires 8 hours or so.

My fingers are crossed ...

--Steven