CSIDE 22.4 taking FOREVER to compile

Hi,

I had this in the past with older versions of CS and CSIDE, but this started up recently with my CSIDE 22.4 deployment on Eclipse 22-12 on Windows Server 2019. I think it may be related to a Windows update that was foisted on me, but have no way to prove it or back it out. This is also a Virtual Machine on VMWare 15.

Anyone else getting anything like this? If I save a file with Autocomplete turned on, I will be hung for 90 seconds to 2 minutes. If I turn autocomplete off, I still have to manually build and it takes that time still. I tried setting thread sockets timeout down to 10 seconds from 30 to see if that would make any difference. It did not.

-Hugh

Find more posts tagged with

Comments

David Henshaw

@HFCDev Hugh -

A) Do you have the Admin service running in the VM and if so, have you suspended indexing?

B) If you're on 22.4, you could try using OBuild for the build rather than the Eclipse plugin. This looks promising - I've even containerized this so I can run a docker container on my desktop when I want to do a build. To do that, I've got my own Dockerfile to do a build with….looks something like following:

FROM registry.opentext.com/otxecm:22.4.2

WORKDIR /tmp

COPY OBuild/ ./

RUN mkdir -p ./src

RUN cp -R /opt/opentext/firstruncopy/config/* /opt/opentext/cs/config

ENTRYPOINT ["./obuild.sh", "--OTHOME /opt/opentext/cs --SRCDIR src --DSTDIR build-output"]

Obviously you'll need to authetnicate to the OT registry prior to doing the Docker build, and to also retrieve OBuild from OT Support and place in relevant folder under where the Dockerfile is.

The docker build creates an image derived from the otxecm image, copies the OBuild files into it (in /tmp) and then copies the relevant config file “baselines” into the config directory. I found that OBuild will run even if there's no DB connection defined etc, but only if there's a valid config file, even if only a “scratch” one that you'd usually finalise during install.

I'm tagging the built image from above with the same version as the otxecm image - i.e. I'd build the image and tag as “obuild:22.4.2”

This was sufficient that I can then navigate to my source code (we use Git, so I simply checkout the project into a working directory and ensure I'm in the equivalent of srcmodules, which in turn contains one folder per module. The module folders must contain a valid module.ini file.

I can then fire up powershell and run

docker run --rm -it -v "$(pwd):/tmp/src" -v "$(pwd)/../build-output:/tmp/build-output" obuild:22.4.2

This creates a container from the image, maps the current directory to /tmp/src in the container. It also maps a build-output location.

The ENTRYPOINT in the build file above defines that when the container runs that OBuild is to be run, using /opt/opentext/cs (which is were CS is installed in the OT images) as the OTHOME location, use the source located in src (which is mapped back to my local machine) and put the build outputs into build-output.

Voila! Build (OSCript) code without CSIDE!

I would point out I've noted some areas for improvement in OBuild.

It doesn't copy all the folders from your module into the final build. Rather it seems that OpenText have defied a set of “known good” folders that OBuild should pick up from your source and place into the build output - e.g. html, support, help, adminhelp etc. But folders like ojlib which contains JAR libraries you may be using in your module seem to be missing from the build output.

I've flagged this on another forum and am hoping @Juliano_Ghisi picks these up.

It's also a shame that there's a dependency on the module.ini file. I would argue that this should be an output of the build process since it fundamentally echoes content in the module's OSpace anyway!

Otherwise, I'm going to eventually look at using Ant or something to arrange the build.

My eventual goal is to hook this up such that when code checkins take place, an automated build occurs and any errors are reported. IT also ensures that the build takes place with no other modules installed - so if someone has made an accidental reference to a function that isn't part of the core install base the build should fail.

HFCDev

I know it's not related to the Admin index. If I turn it off, building takes equally long. I'm not quite ready to go to OBuild. I need the interactive nature of having CSIDE halt execution and show me the error stack when I hit a stack trace.

-Hugh

David Henshaw

Running any Antivirus, Windows Defender etc on the VM?

Chris Meyer

I have always found compilation with CSIDE to be hit-and-miss. Sometimes it goes quickly, but too often it gets stuck and I'm forced to shut down Eclipse.

bartemsa

Check Resource Usage: First, ensure that your system resources (CPU, RAM, etc.) are not being overly utilized by other processes. You can use the Task Manager (Ctrl + Shift + Esc) on Windows Server to monitor resource usage while running Eclipse/CSIDE.

Update CSIDE and Eclipse: Make sure you are using the latest versions of CSIDE and Eclipse. Developers often release updates to fix known issues, so updating might address the problem.

Check for Plugin Conflicts: If you have other plugins or extensions installed in Eclipse, they might be conflicting with CSIDE. Try disabling other plugins one by one to see if any of them are causing the slowdown.

Check Windows Updates: While you suspect that a recent Windows update may be the cause, it's still worth double-checking for any new updates that could potentially fix the issue.

Clear Workspace: Sometimes workspace data can become corrupted, leading to performance problems.