Error, warnings when running sample hello-world-notification-microservice (Nofitication 2.0)

When I run the sample hello-world-notification-microservice (Nofitication 2.0) as a standalone SpringBoot applications, I get the following warnings:

2023-01-10 09:46:11.650  INFO 91855 --- [subscriptions-0] o.apache.http.impl.execchain.RetryExec   : Retrying request to {s}->
2023-01-10 09:49:23.576  INFO 91855 --- [subscriptions-0] o.apache.http.impl.execchain.RetryExec   : I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}-> The target server failed to respond

I use Cumulocity SDK 1016.181.0.

What is the reason for these warnings?
How does this affect the correct behaviour of: receiving and acknowledging notifications?

Regards Christof

A very basic observation – there is no such tenant as – could that be relevant?

Hi Robert,
I used an anonym tenant name just here in this posting.
I tested this with my actual tenant and the messages are from this tenant.

Can you please check if in your application properties file you have added the below 3 entries / //kindly provide a valid device id from your tenant

example.websocket.url=wss://{{Your Valid tenant URL}}:443


Hope this could help


I updated these properties. And basically this sample works for some time. When no notifications are received for 5 minutes, the connection is closed and no more notifications are received
This is reported in the log file.

I now tried to raise the maxIdleTimeout using the following code:

    public JettyWebSocketClient(URI serverUri, NotificationCallback callback) {
        this.serverUri = serverUri;
        this.callback = callback;

    public void connect() throws Exception {
        WebSocketClient client = new WebSocketClient();
        client.connect(this, this.serverUri, new ClientUpgradeRequest());

But this is setting is not taken into account and the connection is closed anyway.
How to change (raise maxIdleTimeout) this behaviour in the sample?

I implemented a constant ping as described in this post.

In this case an idle connection is not closed.