Merge branch 'main' into bug6203

+ #ref: 'refs/tags/3.13.3'

+ naasReleaseEnabled: true

+ echo "Builds a Hudson job for bug branch bug4221, and linking to the Bugzilla bug."

+# Disable FTDC to avoid crashes

+setParameter:

+ diagnosticDataCollectionEnabled: false

+# Disable FTDC to avoid crashes

+setParameter:

+ diagnosticDataCollectionEnabled: false

+# Disable FTDC to avoid crashes

+setParameter:

+ diagnosticDataCollectionEnabled: false

+CHECKED_OUT_WORKSPACE_NAME="checked-out"

+# Disable FTDC to avoid crashes

+setParameter:

+ diagnosticDataCollectionEnabled: false

+sudo su - -c "cat >>/etc/mongod.conf << EOF

+# Disable FTDC to avoid crashes

+setParameter:

+ diagnosticDataCollectionEnabled: false

+EOF

+"

+ # Install MongoDB 7.0 and configure as replica set "replica"

+import org.junit.jupiter.api.Disabled;

+@Disabled("US Government Shutdown around 2026-02-04")

+import org.junit.jupiter.api.Disabled;

+@Disabled("US Government Shutdown around 2026-02-04")

+import org.junit.jupiter.api.Disabled;

+@Disabled("US Government Shutdown around 2026-02-04")

+import org.junit.jupiter.api.Disabled;

+@Disabled("US Government Shutdown around 2026-02-04")

+sourceCode=Zdrojový kód

+sourceCode=Kildetekst

+sourceCode=Código fuente

+sourceCode=Code source

+sourceCode=Codice sorgente

+sourceCode=ソースコード

+sourceCode=Texto fonte

+sourceCode=Исходный текст

+sourceCode=Izvorna koda

+sourceCode=源代码

+ while (miner.isCurrentlyActiveOrHasQueue() && millisLeft > 0) {

+ if (miner.isCurrentlyActiveOrHasQueue() && millisLeft <= 0) {

+ public boolean isCurrentlyActiveOrHasQueue() {

+ return polarDataMiner.isCurrentlyActiveOrHasQueue();

+ public boolean isCurrentlyActiveOrHasQueue() {

+ Wait.wait(()->!polarDataService.isCurrentlyActiveOrHasQueue(), /* timeout */ Optional.of(Duration.ONE_MINUTE),

+ <h2 class="articleSubheadline">January 2026</h2>

+ <ul class="bulletList">

+ <li>Extended RabbitMQ channel heartbeat interval to 1h. This will suffice even for

+ longer garbage collection cycles that may happen during replica set start-up.</li>

+ <li>Using explicit ("manual") RabbitMQ message delivery acknowledgements for initial

+ load when starting up a replica, combined with a "prefetch" (basicQos) value of 1.

+ This way, when the replica is processing data

+ and doesn't read fast enough, the RabbitMQ server will wait for the next message

+ confirmation before sending more messages. This avoids socket buffer overflows

+ which previously could lead to the RabbitMQ server timing out trying to send

+ messages to the replica's channel.</li>

+ </ul>

+followSports=Sledujte nás na

+followGitHub=Sailing Analytics zapnuto

+followSports=Følg os på

+followGitHub=Sailing Analytics på

+followSports=Síganos en

+followGitHub=Sailing Analytics en

+followSports=Suivez-nous sur

+followGitHub=Sailing Analytics sur

+followSports=Seguici su

+followGitHub=Sailing Analytics attivo

+followSports=フォロー:

+followGitHub=Sailing Analytics:

+followSports=Siga-nos em

+followGitHub=Sailing Analytics em

+followSports=Следите за нами в

+followGitHub=Sailing Analytics в

+followSports=Sledite nam na

+followGitHub=Analitika jadranja na

+sportsOn=SAP Sports

+followSports=关注我们

+followGitHub=Sailing Analytics

+import com.sap.sailing.landscape.common.SharedLandscapeConstants;

+ setHostname("www."+SharedLandscapeConstants.DEFAULT_DOMAIN_NAME); // TODO this should probably be archive-failover.sapsailing.com for the fail-over ARCHIVE server; TODO bug6208: use something other than "www" for the ARCHIVE

+ * 10s, a heartbeat interval of 30 minutes, and that uses automatic recovery and topology recovery.

+ connectionFactory.setRequestedHeartbeat(1800);

+ channel.basicQos(1); // with "manual" acknowledgement, process one message at a time, avoiding overloading inbound socket

+ channel.basicConsume(queueName, /* auto-ack */ false, messageConsumer);

+ final Delivery delivery = messageConsumer.nextDelivery();

+ channel.basicAck(delivery.getEnvelope().getDeliveryTag(), /* multiple */ false);

+ try {

+ if (count > 0) {

+ if (this.channel != null && this.channel.isOpen()) {

+ final byte[] message;

+ // check for the unlikely case that a client has coincidentally submitted the TERMINATION_COMMAND; we escape by

+ // appending a random byte which makes the length differ; the input stream provider will skip one byte after receiving

+ // the TERMINATION_COMMAND at the beginning of a message whose length is greater than that of the TERMINATION_COMMAND.

+ if (startsWithTerminationCommand(streamBuffer, count)) {

+ message = new byte[count+1];

+ } else {

+ message = new byte[count];

+ }

+ System.arraycopy(streamBuffer, 0, message, 0, count);

+ this.channel.basicPublish(/* empty exchange name means the default exchange with direct routing;

+ all queues by default bind to this exchange, using the queue name

+ as the routing key.

+ See also https://www.rabbitmq.com/tutorials/amqp-concepts#exchange-default

+ */ "", /* routingKey */ queueName, /* properties */ null, message);

+ count = 0;

+ this.closed = true;

+ throw new IOException("AMPQ Channel seems to be closed!");

+ } catch (IOException e) {

+ logger.log(Level.SEVERE, "IOException while sending data to RabbitMQ queue "+queueName, e);

+ throw e; // re-throw; callers will have to know that their write failed

+ // The re-throw will most likely lead to a writeFatalException(...) on the ObjectOutputStream

+ // which doesn't help really because it breaks the protocol.

+echo "$STATUS" | grep "^{" | jq -C .

+ - Announcements relevant for developers are posted on [GitHub](https://github.com/SAP/sailing-analytics) in the Discussions tab. In order to get notifications you can subscribe to discussions by clicking on "Watch" in the Repository, then "Custom". In the new Popup select "Discussions" and confirm by clicking "Apply".

+

+ <img src="/wiki/images/github/GitHubWatch.jpg" style="width: 50%"/>

+ <img src="/wiki/images/github/GitHubSubscribe.jpg" style="width: 45%"/>

+ Everytime you use your ssh key with encryption key you get prompted to provide the passphrase.

+ To automate this process you can setup an ssh agent. On Linux your desktop environment will usually handle this for you. For macOS you can use this [guide](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent).

+1. Eclipse IDE for Eclipse Committers, version ["2025-12"](https://www.eclipse.org/downloads/packages/release/2025-12/r/eclipse-ide-eclipse-committers). If you are using a Mac and want to use SAPJVM, this has to be the 64 bit version. This is because SAPJVM is not available for Apple Silicon Macs, and Eclipse's OS architecture must match the JVM architecture. Mac users can install SDKMAN! to manage and install different JDKs. For example Amazon Corretto 8: `sdk install java 8.0.472-amzn`.

+3. Git (e.g. Git for Windows v2.18), [http://git-scm.com](http://git-scm.com) / [https://git-for-windows.github.io](https://git-for-windows.github.io) still

+4. Configure git (see [Git repository configuration essentials](#git-repository-configuration-essentials))

+ You will see in section [Tuning the Eclipse Installation](#tuning-the-eclipse-installation)

+11. Install the eclipse plugins (see [Automatic Eclipse plugin installation](#automatic-eclipse-plugin-installation))

+12. Configure Eclipse (see [Tuning the Eclipse Installation](#tuning-the-eclipse-installation))

+13. Configure Maven to use the correct JRE by following the instructions in the paragraph [maven-setup](#maven-setup)

+14. Follow the instructions in the [development setup](#sap-sailing-analytics-development-setup) to build the project.

+15. The steps for building the project for a deployment can be found in the [Build for deployment](#build-for-deployment) section. This is not needed in the daily development workflow and should only be run when needed.

+The necessary Eclipse plugins can be automatically installed into a newly unzipped version of ["2025-12"](https://www.eclipse.org/downloads/packages/release/2025-12/r/eclipse-ide-eclipse-committers) by using the `./configuration/pluginsForEclipse2025-12.p2f` file, found in the git repository cloned in _step 11_. To install the plugins open Eclipse and install Software Items from File. (File ⇒ Import ⇒ Install ⇒ Install Software from File). The description file is located at `/configuration/pluginsForEclipse2025-12.p2f`.

+If you want a hudson job to run when you push your branch then you can run a script in `configuration` called `createHudsonJobForBug.sh`. For you bug branch titled `bug<bug number>`, create a build job, which will create a release, by running the script like so: `./createHudsonJobForBug.sh <bug number>`.

+If you'd like the script to include the bug's summary in its description, set your BUGZILLA_API_KEY environment variable to an API key you obtain from [https://bugzilla.sapsailing.com/bugzilla/userprefs.cgi?tab=apikey](https://bugzilla.sapsailing.com/bugzilla/userprefs.cgi?tab=apikey) or pass the API key as the second argument, after the bug ID, as in

+`./configuration/createHudsonJobForBug.sh <bug number> {Bugzilla-API-Key}`

+In the ``azure-pipelines/main.yml`` file under the ``trigger:`` property we configure which Git branches and/or tags shall trigger a pipeline execution. The core part then is defined by a reference to the pipeline's template, and specific adjustments can then be made to the template pipeline in the ``extends:`` section. The ``isRelease`` boolean property controls whether the build shall be a release build that triggers code signing, in particular. The ``productiveBranchName`` property controls for buils of which branch all scanning and test tasks shall be performed. We required special adjustments of the ``jdkVersion`` property to ``17`` and the ``androidVersion`` to ``35`` for our Gradle app build to work. Furthermore, the MoMa Assembly ID must be configured in the ``momaAssemblyId`` property. Each app folder now has its own ``files2sign.json`` file in its app folder under ``mobile/`` because this allows us to limit the build output to files under the app's own folder.

+

+To release the apps, go to the MoMa records of the two apps ([https://moma.mo.sap.corp/#/apps/124](https://moma.mo.sap.corp/#/apps/124) and [https://moma.mo.sap.corp/#/apps/123](https://moma.mo.sap.corp/#/apps/123)) and from there into the Assembly-Data and press the "Add Release" button. Make sure the "Build System" is set to "free - Hyperspace Azure Pipelines". Make sure you set the "Is this build to be uploaded to Google Play Store (after manual approval)?" field to "Yes - directly to Google Play (General Availability)" in case you have tested you apps already and are sure they can be uploaded to the public store. Otherwise, select "Yes - but to Google Closed Track first (with option for GA afterwards)" which will upload to the Google Closed Track store first, so you can test the apps once more prior to publication. In this case you'll have to resume or reject the "Manual Validation" step (GP Prod Deploy?) after your tests. Then run the ``configuration/releaseAndroidApps.sh`` script, like this:

+When the release pipelines ran successfully, they will have updated the MoMa assembly metadata for the respective apps, including the version numbers and the staging repositories used.

+

+(In previous pipeline versions, a "Build Release Pipeline Project Link" was generated, such as [https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.android.buoy.positioning.app-android/](https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.android.buoy.positioning.app-android/) for the SAP Sailing Buoy Pinger app, and [https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.racecommittee.app-android/](https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.racecommittee.app-android/) for the SAP Sailing Race Manager app. Before using these pipelines, we would go to the MoMa Google Play Metadata section for each app you'd like to release and click on "Add Release" there, too. You will have to make a few adjustments to some fields, such as that you're only releasing a "Patch" with specific release notes which you then have to submit to naming@sap.com for approval before you can send them to LXLabs using the respective button on the Google Play Metadata page in MoMa. Only once you have all approvals in place, use the "Build Release Pipeline Project Link" for the app you'd like to release and run a build there. Note that these builds have interactive steps that pause and ask you to confirm the promotion to the Play Store. Your released app(s) should then show in the Google Play Store after a few hours.)

+Now (2026-01-23) the "NAAS Promote" step in the Azure build pipeline will upload the readily-built apps to the Google Play store (supposedly after a human-in-the-loop confirmation). We haven't completed this process yet because we are currently still in the transition. NAAS, however,