[BUG] Connections to service bus dropped and recreated regularly when using ServiceBusSessionReceiverAsyncClient bean

Describe the bug
I am creating a Spring Bean with an ServiceBusSessionReceiverAsyncClient so that I can reuse this in my REST API based application.
	@Bean
	 public ServiceBusSessionReceiverAsyncClient apiMessageQueueIntegrator() {

		return new ServiceBusClientBuilder()
		.transportType(AmqpTransportType.AMQP_WEB_SOCKETS)
        .connectionString(connectionString)
        .sessionReceiver()
        .receiveMode(ServiceBusReceiveMode.RECEIVE_AND_DELETE)
        .queueName(queueName)
        .buildAsyncClient();
	}

In an @RestController, I do the following:
	@Autowired
	ServiceBusSessionReceiverAsyncClient apiMessageQueueIntegrator;
.
.
.
	@GetMapping("/simulateapicall")
	public ResponseEntity<?> processApiCall() {
.
.
.
		Mono<ServiceBusReceiverAsyncClient> receiverMono = apiMessageQueueIntegrator.acceptSession(sessionid);

		Disposable subscription = Flux.usingWhen(receiverMono,
	            receiver -> receiver.receiveMessages(),
	            receiver -> Mono.fromRunnable(() -> receiver.close()))
	            .subscribe(message -> {
	                // Process message.
	                logger.info(String.format("Message received from queue. Session id: %s. Contents: %s%n", message.getSessionId(),
	                    message.getBody()));

	            }, error -> {
	                logger.info("Queue error occurred: " + error);
	            });

.
.
.
		// After having received message
                  subscription.dispose();
}

(NB! I am sending/receiving only one message per session. I use this in an request/reply scheme.)
This code logic works fine, but when running load testing, I see that the link to the service bus, is closed regularly and reopened. It seems that the connection to the service bus lives for 1-2 seconds, and is then closed and a new connection is opened. This causes issues because my sessions (from acceptSession), gets broken or fails when trying to be created.
It might seem that the dropped connections happens more if I increase the load towards the application.
Exception or Stack Trace
I have attached a file that shows the typical lifecycle of the connection. From when it is created to when it is dropped. My log files typically consists of many such lifecycles as connections are dropped and recreated.
error_log_2.txt
To Reproduce
Create similar code to what I have described. Run jMeter to put load on.
Code Snippet
See bug description.
Expected behavior
I expect the connection to the service bus to be kept up and not terminated.
Screenshots
N/A
Setup (please complete the following information):

OS: Azure app service (Linux, Java 11)
Library/Libraries: azure-messaging-servicebus:7.5.0
Java version: 11
App Server/Environment: Azure app service
Frameworks: Spring Boot

Additional context
N/A
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Bug Description Added
[x] Repro Steps Added
[x] Setup information Added

I changed the client to a synchronous client instead, and now I am seeing these messages in the log:
2021-11-29 06:09:27,552 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-1] onSessionRemoteClose connectionId[api_message_queue], entityName[MF_46773d_1638165572501], condition[Error{condition=amqp:resource-limit-exceeded, description='Cannot allocate more handles to the current session or connection. The maximum number of handles allowed is 255. Please free up resources and try again.', info=null}]
2021-11-29 06:09:27,567 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-1] onSessionRemoteClose closing a local session for connectionId[MF_46773d_1638165572501], entityName[api_message_queue], condition[amqp:resource-limit-exceeded], description[Cannot allocate more handles to the current session or connection. The maximum number of handles allowed is 255. Please free up resources and try again.]
2021-11-29 06:09:27,575 ERROR reactor.util.Loggers$Slf4JLogger [reactor-executor-1] Operator called default onErrorDropped
reactor.core.Exceptions$ErrorCallbackNotImplemented: com.azure.core.amqp.exception.AmqpException: onSessionRemoteClose connectionId[MF_46773d_1638165572501], entityName[api_message_queue] condition[Error{condition=amqp:resource-limit-exceeded, description='Cannot allocate more handles to the current session or connection. The maximum number of handles allowed is 255. Please free up resources and try again.', info=null}], errorContext[NAMESPACE: nppkafkapoc.servicebus.windows.net. ERROR CONTEXT: N/A, PATH: api_message_queue]
Caused by: com.azure.core.amqp.exception.AmqpException: onSessionRemoteClose connectionId[MF_46773d_1638165572501], entityName[api_message_queue] condition[Error{condition=amqp:resource-limit-exceeded, description='Cannot allocate more handles to the current session or connection. The maximum number of handles allowed is 255. Please free up resources and try again.', info=null}], errorContext[NAMESPACE: nppkafkapoc.servicebus.windows.net. ERROR CONTEXT: N/A, PATH: api_message_queue]
	at com.azure.core.amqp.implementation.ExceptionUtil.toException(ExceptionUtil.java:85)
	at com.azure.core.amqp.implementation.handler.SessionHandler.onSessionRemoteClose(SessionHandler.java:128)
	at org.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:152)
	at org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)
	at org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324)
	at org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:291)
	at com.azure.core.amqp.implementation.ReactorExecutor.run(ReactorExecutor.java:92)
	at reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68)
	at reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
2021-11-29 06:09:27,581 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-1] connectionId[MF_46773d_1638165572501] sessionName[api_message_queue]: Error occurred. Removing and disposing session.

So I guess the number of open connections per client is an issue. Is there anywhere I can adjust this 255 limit? Or do I need to create an array of clients and spread the traffic across them?

I did some more testing. Created an array of ServiceBusSessionReceiverClient with 20 clients, and randomly picks one when establishing the session. This reduces the issues, but I still see errors where the connection is closed.
How can I find out what causes the connection to close?
2021-11-30 09:41:39,153 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] onConnectionError connectionId[MF_abe7ce_1638264786203], hostName[nppkafkapoc.servicebus.windows.net], message[Starting new reactor], error[connectionId[MF_abe7ce_1638264786203] IO Sink was interrupted before reactor closed.]
2021-11-30 09:41:39,153 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] signal[onReactorError: java.lang.RuntimeException: connectionId[MF_abe7ce_1638264786203] IO Sink was interrupted before reactor closed., isTransient[false], initiatedByClient[false]]: Disposing of ReactorConnection.
2021-11-30 09:41:39,154 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] sessionName[api_message_queue] RejectedExecutionException when scheduling work.
2021-11-30 09:41:39,155 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] sessionName[cbs-session] RejectedExecutionException when scheduling work.
2021-11-30 09:41:39,155 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-13] onLinkRemoteClose connectionId[MF_abe7ce_1638264786203] linkName[9e6d8040-860d-41f8-a318-6c5b16a08951], errorCondition[null] errorDescription[null]
2021-11-30 09:41:39,179 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] linkName[e1443d02-c0dd-4fee-89bf-32004d2b82ed] RejectedExecutionException when scheduling on ReactorDispatcher. Manually invoking and completing close.
2021-11-30 09:41:39,180 INFO com.azure.core.util.logging.ClientLogger [boundedElastic-130] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Unable to schedule close work. Closing manually.
2021-11-30 09:41:39,186 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-13] onLinkRemoteOpen connectionId[MF_abe7ce_1638264786203], entityPath[api_message_queue], linkName[e1443d02-c0dd-4fee-89bf-32004d2b82ed], remoteSource[Source{address='api_message_queue', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter={com.microsoft:session-filter=e1443d02-c0dd-4fee-89bf-32004d2b82ed}, defaultOutcome=null, outcomes=null, capabilities=null}]
2021-11-30 09:41:39,186 WARN com.azure.core.util.logging.ClientLogger [reactor-executor-13] connectionId[MF_abe7ce_1638264786203] message[Unhandled exception while processing events in reactor, report this error.]
2021-11-30 09:41:39,187 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-13] onConnectionError connectionId[MF_abe7ce_1638264786203], hostName[nppkafkapoc.servicebus.windows.net], message[Starting new reactor], error[Spec. Rule 1.3 - onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled serially., TrackingId: 376ed1d6-adb6-49a9-a6d7-e8b7253b046e, at: 2021-11-30T09:41:39.187084Z[GMT], errorContext[NAMESPACE: nppkafkapoc.servicebus.windows.net. ERROR CONTEXT: N/A]]
2021-11-30 09:41:39,355 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] onConnectionShutdown connectionId[MF_abe7ce_1638264786203], hostName[nppkafkapoc.servicebus.windows.net], message[Shutting down], shutdown signal[true]
2021-11-30 09:42:39,182 INFO com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Timed out waiting for RequestResponseChannel to complete closing. Manually closing.
2021-11-30 09:42:39,188 INFO com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Channel is closed. Requesting upstream.
2021-11-30 09:42:39,188 INFO com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Connection not requested, yet. Requesting one.
2021-11-30 09:42:39,192 INFO com.azure.core.util.logging.ClientLogger [boundedElastic-74] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Unable to schedule close work. Closing manually.
2021-11-30 09:42:39,197 ERROR com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] linkName[cbs]: Unable to open send and receive link.
2021-11-30 09:42:39,197 WARN com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Retry #1. Retry attempts exhausted or exception was not retriable.
connectionId[MF_abe7ce_1638264786203] linkName[cbs]: Unable to open send and receive link.
2021-11-30 09:42:39,198 INFO com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Error in AMQP channel processor. Notifying 0 subscribers.
2021-11-30 09:42:39,198 INFO com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] Could not schedule closeConnection work. Manually disposing.
2021-11-30 09:42:39,198 INFO com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] Closing executor.
2021-11-30 09:43:39,195 INFO com.azure.core.util.logging.ClientLogger [parallel-1] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Timed out waiting for RequestResponseChannel to complete closing. Manually closing.

I did some more testing. Created an array of ServiceBusSessionReceiverClients with 20 clients and picking one of them randomly when connecting to the session. The problem is decreased, but still the clients drops its connections:
2021-11-30 09:41:39,153 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] onConnectionError connectionId[MF_abe7ce_1638264786203], hostName[hiddenname.servicebus.windows.net], message[Starting new reactor], error[connectionId[MF_abe7ce_1638264786203] IO Sink was interrupted before reactor closed.]
2021-11-30 09:41:39,153 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] signal[onReactorError: java.lang.RuntimeException: connectionId[MF_abe7ce_1638264786203] IO Sink was interrupted before reactor closed., isTransient[false], initiatedByClient[false]]: Disposing of ReactorConnection.
2021-11-30 09:41:39,154 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] sessionName[api_message_queue] RejectedExecutionException when scheduling work.
2021-11-30 09:41:39,155 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] sessionName[cbs-session] RejectedExecutionException when scheduling work.
2021-11-30 09:41:39,155 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-13] onLinkRemoteClose connectionId[MF_abe7ce_1638264786203] linkName[9e6d8040-860d-41f8-a318-6c5b16a08951], errorCondition[null] errorDescription[null]
2021-11-30 09:41:39,179 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] linkName[e1443d02-c0dd-4fee-89bf-32004d2b82ed] RejectedExecutionException when scheduling on ReactorDispatcher. Manually invoking and completing close.
2021-11-30 09:41:39,180 INFO com.azure.core.util.logging.ClientLogger [boundedElastic-130] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Unable to schedule close work. Closing manually.
2021-11-30 09:41:39,186 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-13] onLinkRemoteOpen connectionId[MF_abe7ce_1638264786203], entityPath[api_message_queue], linkName[e1443d02-c0dd-4fee-89bf-32004d2b82ed], remoteSource[Source{address='api_message_queue', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter={com.microsoft:session-filter=e1443d02-c0dd-4fee-89bf-32004d2b82ed}, defaultOutcome=null, outcomes=null, capabilities=null}]
2021-11-30 09:41:39,186 WARN com.azure.core.util.logging.ClientLogger [reactor-executor-13] connectionId[MF_abe7ce_1638264786203] message[Unhandled exception while processing events in reactor, report this error.]
2021-11-30 09:41:39,187 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-13] onConnectionError connectionId[MF_abe7ce_1638264786203], hostName[hiddenname.servicebus.windows.net], message[Starting new reactor], error[Spec. Rule 1.3 - onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled serially., TrackingId: 376ed1d6-adb6-49a9-a6d7-e8b7253b046e, at: 2021-11-30T09:41:39.187084Z[GMT], errorContext[NAMESPACE: hiddenname.servicebus.windows.net. ERROR CONTEXT: N/A]]
2021-11-30 09:41:39,355 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] onConnectionShutdown connectionId[MF_abe7ce_1638264786203], hostName[hiddenname.servicebus.windows.net], message[Shutting down], shutdown signal[true]
2021-11-30 09:42:39,182 INFO com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Timed out waiting for RequestResponseChannel to complete closing. Manually closing.
2021-11-30 09:42:39,188 INFO com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Channel is closed. Requesting upstream.
2021-11-30 09:42:39,188 INFO com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Connection not requested, yet. Requesting one.
2021-11-30 09:42:39,192 INFO com.azure.core.util.logging.ClientLogger [boundedElastic-74] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Unable to schedule close work. Closing manually.
2021-11-30 09:42:39,197 ERROR com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] linkName[cbs]: Unable to open send and receive link.
2021-11-30 09:42:39,197 WARN com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Retry #1. Retry attempts exhausted or exception was not retriable.
connectionId[MF_abe7ce_1638264786203] linkName[cbs]: Unable to open send and receive link.
2021-11-30 09:42:39,198 INFO com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Error in AMQP channel processor. Notifying 0 subscribers.
2021-11-30 09:42:39,198 INFO com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] Could not schedule closeConnection work. Manually disposing.
2021-11-30 09:42:39,198 INFO com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] Closing executor.
2021-11-30 09:43:39,195 INFO com.azure.core.util.logging.ClientLogger [parallel-1] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Timed out waiting for RequestResponseChannel to complete closing. Manually closing.

RE: https://github.com/Azure/azure-sdk-for-java/issues/25718#issuecomment-981324013
The error condition amqp:resource-limit-exceeded is sent from the service, it is saying that there are too many active receiving clients on your end. Are you properly disposing of each client after you use them?
RE: Sample code
I do not think you're using this correctly. What subscribe does is hook up the callbacks, it does not block the running thread until a message is received. If you are waiting for a synchronous receive, you should consider chaining .block() rather than a subscribe to this reactor chain.
@GetMapping("/simulateapicall")
public ResponseEntity<?> processApiCall() {
    Mono<ServiceBusReceiverAsyncClient> receiverMono = apiMessageQueueIntegrator.acceptSession(sessionid);
    Disposable subscription = Flux.usingWhen(receiverMono,
            receiver -> receiver.receiveMessages(),
            receiver -> Mono.fromRunnable(() -> receiver.close()))
            .subscribe(message -> {
                // Process message.
                logger.info(String.format("Message received from queue. Session id: %s. Contents: %s%n", message.getSessionId(),
                    message.getBody()));

            }, error -> {
                logger.info("Queue error occurred: " + error);
            });

    // After having received message
    subscription.dispose();
}

Thanks for your reply! I am aware that it is not blocking.
I did not include the code (to avoid confusing the main issues), but I block the thread by using a CountDownLatch that I decrease each time I receive a message. This CountDownLatch has a timeout, and in that way I am able to wait for the correct number of messages to arrive, and it also gives me a nice timeout.
I am actually just waiting for one message to arrive, and you gave me a nice answer in another issue on how to rewrite it from Flux to Mono.
But I took another approach and got rid of the Async alltogether, and reimplemented it as:
  @Autowired
  ServiceBusSessionReceiverClient apiMessageQueueIntegrator;

  ServiceBusReceiverClient receiverClient = apiMessageQueueIntegrator.acceptSession(sessionid);

  IterableStream<ServiceBusReceivedMessage> receiveStream = receiverClient.receiveMessages(1, Duration.ofSeconds(timeout));

  receiveStream.stream().forEach(message -> {
	  logger.info("*** Received message! ***");
	  receivedMessage = message;
	  });

  receiverClient.close();

I don't get the too many handles errors any more, but the connections to the service bus are still disappearing. Below is log extract from the lifecycle of one of the connections of one such ServiceBusClient. It connects, and I am able to use it for a while, but then suddenly, the connection is removed. I loose all my connected sessions, and I am also not able to create new sessions on the client until it has reconnected properly.
I've spent countless hours now trying to figure out why this happens. Why does the ServiceBusReceiveClient suddenly loose the connection?
Can it be something related to this being a session receiver? Is there some logic "deep down" that actually will close the ServiceBusSessionReceiverClient connection when I have finished the work against the session - even if I don't do it explicitly? As you can see from the code, I close the client that I got as return from the call to acceptSession, but I do not close the main ServiceBusSessionReceiverClient until the bean is destroyed (application shutdown).
I actually tried to create a pool of ServiceBusSessionReceiverClient to split the load on more than one, but the issue still remains. The strange thing is that compared to only running with one client, each client it is able to handle fewer sessions until it drops the connection when I pool them.
I am poc'ing a new solution, and wanted to use ServiceBus for this, but if I cannot solve these connection issues, I need to reconsider it. This seems very straight forward. The only special thing is that I create a lot of session connections to the queue because this is done from a rest controller with a lot of traffic.

2021-11-30 09:41:39,153 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] onConnectionError connectionId[MF_abe7ce_1638264786203], hostName[hiddenname.servicebus.windows.net], message[Starting new reactor], error[connectionId[MF_abe7ce_1638264786203] IO Sink was interrupted before reactor closed.]
2021-11-30 09:41:39,153 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] signal[onReactorError: java.lang.RuntimeException: connectionId[MF_abe7ce_1638264786203] IO Sink was interrupted before reactor closed., isTransient[false], initiatedByClient[false]]: Disposing of ReactorConnection.
2021-11-30 09:41:39,154 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] sessionName[api_message_queue] RejectedExecutionException when scheduling work.
2021-11-30 09:41:39,155 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] sessionName[cbs-session] RejectedExecutionException when scheduling work.
2021-11-30 09:41:39,155 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-13] onLinkRemoteClose connectionId[MF_abe7ce_1638264786203] linkName[9e6d8040-860d-41f8-a318-6c5b16a08951], errorCondition[null] errorDescription[null]
2021-11-30 09:41:39,179 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] connectionId[MF_abe7ce_1638264786203] linkName[e1443d02-c0dd-4fee-89bf-32004d2b82ed] RejectedExecutionException when scheduling on ReactorDispatcher. Manually invoking and completing close.
2021-11-30 09:41:39,180 INFO com.azure.core.util.logging.ClientLogger [boundedElastic-130] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Unable to schedule close work. Closing manually.
2021-11-30 09:41:39,186 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-13] onLinkRemoteOpen connectionId[MF_abe7ce_1638264786203], entityPath[api_message_queue], linkName[e1443d02-c0dd-4fee-89bf-32004d2b82ed], remoteSource[Source{address='api_message_queue', durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter={com.microsoft:session-filter=e1443d02-c0dd-4fee-89bf-32004d2b82ed}, defaultOutcome=null, outcomes=null, capabilities=null}]
2021-11-30 09:41:39,186 WARN com.azure.core.util.logging.ClientLogger [reactor-executor-13] connectionId[MF_abe7ce_1638264786203] message[Unhandled exception while processing events in reactor, report this error.]
2021-11-30 09:41:39,187 INFO com.azure.core.util.logging.ClientLogger [reactor-executor-13] onConnectionError connectionId[MF_abe7ce_1638264786203], hostName[hiddenname.servicebus.windows.net], message[Starting new reactor], error[Spec. Rule 1.3 - onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled serially., TrackingId: 376ed1d6-adb6-49a9-a6d7-e8b7253b046e, at: 2021-11-30T09:41:39.187084Z[GMT], errorContext[NAMESPACE: hiddenname.servicebus.windows.net. ERROR CONTEXT: N/A]]
2021-11-30 09:41:39,355 INFO com.azure.core.util.logging.ClientLogger [receiver-0-328] onConnectionShutdown connectionId[MF_abe7ce_1638264786203], hostName[hiddenname.servicebus.windows.net], message[Shutting down], shutdown signal[true]
2021-11-30 09:42:39,182 INFO com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Timed out waiting for RequestResponseChannel to complete closing. Manually closing.
2021-11-30 09:42:39,188 INFO com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Channel is closed. Requesting upstream.
2021-11-30 09:42:39,188 INFO com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Connection not requested, yet. Requesting one.
2021-11-30 09:42:39,192 INFO com.azure.core.util.logging.ClientLogger [boundedElastic-74] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Unable to schedule close work. Closing manually.
2021-11-30 09:42:39,197 ERROR com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] linkName[cbs]: Unable to open send and receive link.
2021-11-30 09:42:39,197 WARN com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Retry #1. Retry attempts exhausted or exception was not retriable.
connectionId[MF_abe7ce_1638264786203] linkName[cbs]: Unable to open send and receive link.
2021-11-30 09:42:39,198 INFO com.azure.core.util.logging.ClientLogger [parallel-2] namespace[MF_abe7ce_1638264786203] entityPath[$cbs]: Error in AMQP channel processor. Notifying 0 subscribers.
2021-11-30 09:42:39,198 INFO com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] Could not schedule closeConnection work. Manually disposing.
2021-11-30 09:42:39,198 INFO com.azure.core.util.logging.ClientLogger [parallel-2] connectionId[MF_abe7ce_1638264786203] Closing executor.
2021-11-30 09:43:39,195 INFO com.azure.core.util.logging.ClientLogger [parallel-1] connectionId[MF_abe7ce_1638264786203] linkName[cbs] Timed out waiting for RequestResponseChannel to complete closing. Manually closing.

@conniey

Me

/unresolve

Looking at your log snippet, we aren't able to recover due to an error here: #24762.

Could you upload the entire application log?
Could you explain the usage pattern for the session receiver? Are there long-lived instances of ServiceBusReceiverClient or are they opened, receive a few messages, and then closed?

The application works like this:
There are 3 apps involved in the value chain.
A REST API is defined to receive requests in app_1. Upon request to the API, the following is done:

Send a request to an external system (app_2) (a REST call). This call includes an UUID that we can call "uuid_sessionid".
App_1 establishes a session towards the service bus queue. The session id used is "uuid_sessionid"
When the external system app_2 has finished its work, it emits an event on an event queue (including the received uuid_sessionid". There is a separate event ingester (app_3) that eventually will ingest this event and add a message to the service bus queue with sessionid "uuid_sessionid" (part of the event data).
App_1 will receive this message (because it is listening to the session queue), and return result to the initial caller of the REST API.

There are many short-lived requests towards app_1. App_1 will time-out after 5 seconds if message has not been received on queue. The ServiceBusReceiverClient will receive max 1 message before closing - so it is very short lived. The ServiceBusSessionReceiverClient (from where the ServiceBusReceiverClient) are created is a Spring Bean - so it will live the whole life-cycle of the application. It is @Autowired into the controller class.
The attached log has been created ny running 25 simultaneously users from jMeter towards app_1. The users will do 50 calls each. I stopped the jMeter jo after 329 requests (when I saw that they started failing).
I have attached a full log from application start to application shutdown. I've removed ip-addresses (x.x.x.x / y.y.y.y) and other minor changes to hide real names/addresses.
full_debug_log.txt

From an initial look at the looks, it appears that when the session is closed, it also closes the underlying proton-j Reactor instance, which causes the creation of a new connection. Digging some more into it.

We are observing similar errors.
Environment: Azure Container Instances, JDK, Spring, ServiceBus
        <groupId>com.azure</groupId>
        <artifactId>azure-messaging-servicebus</artifactId>
        <version>7.5.0</version>

2022-01-25 11:06:48.287	ERROR	Exception occurred when handling event in super.
uncorrelated channel: 0
2022-01-25 11:06:48.284	INFO	onConnectionRemoteOpen hostname[sb-ns-name.servicebus.windows.net], connectionId[MF_f2ee13_1643049415858], remoteContainer[215ad176b4464c4488eba3ba48b74039_G10]
2022-01-25 11:06:48.284	ERROR	Exception occurred when handling event in super.
uncorrelated channel: 0
2022-01-25 11:06:48.245	INFO	onConnectionLocalClose connectionId[MF_f2ee13_1643049415858] hostname[sb-ns-name.servicebus.windows.net] errorCondition[null] errorDescription[null]
2022-01-25 11:06:48.188	INFO	connectionId[MF_f2ee13_1643049415858] Closing executor.
2022-01-25 11:06:48.180	ERROR	connectionId[MF_f2ee13_1643049415858] sessionName[queue_name] entityPath[queue_name] linkName[queue_name_7d62eb_1643049416842] Cannot create receive link from a closed session., errorContext[NAMESPACE: sb-ns-name.servicebus.windows.net. ERROR CONTEXT: N/A, PATH: queue_name]
2022-01-25 11:06:48.141	INFO	Closing Global Endpoint Manager ...
2022-01-25 11:06:48.141	INFO	Shutting down ...
2022-01-25 11:06:48.140	INFO	Attempting to close client 0
2022-01-25 11:06:47.957	INFO	Shutting down the TelemetryClient background Executor
2022-01-25 11:06:47.889	INFO	onSessionRemoteClose connectionId[cbs-session], entityName[MF_5a8526_1643049414955], condition[Error{condition=null, description='null', info=null}]
2022-01-25 11:06:47.887	INFO	onSessionRemoteClose connectionId[eventhub_name], entityName[MF_5a8526_1643049414955], condition[Error{condition=null, description='null', info=null}]
2022-01-25 11:06:47.882	INFO	namespace[eventhub_namespace.servicebus.windows.net] entityPath[eventhub_name]: Channel is disposed.
2022-01-25 11:06:47.880	INFO	connectionId[MF_5a8526_1643049414955] signal[Disposed by client., isTransient[false], initiatedByClient[true]]: Disposing of ReactorConnection.
2022-01-25 11:06:47.878	INFO	namespace[eventhub_namespace.servicebus.windows.net] entityPath[eventhub_name]: AMQP channel processor completed. Notifying 0 subscribers.
2022-01-25 11:06:47.877	INFO	Upstream connection publisher was completed. Terminating processor.
2022-01-25 11:06:47.865	INFO	namespace[sb-ns-name.servicebus.windows.net] entityPath[N/A]: Channel is disposed.
2022-01-25 11:06:47.860	INFO	connectionId[MF_f2ee13_1643049415858] signal[Disposed by client., isTransient[false], initiatedByClient[true]]: Disposing of ReactorConnection.
2022-01-25 11:06:47.858	INFO	namespace[sb-ns-name.servicebus.windows.net] entityPath[N/A]: AMQP channel processor completed. Notifying 0 subscribers.
2022-01-25 11:06:47.857	INFO	Upstream connection publisher was completed. Terminating processor.
2022-01-25 11:06:47.856	INFO	No more open clients, closing shared connection [ServiceBusConnectionProcessor].
2022-01-25 11:06:47.850	INFO	Closing a dependent client. # of open clients: 0
2022-01-25 11:06:47.848	INFO	Removing receiver links.
2022-01-25 11:06:47.686	INFO	connectionId[MF_807fbb_1643049415850] linkName[queue_name-mgmt] entityPath[queue_name/$management] Receiver link was never active. Closing endpoint states.
2022-01-25 11:06:47.685	INFO	connectionId[MF_807fbb_1643049415850] linkName[queue_name-mgmt] entityPath[queue_name/$management] Sender link was never active. Closing endpoint states.
2022-01-25 11:06:47.673	INFO	onSessionRemoteClose connectionId[queue_name-mgmt-session], entityName[MF_807fbb_1643049415850], condition[Error{condition=null, description='null', info=null}]
2022-01-25 11:06:47.671	INFO	namespace[MF_807fbb_1643049415850] entityPath[queue_name/$management]: Error in AMQP channel processor. Notifying 0 subscribers.
2022-01-25 11:06:47.671	WARN	namespace[MF_807fbb_1643049415850] entityPath[queue_name/$management]: Retry #1. Retry attempts exhausted or exception was not retriable.
connectionId[MF_807fbb_1643049415850] linkName[queue_name-mgmt]: Unable to open send and receive link.
2022-01-25 11:06:47.671	ERROR	connectionId[MF_807fbb_1643049415850] linkName[queue_name-mgmt]: Unable to open send and receive link.
2022-01-25 11:06:47.669	INFO	connectionId[MF_807fbb_1643049415850] linkName[queue_name-mgmt] Unable to schedule close work. Closing manually.
2022-01-25 11:06:47.669	WARN	ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.
2022-01-25 11:06:47.669	WARN	ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.
2022-01-25 11:06:47.668	INFO	namespace[MF_807fbb_1643049415850] entityPath[queue_name/$management]: Connection not requested, yet. Requesting one.
2022-01-25 11:06:47.668	INFO	namespace[MF_807fbb_1643049415850] entityPath[queue_name/$management]: Channel is closed. Requesting upstream.
2022-01-25 11:06:47.660	INFO	onConnectionBound connectionId[MF_f2ee13_1643049415858] hostname[sb-ns-name.servicebus.windows.net] peerDetails[sb-ns-name.servicebus.windows.net:5671]
2022-01-25 11:06:47.658	INFO	onLinkRemoteClose connectionId[MF_807fbb_1643049415850] linkName[queue_name-mgmt:receiver], errorCondition[null] errorDescription[null]
2022-01-25 11:06:47.657	INFO	onLinkRemoteClose connectionId[MF_807fbb_1643049415850] linkName[queue_name-mgmt:sender], errorCondition[null] errorDescription[null]
2022-01-25 11:06:47.655	ERROR	lockToken[d1744f5d-00ac-4b14-a84d-6ba13cc9b078]. state[Accepted{}]. Cannot update disposition with no link.
2022-01-25 11:06:47.645	INFO	onConnectionLocalOpen connectionId[MF_f2ee13_1643049415858] hostname[sb-ns-name.servicebus.windows.net] errorCondition[null] errorDescription[null]
2022-01-25 11:06:47.643	INFO	connectionId[MF_f2ee13_1643049415858] reactor.onReactorInit
2022-01-25 11:06:47.639	INFO	onConnectionInit connectionId[MF_f2ee13_1643049415858] hostname[sb-ns-name.servicebus.windows.net] amqpHostname[sb-ns-name.servicebus.windows.net]
2022-01-25 11:06:47.590	INFO	connectionId[MF_f2ee13_1643049415858] message[Starting reactor.]
2022-01-25 11:06:47.589	INFO	connectionId[MF_f2ee13_1643049415858]: Creating and starting connection to sb-ns-name.servicebus.windows.net:5671
2022-01-25 11:06:47.563	INFO	connectionId[MF_807fbb_1643049415850] linkName[queue_name-mgmt] Unable to schedule close work. Closing manually.
2022-01-25 11:06:47.563	WARN	ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.
2022-01-25 11:06:47.560	WARN	connectionId[MF_807fbb_1643049415850], signal[onComplete], result[FAIL_TERMINATED]. Unable to emit shutdown signal.
2022-01-25 11:06:47.559	INFO	onLinkFinal connectionId[MF_807fbb_1643049415850], linkName[queue_name_7d62eb_1643049416842]
2022-01-25 11:06:47.559	INFO	connectionId[MF_807fbb_1643049415850] sessionName[queue_name-mgmt-session] RejectedExecutionException when scheduling work.
2022-01-25 11:06:47.553	WARN	ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.
2022-01-25 11:06:47.472	INFO	connectionId[MF_807fbb_1643049415850] linkName[queue_name_7d62eb_1643049416842] RejectedExecutionException when scheduling on ReactorDispatcher. Manually invoking and completing close.
2022-01-25 11:06:47.471	WARN	ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.
2022-01-25 11:06:47.459	INFO	connectionId[MF_807fbb_1643049415850] linkName[cbs] Unable to schedule close work. Closing manually.
2022-01-25 11:06:47.458	WARN	ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.
2022-01-25 11:06:47.458	INFO	onSessionRemoteClose connectionId[cbs-session], entityName[MF_807fbb_1643049415850], condition[Error{condition=null, description='null', info=null}]
2022-01-25 11:06:47.453	INFO	onSessionRemoteClose connectionId[queue_name], entityName[MF_807fbb_1643049415850], condition[Error{condition=null, description='null', info=null}]
2022-01-25 11:06:47.389	INFO	connectionId[MF_807fbb_1643049415850] sessionName[cbs-session] RejectedExecutionException when scheduling work.
2022-01-25 11:06:47.389	WARN	ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.
2022-01-25 11:06:47.361	INFO	connectionId[MF_807fbb_1643049415850] sessionName[queue_name] RejectedExecutionException when scheduling work.
2022-01-25 11:06:47.358	WARN	ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.
2022-01-25 11:06:47.338	INFO	namespace[sb-ns-name.servicebus.windows.net] entityPath[N/A]: Next AMQP channel received, updating 0 current subscribers
2022-01-25 11:06:47.338	INFO	namespace[sb-ns-name.servicebus.windows.net] entityPath[N/A]: Setting next AMQP channel.
2022-01-25 11:06:47.338	INFO	namespace[sb-ns-name.servicebus.windows.net] entityPath[N/A]: Connection not requested, yet. Requesting one.
2022-01-25 11:06:47.337	INFO	namespace[sb-ns-name.servicebus.windows.net] entityPath[N/A]: Channel is closed. Requesting upstream.
2022-01-25 11:06:47.263	INFO	connectionId[MF_807fbb_1643049415850] signal[onReactorError: java.lang.RuntimeException: connectionId[MF_807fbb_1643049415850] IO Sink was interrupted before reactor closed., isTransient[false], initiatedByClient[false]]: Disposing of ReactorConnection.
2022-01-25 11:06:47.262	INFO	onConnectionError connectionId[MF_807fbb_1643049415850], hostName[sb-ns-name.servicebus.windows.net], message[Starting new reactor], error[connectionId[MF_807fbb_1643049415850] IO Sink was interrupted before reactor closed.]
2022-01-25 11:06:47.256	WARN	connectionId[MF_807fbb_1643049415850] signalWorkQueue failed before reactor closed.
2022-01-25 11:06:47.237	INFO	Refreshing token. scopes[amqp://sb-ns-name.servicebus.windows.net/queue_name]

Just seen a stacktrace in the logs which seems to match the above error pattern, logs look nearly identical:
com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient.lambda$updateDisposition$43(ServiceBusReceiverAsyncClient.java:1340),
reactor.core.publisher.Mono.lambda$onErrorMap$31(Mono.java:3676),
reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onError(FluxOnErrorResume.java:94),
reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onError(MonoIgnoreThen.java:270),
reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.subscribeNext(MonoIgnoreThen.java:247),
reactor.core.publisher.MonoIgnoreThen.subscribe(MonoIgnoreThen.java:51),
reactor.core.publisher.Mono.subscribe(Mono.java:4338),
reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.subscribeNext(MonoIgnoreThen.java:255),
reactor.core.publisher.MonoIgnoreThen.subscribe(MonoIgnoreThen.java:51),
reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157),
reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816),
reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249),
reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.complete(MonoIgnoreThen.java:284),
reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onNext(MonoIgnoreThen.java:187),
reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.subscribeNext(MonoIgnoreThen.java:232),
reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onComplete(MonoIgnoreThen.java:203),
reactor.core.publisher.FluxFlatMap$FlatMapMain.checkTerminated(FluxFlatMap.java:846),
reactor.core.publisher.FluxFlatMap$FlatMapMain.drainLoop(FluxFlatMap.java:608),
reactor.core.publisher.FluxFlatMap$FlatMapMain.innerComplete(FluxFlatMap.java:894),
reactor.core.publisher.FluxFlatMap$FlatMapInner.onComplete(FluxFlatMap.java:997),
reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.onComplete(MonoPeekTerminal.java:299),
reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.onComplete(MonoPeekTerminal.java:299),
reactor.core.publisher.MonoPublishOn$PublishOnSubscriber.run(MonoPublishOn.java:190),
reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68),
reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28),
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264),
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304),
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128),
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628),
java.base/java.lang.Thread.run(Thread.java:829)

can you please increase the priority of this task? We have been waiting for a solution for a long time...

I'm experiencing the same problem. What coud I do to solve this problem in the meanwhile?

Looking for resolution on this same issue, any expected timeframe please.

Hi @quentinpopp @freedev @nikhilkumarenr @joan2424 @hargut @steinrr
I'm Zejia from Java SDK team, Recently I'm looking at this issue and working on it.
Firstly here is a workround:
Try to keep your client created by SessionClient.acceptSession(id) in your application, do not create and close client in each call. We also recommend using sessionClient in this way to reduce the cost of create and close client frequently.
There was a issue https://github.com/Azure/azure-sdk-for-java/issues/24762 fixed in February. We recommend upgrading to the latest version of ServiceBus SDK.
After upgrading, if the issue still remain, could you please provide DEBUG level logs and some code snippets. And I want to confirm that does all of you meet this issue in a heavy load scenario which means create and close client frequently?

Hi, few days ago I've updated to the latest ServiceBus SDK (com.azure:azure-messaging-servicebus:jar:7.8.0).
The situation seems to have been slightly changed, now after ~5 minutes of idle this exception is raised.
Anyway after the exception the app is still working because it seems a new connection is opened under the hood.
        serviceBusReceiverAsyncClient = serviceBusClientBuilder
                .transportType(AmqpTransportType.AMQP_WEB_SOCKETS)
                .receiver()
                .topicName(inTopicName)
                .subscriptionName(subscriptionName)
                .prefetchCount(prefetchCount)
                .maxAutoLockRenewDuration(this.maxAutoLockRenewDuration)
                .disableAutoComplete()
                .buildAsyncClient();

And then I subscribe new message with
        Multi.createFrom()
                .publisher(serviceBusReceiverAsyncClient.receiveMessages())
                .onItem()
                .transform(m -> this.consumeMessage(m))
                .subscribe()
                .with(o -> this.processReceivedMessage(o));

This is the exception raised:
2022-05-17 21:25:46,323 WARN  [com.azu.cor.amq.imp.RequestResponseChannel] (reactor-executor-3) {"az.sdk.message":"Error in SendLinkHandler. Disposing unconfirmed sends.","exception":"The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:6a5b592335994c66b9f3ef62ad4bee7e_G50, SystemTracker:gateway7, Timestamp:2022-05-17T21:25:46, errorContext[NAMESPACE: eldmangessbq01.servicebus.windows.net. ERROR CONTEXT: N/A, PATH: $cbs, REFERENCE_ID: cbs:sender, LINK_CREDIT: 97]","connectionId":"MF_0c2d51_1652795696565","linkName":"cbs"}
2022-05-17 21:25:46,329 WARN  [com.azu.cor.amq.imp.ReactorExecutor] (reactor-executor-3) {"az.sdk.message":"Unhandled exception while processing events in reactor, report this error.","exception":"java.lang.IllegalStateException","connectionId":"MF_0c2d51_1652795696565"}
2022-05-17 21:25:50,329 WARN  [com.azu.cor.amq.imp.ReactorExecutor] (reactor-executor-3) {"az.sdk.message":"scheduleCompletePendingTasks - exception occurred while  processing events.\njava.lang.IllegalStateException\norg.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:112)\norg.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324)\norg.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:292)\ncom.azure.core.amqp.implementation.ReactorExecutor.lambda$scheduleCompletePendingTasks$1(ReactorExecutor.java:158)\nreactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68)\nreactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28)\njava.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)\njava.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)\njava.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)\njava.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)\njava.base/java.lang.Thread.run(Thread.java:833)Cause: null\norg.apache.qpid.proton.engine.impl.EndpointImpl.decref(EndpointImpl.java:54)\norg.apache.qpid.proton.engine.impl.TransportImpl.unbind(TransportImpl.java:315)\norg.apache.qpid.proton.reactor.impl.IOHandler.onUnhandled(IOHandler.java:387)\norg.apache.qpid.proton.engine.BaseHandler.onTransportClosed(BaseHandler.java:84)\norg.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:200)\norg.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)\norg.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324)\norg.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:292)\ncom.azure.core.amqp.implementation.ReactorExecutor.lambda$scheduleCompletePendingTasks$1(ReactorExecutor.java:158)\nreactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68)\nreactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28)\njava.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)\njava.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)\njava.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)\njava.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)\njava.base/java.lang.Thread.run(Thread.java:833)","connectionId":"MF_0c2d51_1652795696565"}
2022-05-17 21:25:50,837 WARN  [com.azu.cor.amq.imp.ReactorDispatcher] (parallel-1) {"az.sdk.message":"ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.","exception":"ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.","connectionId":"MF_0c2d51_1652795696565"}
2022-05-17 21:25:50,837 WARN  [com.azu.cor.amq.imp.ReactorDispatcher] (boundedElastic-10) {"az.sdk.message":"ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.","exception":"ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.","connectionId":"MF_0c2d51_1652795696565"}
2022-05-17 21:25:50,837 WARN  [com.azu.cor.amq.imp.RequestResponseChannel] (parallel-1) {"az.sdk.message":"Unable to open send and receive link.","exception":"Unable to open send and receive link.","connectionId":"MF_0c2d51_1652795696565","linkName":"cbs"}
2022-05-17 21:25:50,838 WARN  [com.azu.cor.amq.imp.AmqpChannelProcessor] (parallel-1) {"az.sdk.message":"Retry attempts exhausted or exception was not retriable.","exception":"Unable to open send and receive link.","connectionId":"MF_0c2d51_1652795696565","entityPath":"$cbs","retry":2}
2022-05-17 21:25:50,838 ERROR [rea.cor.pub.Operators] (parallel-1) Operator called default onErrorDropped: reactor.core.Exceptions$ErrorCallbackNotImplemented: java.lang.RuntimeException: Unable to open send and receive link.
Caused by: java.lang.RuntimeException: Unable to open send and receive link.
	at com.azure.core.amqp.implementation.RequestResponseChannel.<init>(RequestResponseChannel.java:221)
	at com.azure.core.amqp.implementation.ReactorConnection.lambda$createRequestResponseChannel$16(ReactorConnection.java:406)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:113)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:127)
	at reactor.core.publisher.Operators$MonoSubscriber.request(Operators.java:1906)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.request(FluxMapFuseable.java:169)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.request(FluxMapFuseable.java:169)
	at reactor.core.publisher.FluxPeekFuseable$PeekFuseableSubscriber.request(FluxPeekFuseable.java:144)
	at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.request(Operators.java:2158)
	at com.azure.core.amqp.implementation.AmqpChannelProcessor.requestUpstream(AmqpChannelProcessor.java:320)
	at com.azure.core.amqp.implementation.AmqpChannelProcessor.lambda$onError$4(AmqpChannelProcessor.java:213)
	at reactor.core.publisher.LambdaMonoSubscriber.onNext(LambdaMonoSubscriber.java:171)
	at reactor.core.publisher.MonoDelay$MonoDelayRunnable.propagateDelay(MonoDelay.java:271)
	at reactor.core.publisher.MonoDelay$MonoDelayRunnable.run(MonoDelay.java:286)
	at reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68)
	at reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.util.concurrent.RejectedExecutionException: ReactorDispatcher instance is closed. Should not continue dispatching work to this reactor.
	at com.azure.core.amqp.implementation.ReactorDispatcher.throwIfSchedulerError(ReactorDispatcher.java:139)
	at com.azure.core.amqp.implementation.ReactorDispatcher.invoke(ReactorDispatcher.java:103)
	at com.azure.core.amqp.implementation.RequestResponseChannel.<init>(RequestResponseChannel.java:216)
	... 20 more

Hi @freedev thank you for your reply.
It seems like your scenario is quite differen from steinrr. So I'd like to ask some more question:

Do you have only one servicebus client in your application?
You said there are ~ 5 mins of idle, does this mean that your client didn't receive any message in this 5 mins?
Could you please enable DEBUG level logging and give some logs before the exception occurs to take a look what the last several operations?

1. Do you have only one servicebus client in your application?

yes

2. You said there are ~ 5 mins of idle, does this mean that your client didn't receive any message in this 5 mins?

yes

3. Could you please enable DEBUG level logging and give some logs before the exception occurs to take a look what the last several operations?

yes, but don't know how, let me see how can I do (any suggestion appreciated)

Hi @freedev ,
thank you for your answers.
here is how to configure your SDK logging level link:
https://docs.microsoft.com/en-us/azure/developer/java/sdk/logging-overview

Hi there,
I notice that there should be several scenario may occur this bug(freedev's scenario is different from steinrr at least). So could you please provide more informations including code snippet, debug level logs and configuration about your servicebus(queue, topic and subsciption).

Hi @freedev I've worked on your issue these days, the logs your provide are your application is recovered. You don't need to worry about these logs. If your receiver is hanging, you should contact with us.

Hi @ZejiaJiang, thanks for your analysis. I have worked on this issue too, during my tests I found that if the Azure Servicebus is removed and created again, the serviceBusReceiverAsyncClient is unable to reconnect automatically and remains stuck. In order to solve this issue I have to recreate the serviceBusReceiverAsyncClient (or restart the application).
But at the moment I don't know how to catch the problem, how to check if the client is in a wrong state.

Hi @freedev ,
I'm confused about Azure Servicebus removed and created? Do you mean you delete the service of service bus in portal and create it again? If you did so, I think the client won't recovery, because the connecntion string is completely different. It's not a good practice.
This is how to enable debug level log in your application: https://docs.microsoft.com/en-us/azure/developer/java/sdk/logging-overview . You can try it.

Hi @ZejiaJiang, thanks for coming back.
I'm not referring to the whole Azure Servicebus service, but specifically to an Azure Service Topic.
During the development process - and the especially in dev environment - happens that the Topics are created and destroyed automatically by an Azure pipeline (or directly by Azure Portal).
In any case, this can happen for several reasons, but always because we need to remove all the messages (active or deadletter) from the topic.

Ok, but what if there is a network connection error? Does the client try to
reconnect automatically?
On Tue, 7 Jun 2022 at 10:25, ZejiaJiang @.***> wrote:

Hi @freedev https://github.com/freedev,
If the topic is deleted, service will respond not found error, it's not a
retriable error, the client won't reconnect automatically. this is an
expected behavior. Maybe use other approach to remove all messages, such as
run a script.
—
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-sdk-for-java/issues/25718#issuecomment-1148357493,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADRK7UI3IWIBHV5BX5K2BDVN4BQFANCNFSM5I5A53EQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Vincenzo D'Amore

I’ll try to be more clear, what if during the normal execution there is a
network error? Does the client try to keep alive  the connection?
On Tue, 7 Jun 2022 at 20:13, freedev @.***> wrote:

Ok, but what if there is a network connection error? Does the client try to
reconnect automatically?
On Tue, 7 Jun 2022 at 10:25, ZejiaJiang @.***> wrote:

Hi @freedev https://github.com/freedev,
If the topic is deleted, service will respond not found error, it's not a
retriable error, the client won't reconnect automatically. this is an
expected behavior. Maybe use other approach to remove all messages, such
as
run a script.
—
Reply to this email directly, view it on GitHub
<
https://github.com/Azure/azure-sdk-for-java/issues/25718#issuecomment-1148357493
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AADRK7UI3IWIBHV5BX5K2BDVN4BQFANCNFSM5I5A53EQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Vincenzo D'Amore
—
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-sdk-for-java/issues/25718#issuecomment-1149009739,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADRK7XTS6D66QAOFOCSQCTVN6GM3ANCNFSM5I5A53EQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Vincenzo D'Amore

@freedev Yes, the client has retry stragety, you could set spectific retry option to control it.

@ZejiaJiang Does this retry strategy apply to every kind of error? I mean, if for whatever reason the client is unable to connect to a topic (or the topic is temporary removed) can this retry strategy keep alive the client when the failure is resolved?

@freedev if there is a network error, client will keep alive and retry until failure resolved.

@ZejiaJiang thanks for answering. How can I implement a strategy for retry when the topic is removed? Could you please provide an example for generic error handling with the service bus async client method receiveMessages() ?

@freedev Sorry, maybe I misled you. For the topic removed, we cannot retry automatically in client. The only thing we can set is AmqpRetryOptions to configure maxDelay, maxRetries and etc. The topic removed is not we expected behavior.

Hi @ZejiaJiang, thanks for your support. I think we can close the issue.


Serial communication much slower with python 3

With python 3, a simple measurement with devices using a Serial TL are by a factor of 4-5 slower than with python 2.

fixed in development


Cover not fully opening (DRBL)

I agree to the following

[X] I have read the documentation right now
[X] I have read the FAQs right now
[X] I am aware of the latest release notes
[X] I am aware that an integration that was installed via HACS also needs to be updated via HACS
[X] The Backend (CCU/Homegear/...) is working as expected, devices are taught in and are controllable by its own UI.
[X] I am running the latest version of the custom_component (and Home Assistant)

The problem
After updating to <IP_ADDRESS>, my covers are only opening up to 99% when opening them via HomeAssistant Dashboard.
They first fully open to 100%. After a few seconds, they are moving again and stop at 99%.
Before updating, everything worked fine.
What version of HomematicIP (local) has the issue?
<IP_ADDRESS>
What was the last working version of HomematicIP (local)?
No response
What type of installation are you running?
Home Assistant OS
What type of installation are you running for your homematic backend?
CCU3
Which version of your homematic backend are you running?
No response
What hardware are you running for your system?
No response
Which config details do you use

[ ] TLS
[ ] callback data (see)

Which interfaces do you use?

[X] Homematic IP
[ ] Homematic (Bidcos-RF)
[ ] Groups (Heating-Group)
[ ] BidCos-Wired (HM-Wired)

Diagnostics information (no logs here)
No response
Log file extract. Anything in the logs that might be useful for us? The log (Setting/System/Logs -> load full log) is the best source to support trouble shooting!
No response
Additional information
No response

We only send one command for covers, so why do you think it’s an issue of this integration.
Or are you using blinds?

Sorry. I am using blinds ;).

That is menitioned in the release notes of 1.60.0:

Set open tilt level to 50%

I saw the release notes of 1.60.0.
But this causes problems in my case. If I press "open" in Homeassistant, the blind opens (I think it receives the command 100% open). Afterwards, it receives the command for 50% slat position and goes to position 99% and 50% slat position, because I think that 100% open at 50% slat position is an invalid state (if the blind is fully open, it can not have a slat position).
Why was an open tilt level of 50% chosen?

It was requested by blind users in the past.

I think this is not an issue with this integration.
If you want to change the tilt default to a new value you should start a discussion in this repository.
I personally don‘t use blinds or covers.

Thank you!
I think the problem lies within the order of the commands as they are sent to the Homematic upon combined tilt/position command.
In cover.py starting from line 109, there is the service definition. First, the position command is sent. Afterwards, the tilt command is sent. This way, the position of 100% is overwritten by the HomeMatic system due to the wrong tilt value. However, if you press "open" in HomeAssistant, a position of 100% is sent, which is never reached because of the tilt value.

No, if you use the service cover combined position, then only on combined parameter is send.
Same with the  cover open/close command.


Can't get "person" information

Hi,
I'm using rollbar on my heroku app, which is also a Shopify app. I have a helper method called current_shop. It's defined in one of app's helpers. In every controller I have:
include MyCustomHelper # defines current_shop method
helper_method :current_shop

I can use my helper method current_shop anywhere in controller and in views.
This is my rollbar configuration:
# ...
  config.person_method = 'current_shop'
  # config.person_id_method = "my_id"
  config.person_username_method = 'shopify_domain'
# Shop model (returned by `current_shop` method) has :id and :email columns
# ...

However, whenever the error gets reported to rollbar, I don't see any shop-related information.
What am I missing?

@ArturMoczulski Could you take a look at this issue?

@vfonic what are you returning from current_shop. Rollbar doesn't blindly add whatever you return from person_method. In fact it runs person_id_method, person_email_method and person_email_method on whatever was returned from person_method.
Here is the implementation:
https://github.com/rollbar/rollbar-gem/blob/master/lib/rollbar/plugins/rails/controller_methods.rb#L8-L22

@ArturMoczulski current_shop returns an instance of Shop ActiveRecord model. It contains id and email attributes. For the username, I edited the Rollbar configuration, as pointed out above, to return shopify_domain.
I just checked in the Rollbar, and it seems to be reporting correctly now. :)
Thanks for following up!


builders for kube-runtime reflector

Trying to propagate kube-runtime to all external repo actix examples and noticing a few things that should be made better for a smoother experience:

users need to import watcher when using reflector (even if they expose the same events and they only use one)
users need to import Writer when using reflector (even though they cannot really use it sensibly)

Proposed solutions:

[ ] add builder Cache<T> around reflector - #698
[ ] Cache builder to allow retrieving a reader as in Controller - #698
[ ] add Watcher<T> builder - #703

Edit: crossing out a few from feedback.
Edit2: removing ancient comments here, as a long time has passed here.

users now need to import ListParams when using reflector/watcher even if they're using defaults

They can also call it as Default::default().

reflector exposes the Writer even if it's unsafe to have multiple writers

The reflector takes the Writer by-move, so you can't pass the same Writer to multiple reflectors.

Ahh. Ok. Thanks. Probably going to ignore those parts then.

Wrote some docs for the Controller, and that's probably the hardest one. Needed a few more dev-dependencies we already had in Cargo.lock.
https://docs.rs/kube-runtime/0.37.0/kube_runtime/controller/struct.Controller.html

Most of the issues here are now in separate issues. So the only question left here is whether or not to add builders to reflector, watcher. This forces one question:

if Watcher<K> is just a builder to call watcher
and Reflector<K> is just a builder to call reflector (hiding the watcher arg + import)
then Controller<K> should really just call out to controller (i.e. keep the original name of controller rather than applier)

Managed to get around this with an easier solution in #907 thanks to Teo's ideas on WatchStreamExt.


Let’s get Firebase into master

Ping @jlooper.
Let’s list everything that’s preventing us from getting the angular-firebase branch into master. Off the top of my head...

[ ] Avoid the need to make changes to platforms.

[ ] google-services.json in platforms/android/google-services.json
[ ] Changes to platforms/android/build.gradle

[ ] Consider adding flags to the Firebase plugin install so that we can add parts to the integration ad hoc. Something like --remoteconfig and --admob would add that part in. Otherwise we wouldn't expect these bits to be added
[ ] Need to document how to get Google Play Services running on an emulator.
[x] Implement offline sync

Hey all,
I’m closing this for now as we’ve decided to keep Firebase out of this sample for simplicity. For a more up-to-date guide on using Firebase in NativeScript see Jen Looper’s excellent guide at https://www.nativescript.org/blog/merry-and-bright-create-a-mobile-app-with-firebase-angular-2-and-nativescript.


Remove LaidBackScans, WickedScans and Astrames

Checklist:

[ ] Updated extVersionCode value in build.gradle for individual extensions
[ ] Updated overrideVersionCode or baseVersionCode as needed for all multisrc extensions
[ ] Referenced all related issues in the PR body (e.g. "Closes #xyz")
[ ] Added the isNsfw = true flag in build.gradle when appropriate
[ ] Have not changed source names
[ ] Have explicitly kept the id if a source's name or language were changed
[x] Have tested the modifications by compiling and running the extension through Android Studio
[ ] Have removed web_hi_res_512.png when adding a new extension

Actually wicked scans url is changed https://wickedscans.org/


Typo "query**time_out"→"query time_out"

https://docs.microsoft.com/en-us/sql/tools/sqlcmd-utility?view=sql-server-ver15

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

approved.
#sign-off

approved.
#sign-off


Added rff.tsu.ru

Add Tomsk State University Department of Radiophysics

Add Global Research Academy of Sciences.
On Thu 24 Sep, 2015 7:23 pm fsotomsk<EMAIL_ADDRESS>wrote:

Add Tomsk State University Department of Radiophysics
You can view, comment on, or merge this pull request online at:
https://github.com/leereilly/swot/pull/968
Commit Summary

Added rff.tsu.ru

File Changes

A lib/domains/ru/tsu/rff.txt
https://github.com/leereilly/swot/pull/968/files#diff-0 (1)

Patch Links:

https://github.com/leereilly/swot/pull/968.patch
https://github.com/leereilly/swot/pull/968.diff

—
Reply to this email directly or view it on GitHub
https://github.com/leereilly/swot/pull/968.


Python 3.5 and 3.6 support on Windows

Depends on #297. Test on appveyor and update installation manual

Implemented in 0.50


Convert docker compose to Kubernetes Resources k3s

I have Truenas scale, Docker was removed from the base OS. The apps system on scale is k3s, But k3s switched form docker to containerd as runtime, so docker was removed.
I'm not familiar with k3s, And tired to convert the compose file to k3s, but was unable to do so, tried to deploy it via portioner, and it failed.
Could you post k3s yaml to deploy via portioner?
Thanks

Could someone please help with this?

I started experimenting with installing it on my Harvester Kube cluster.
My manifests are here:
https://gitlab.acloud.app/system/harvester/-/tree/main/dsm
kubectl logs -f -n dsm dsm
❯ Starting Virtual DSM for Docker v7.12...
❯ For support visit https://github.com/vdsm/virtual-dsm
❯ CPU: Intel Xeon Gold 5218 CPU | RAM: 226/252 GB | DISK: 251 GB (ext4) | HOST: 5.14.21-150400.24.108-default...
❯ Install: Downloading installer...
❯ Install: Downloading DSM_VirtualDSM_69057.pat...
❯ Install: Extracting downloaded image...
❯ Install: Preparing system partition...
❯ Install: Extracting system partition...
❯ Install: Installing system partition...
❯ Creating a 256G growable disk image in qcow2 format...
Formatting '/storage/data.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=off compression_type=zlib size=274877906944 lazy_refcounts=off refcount_bits=16
❯ Booting Virtual DSM...

@mmishael I have successfully run vDSM on Truenas scale 24.04.0 for a period of time and enabled vDSM to obtain IP through DHCP. I have provided some key configuration screenshots, hoping they can be helpful to you.

I started experimenting with installing it on my Harvester Kube cluster.
My manifests are here: https://gitlab.acloud.app/system/harvester/-/tree/main/dsm
Download them, customize for you needs and apply.
Logs:
kubectl logs -f -n dsm dsm
❯ Starting Virtual DSM for Docker v7.12...
❯ For support visit https://github.com/vdsm/virtual-dsm
❯ CPU: Intel Xeon Gold 5218 CPU | RAM: 226/252 GB | DISK: 251 GB (ext4) | HOST: 5.14.21-150400.24.108-default...

❯ Install: Downloading installer...
❯ Install: Downloading DSM_VirtualDSM_69057.pat...
❯ Install: Extracting downloaded image...
❯ Install: Preparing system partition...
❯ Install: Extracting system partition...
❯ Install: Installing system partition...
❯ Creating a 256G growable disk image in qcow2 format...
Formatting '/storage/data.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=off compression_type=zlib size=274877906944 lazy_refcounts=off refcount_bits=16
❯ Booting Virtual DSM...

so far looking good.
I want to test it few days and will send PR...
I noticed, that disk space units doesn't match: Kubernetes uses Gi and everyone else usually uses GB. So, my 256Gi in Kubernetes PVC is only 251GB as seen by Synology and since I have 256GB in environment that doesn't match...

P.S. as I'm testing, I found that if I open UI via IP port - everything works. But if I use Ingress and open via domain name - I'm getting error:

You are not authorized to use this service.

Wow thanks!!! I will look at it.

@mmishael I have successfully run vDSM on Truenas scale 24.04.0 for a period of time and enabled vDSM to obtain IP through DHCP. I have provided some important configuration screenshots, hoping they can be helpful to you.

Thanks!
I did all the steps you noted, but I get redirected to DMS ip not available.
Do you know what could be the problem?

The config above is the basic one.
I was running more tests, and it looks to me, that most optimal network settings are not just to expose UI port, but for DSM to have dedicated IP in LAN. That configuration can be different depending on Kubernetes cluster.
I'm using Harvester 1.3.0 cluster and here is my pod config:
apiVersion: v1
kind: Pod
metadata:
  name: dsm
  labels:
    name: dsm
  namespace: dsm
  annotations:
    # https://github.com/k8snetworkplumbingwg/multus-cni/blob/master/docs/how-to-use.md#launch-pod-with-json-annotation
    k8s.v1.cni.cncf.io/networks: '[{"name":"net2","namespace":"default","interface":"net2"}]'
spec:
  terminationGracePeriodSeconds: 120 # the Kubernetes default is 30 seconds and it may be not enough
  containers:
    - name: dsm
      image: vdsm/virtual-dsm
      resources:
        limits:
          devices.kubevirt.io/kvm: 1
          devices.kubevirt.io/vhost-net: 1
      securityContext:
        privileged: true
        capabilities:
          add: ["NET_ADMIN"]
      env:
        - name: RAM_SIZE
          value: 4G
        - name: CPU_CORES
          value: "4"
        - name: DISK_SIZE
          value: "250G"
        - name: DISK_FMT
          value: "qcow2"
        - name: DHCP
          value: "Y"
        - name: VM_NET_DEV
          value: "net2"
      volumeMounts:
        - mountPath: /storage
          name: dsm256-ssd
  volumes:
    - name: dsm256-ssd
      persistentVolumeClaim:
        claimName: dsm256-ssd-pvc

With that config I have my Samba shares working on Windows computers in LAN.

Do you know what could be the problem?

@mmishael ,
On the screenshots above, it's appears strange to me that VM_NET_DEV has one interface name, but then on another screenshot another interface selected. That can be the problem.

Do you know what could be the problem?

@mmishael , On the screenshots above, it's appears strange to me that VM_NET_DEV has one interface name, but then on another screenshot another interface selected. That can be the problem.

Hi Thanks,
I think It should be eth0, its container internal interface it doesn't have the "eno1".
Something with DHCP doesn't work, the container doesn't get the DHCP address.

@mmishael hi,

You can try setting these two options for "Kubernetes Settings". You should choose the corresponding value based on your network card. enp4s0 is my PCIe 10 Gigabit network card, and the network card that comes with your device is generally called "eno1". Please also fill in your own gateway address for the "Route v4 Gateway" option below
The description I provided in the previous screenshot was not clear enough. The value of "VM_NET_DEV" is the name of the network card in the container, not the name of the network card in Truenas. I speculate that your environment should be filled in with "eth0", and "Host Interface" should be selected with "eno1 'Interface".
You can use @wy19xx to contact me. Without @, I shouldn't receive GitHub's email notification.

@kroese
In my case the VM_NET_DEV was not detected correctly. So, I had to set it manually:
         - name: VM_NET_DEV
           value: "net2"

I think that's because the VM had few interfaces, which were enabled to access WAN, but only one was reachable from outside.
Should the vdsm be configured to listen on all interfaces by default?

@wy19xx The container automaticly detects the network interface name inside the container:
VM_NET_DEV=$(awk '$2 == 00000000 { print $1 }' /proc/net/route)

If this method does not work correctly in your case, it would be better to improve this auto-detection code, than overriding the name manually using an environmeny variable.

Yes, I used to guess it was automatically detected, so there shouldn't be a need to fill in when there was only one network card, but I have two network cards. Previously, when I didn't fill in this item and started the container, an error message would be displayed. I have sent out all my configurations without any changes in order to improve the success rate of the configuration.

If the name is always net2 on every installation of Kubernetes...

No, net2 is not typical.
It's actually came from my annotation:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[{"name":"net2","namespace":"default","interface":"net2"}]'

I'm not the network or Kubernetes expert, but here is my understanding of how it works in Kubernetes:

The default scenario:

the pod or VM in Kubernetes will have only one interface (even if the server has multiple NIC).
vdsm will correctly attach to that interface
the interface will have ClusterIP (that's internal Kubernetes network, not accessible by any non-Kubernetes device)
to access vdsm user need to add Service: NodePort, LoadBalancer, ...
the Service need to have entry for every port: webUI on 5000, 5001, NFS, Samba, SSH, ... A lot of entries. Also need to properly set TCP / UDP type. That's a hassle and error-prone... Network discovery probably will not work.

Put vdsm into LAN

that requires bridge configuration for the pod / VM. That's what my annotation above is used for. That annotation only works, if multus installed in Kubernetes cluster.
with bridge configuration - pod / VM will have 2 interfaces: one will internal KubernetesIP, another - regular IP in the LAN. Both interfaces will have access to Internet: one - NAT'd via Kubernetes cluster, another - via LAN.
if vdsm will listen on that LAN interface - the network discovery will work in LAN. Also, ports can be forwarded on the router, and no Services are needed on Kubernetes cluster.

If configured with 2 interfaces, here is what I see:
# kubectl exec -it -n dsm dsm -- cat /proc/net/route
Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  Mask            MTU     Window  IRTT
eth0    00000000        0101FEA9        0003    0       0       0       00000000        0       0       0
eth0    0101FEA9        00000000        0005    0       0       0       FFFFFFFF        0       0       0

# kubectl exec -it -n dsm dsm -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: eth0@if108: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether 02:2d:64:71:e8:1d brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::2d:64ff:fe71:e81d/64 scope link
       valid_lft forever preferred_lft forever
4: net2@if109: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether f6:7e:e4:e7:04:65 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::f47e:e4ff:fee7:465/64 scope link
       valid_lft forever preferred_lft forever
5: dsm@net2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 500
    link/ether 02:11:32:70:4e:69 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::11:32ff:fe70:4e69/64 scope link
       valid_lft forever preferred_lft forever

@kroese Here is my output：
admin@truenas[~]$ cat /proc/net/route
Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  Mask            MTU     Window  IRTT
enp4s0  00000000        0201A8C0        0003    0       0       0       00000000        0       0       0
kube-bridge     000010AC        00000000        0001    0       0       0       0000FFFF        0       0       0
enp4s0  0001A8C0        00000000        0001    0       0       0       00FFFFFF        0       0       0

@kroese This is my output:
# cat /proc/net/route
Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  Mask            MTU     Window  IRTT
eth0    00000000        010010AC        0003    0       0       0       00000000        0       0       0
eth0    000010AC        00000000        0001    0       0       0       0000FFFF        0       0       0
net1    0001A8C0        00000000        0001    0       0       0       00FFFFFF        0       0       0

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo
       valid_lft forever preferred_lft forever
3: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether fa:4f:52:dc:85:c3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f84f:52ff:fedc:85c3/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
4: net1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether b2:ca:5f:0d:ac:60 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global net1
       valid_lft forever preferred_lft forever
    inet6 fe80::b0ca:5fff:fe0d:ac60/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
5: dsm@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 500
    link/ether 02:11:32:28:79:05 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::11:32ff:fe28:7905/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

@mmishael hi,

You can try setting these two options for "Kubernetes Settings". You should choose the corresponding value based on your network card. enp4s0 is my PCIe 10 Gigabit network card, and the network card that comes with your device is generally called "eno1". Please also fill in your own gateway address for the "Route v4 Gateway" option below
The description I provided in the previous screenshot was not clear enough. The value of "VM_NET_DEV" is the name of the network card in the container, not the name of the network card in Truenas. I speculate that your environment should be filled in with "eth0", and "Host Interface" should be selected with "eno1 'Interface".
You can use @wy19xx to contact me. Without @, I shouldn't receive GitHub's email notification.

Hi  @wy19xx,
I appreciate your efforts.
I have tried to do the steps you mentioned and it didn't work for me, it was still redirected to the
"The location of DSM is http://<IP_ADDRESS>:5000/" no my network 10.10.x.x.
As you mentioned, I can see my interfaces in the truenas dashboard, and it's "eno1", I gave my IPV4 gateway and still no change.
Please see uploaded log, not sure it can help ....
vdsm_vdsm-ix-chart-5cfc46f676-dwp4w_ix-chart.log

@mmishael hi,嗨

You can try setting these two options for "Kubernetes Settings". You should choose the corresponding value based on your network card. enp4s0 is my PCIe 10 Gigabit network card, and the network card that comes with your device is generally called "eno1". Please also fill in your own gateway address for the "Route v4 Gateway" option below你可以尝试在 "Kubernetes 设置 "中设置这两个选项。enp4s0 是我的 PCIe 万兆网卡，而设备自带的网卡一般称为 "eno1"。还请在下面的 "Route v4 Gateway（路由 v4 网关）"选项中填写您自己的网关地址
The description I provided in the previous screenshot was not clear enough. The value of "VM_NET_DEV" is the name of the network card in the container, not the name of the network card in Truenas. I speculate that your environment should be filled in with "eth0", and "Host Interface" should be selected with "eno1 'Interface".我在上一张截图中的描述不够清楚。VM_NET_DEV "的值是容器中网卡的名称，而不是 Truenas 中网卡的名称。我推测你的环境应该填写 "eth0"，"Host Interface（主机接口）"应该选择 "eno1 'Interface'"。
You can use @wy19xx to contact me. Without @, I shouldn't receive GitHub's email notification.您可以用它来联系我。如果没有 @，我应该不会收到 GitHub 的电子邮件通知。

Hi @wy19xx,嗨 、
I appreciate your efforts.感谢您的努力。 I have tried to do the steps you mentioned and it didn't work for me, it was still redirected to the我试着按您提到的步骤操作，但没有成功，还是被重定向到了 "The location of DSM is http://<IP_ADDRESS>:5000/" no my network 10.10.x.x."DSM 的位置是 http://<IP_ADDRESS>:5000/"，没有我的网络 10.10.x.x。
As you mentioned, I can see my interfaces in the truenas dashboard, and it's "eno1", I gave my IPV4 gateway and still no change.正如您提到的，我可以在 truenas 面板上看到我的接口，是 "eno1"，我提供了 IPV4 网关，但还是没有变化。
Please see uploaded log, not sure it can help ....请参阅上传的日志，不确定是否有帮助 ....
vdsm_vdsm-ix-chart-5cfc46f676-dwp4w_ix-chart.log

@mmishael Hi,
I'm sorry to say that the above configuration is all I have, I know nothing about the technical details of obtaining IPs, and these configurations are the result of my attempts to work through the permutations and combinations of the various options. @SlavikCA has committed the Kubernetes configuration file to the master branch, and @kroese has refined the auto-detection of the VM_NET_DEV configuration, so perhaps you could try re-pulling the latest image and rebuilding the container again?

@mmishael hi,

You can try setting these two options for "Kubernetes Settings". You should choose the corresponding value based on your network card. enp4s0 is my PCIe 10 Gigabit network card, and the network card that comes with your device is generally called "eno1". Please also fill in your own gateway address for the "Route v4 Gateway" option below
The description I provided in the previous screenshot was not clear enough. The value of "VM_NET_DEV" is the name of the network card in the container, not the name of the network card in Truenas. I speculate that your environment should be filled in with "eth0", and "Host Interface" should be selected with "eno1 'Interface".
You can use @wy19xx to contact me. Without @, I shouldn't receive GitHub's email notification.

Hi @wy19xx,
I appreciate your efforts. I have tried to do the steps you mentioned and it didn't work for me, it was still redirected to the "The location of DSM is http://<IP_ADDRESS>:5000/" no my network 10.10.x.x.
As you mentioned, I can see my interfaces in the truenas dashboard, and it's "eno1", I gave my IPV4 gateway and still no change.
Please see uploaded log, not sure it can help ....
vdsm_vdsm-ix-chart-5cfc46f676-dwp4w_ix-chart.log

@mmishael Hi,
I'm sorry to say that the above configuration is all I have, I know nothing about the technical details of obtaining IPs, and these configurations are the result of my attempts to work through the permutations and combinations of the various options. @SlavikCA has committed the Kubernetes configuration file to the master branch, and @kroese has refined the auto-detection of the VM_NET_DEV configuration, so perhaps you could try re-pulling the latest image and rebuilding the container again?


Creating the "visualization" api for FLAML

Why are these changes needed?
This pull request includes all of the recent pushes from the main microsoft/FLAML. Not only this, but it creates a new API for FLAML called "visualization". So far, the finalized feature of this pull has feature importance for the data after training. Group 1 in DS 440 is working on creating better explainability through visualizations for FLAML. Further updates with more visualizations will be pull requested later.
Related issue number
Checks

[] I've used pre-commit to lint the changes in this PR, or I've made sure lint with flake8 output is two 0s.
[] I've included any doc changes needed for https://microsoft.github.io/FLAML/. See https://microsoft.github.io/FLAML/docs/Contribute#documentation to build and test documentation locally.
[] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[] I've made sure all auto checks have passed.

Could you make sure the items on the checklist are satisfied?


Support standalone mode detector for store data manager

StoreDataManager provider to supply the mode switcher

Tweak infinispan store data manager into standalone mode

@ruhan1 @sswguo @ligangty Thanks for your review comments, I also agree with them. Let me close this as I'll push another improved pr in the branch:noncontent-store instead.


[Work In Progress - Do Not Merge] Connectedk8s: Add "arc "mode in Guard for using OBO service

Arc RBAC changes for Connectedk8s extension

Add "arc "mode in Guard for using 1P apps for authN/authZ
Add warning to use latest kubelogin with PoP token support
Bump the release version

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

Work In Progress - Do Not Merge

@yonzhan @yanzhudd @zhoxing-ms for reviews

Hi @vineeth-thumma, please rerun tests in live mode and upload the recoding files if the recording files exist.

Adding @atchutbarli for review

@yonzhan @yanzhudd @zhoxing-ms Can one of you please add @atchutbarli as a reviewer? (I'm unable to add). We need an approval from him as their team owns the extensiion.


fix: permission issues

Pull request description
Related to https://github.com/kubeshop/testkube/issues/2436
The maven executor creates files in the data folder upon compilation. The init container is running as root, therefore other users do not have permission to modify the folder the test content is placed into.
Checklist (choose whats happened)

[ ] breaking change! (describe)
[x] tested locally
[ ] tested on cluster
[ ] added new dependencies
[ ] updated the docs
[ ] added a test

Breaking changes

Changes

updated permissions on test content folder

Fixes

@vsukhin it is not empty, the permissions changed when I ran the test with RUNNER_DATADIR unset, the changes I just pushed should fix that


docs(avm): Comments in pil file related to range checks of addresses

Benchmark results
Metrics with a significant change:

protocol_circuit_witness_generation_time_in_ms (base-parity): 1,781 (+98%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_ms
5,781 (-1%)
1,569
700 (-1%)
768 (+2%)
784

proof_construction_time_sha256_30_ms
12,050 (-1%)
3,191
1,409 (-1%)
1,435 (-1%)
1,470 (-1%)

proof_construction_time_sha256_100_ms
45,716
12,279 (-1%)
5,665 (-2%)
5,565 (-1%)
5,500 (-1%)

proof_construction_time_poseidon_hash_ms
79.0
34.0 (-3%)
34.0
58.0
88.0 (+1%)

proof_construction_time_poseidon_hash_30_ms
1,538
423
203
227
276 (+3%)

proof_construction_time_poseidon_hash_100_ms
5,807
1,585
724 (-1%)
796 (-3%)
791 (-2%)

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
64 txs

l1_rollup_calldata_size_in_bytes
1,412
1,412
1,412

l1_rollup_calldata_gas
9,464
9,476
9,476

l1_rollup_execution_gas
608,000
608,012
608,012

l2_block_processing_time_in_ms
1,292 (-1%)
4,828
9,587

l2_block_building_time_in_ms
44,058 (-1%)
174,577
348,783

l2_block_rollup_simulation_time_in_ms
43,862 (-1%)
173,845
347,337

l2_block_public_tx_process_time_in_ms
40,647 (-1%)
170,577
343,954

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
9,399 (-3%)
14,381 (-2%)

node_database_size_in_bytes
14,499,920
21,352,528

pxe_database_size_in_bytes
18,071
29,868

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
512 leaves
1024 leaves
2048 leaves
4096 leaves
32 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.4 (-1%)
17.3
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.7
31.8
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.606 (-1%)
0.522
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
48.6 (-1%)
76.1
247
474 (-1%)
930
1,846
N/A

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
543
1,055
2,079
4,127
N/A

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.496 (-1%)
0.469
0.449
0.442 (-1%)
0.441
0.440
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
58.3 (-1%)
112 (-1%)
355 (-1%)
697 (-1%)
1,390
2,770
N/A

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
106
208
692
1,363
2,707
5,395
N/A

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.504 (-1%)
0.504
0.482
0.479 (-1%)
0.480
0.481
N/A

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
62.6 (-1%)

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
107

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0.553 (-1%)

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
84,053
665,267

Transaction size based on fee payment method
| Metric |  |
| - |  |


Every cropped image is saving with a unique name in app files/Pictures

When I crop an image using Android 12 or 12+, the cutter creates a file named "cropped3655457542457542.png", for example, in the application's file folder: Android/data/app-name-space/files/Pictures. This behavior causes each successive crop to have an incorrect file path in the result.
Steps:
1 -  Starts the launcher:
cropImage.launch(
    options {
        setGuidelines(CropImageView.Guidelines.ON)
        setAspectRatio(2, 3)
        setRequestedSize(592, 840, CropImageView.RequestSizeOptions.RESIZE_FIT)
        setActivityTitle(getString(R.string.activity_label_image_crop))
        setOutputCompressFormat(Bitmap.CompressFormat.PNG)
        setOutputCompressQuality(100)
    }
)

2 - On result if I need the uriFilePath the system keeps getting the last cropped image file, not the actual cropped. The actual cropped only works with the uriContent but the system keeps saving a new file with a cropped+randomNumber in name.
How to prevent the system to creates a new file every crop action?

There's a boolean option somewhere. Also, i'd advise you to set the target / output uri and that way you are in control where the file is stored.


feat(operator): introduces operator-sdk bundle creation

Short description of what this resolves:
Introduce the Operator SDK to manage the creation of Operator Bundle and metadata.
Changes proposed in this pull request:

Add Operator SDK
Update to CRD v1
Remove install command
Rely on OLM to install Operator under test

Relates to #80
Fixes #613

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
390aad98533f8555061cea438e47c82558cce4a8
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test openshift

/test openshift

/test openshift

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
1542afe7e6002a2b78c8cccb32c3d6852b341eef
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
1542afe7e6002a2b78c8cccb32c3d6852b341eef
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
1542afe7e6002a2b78c8cccb32c3d6852b341eef
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
23b3a9852be7c215baf7f89aa8d2cf4ac92ba61e
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test openshift


Support multi-istiocontrolplane testing

the new installer is designed for modularity and isolation. it allows installing multiple istiocontrolplane in the same cluster in different namespaces.
the tasks includes:

allow customized labels for istio-ingress.
test multi-istiocontrolplane in different namespaces. the released version is installed istio-control/istio-ingress/istio-policy/istio-telemetry in while the master version is installed in istio-control-master/istio-ingress-master/istio-policy-master/istio-telemetry-master. share one citadel installed in istio-system
allow customized namespace and labels for bookinfo application to test

Given our plans to consolidate everything to one deployment, investing effort into this for the microservices model may be wasted effort

@howardjohn Could you point me the design doc or discussion threads? Thanks.

https://www.google.com/url?sa=t&rct=j&esrc=s&source=appssearch&uact=8&cd=1&cad=rja&q&sig2=ptxv889PludfKCnEmvrKzg&ved=0ahUKEwjs_Kr48uPmAhXPsWQKHQ0_BeQ4ABABKAEwAQ&url=https://drive.google.com/a/google.com/open?id%3D1v8BxI07u-mby5f5rCruwF7odSXgb9G8-C9W5hQtSIAg%26usp%3Dchrome_omnibox&usg=AOvVaw0wurP8j3z2PFvtjIJeKFBB

Thanks @howardjohn Do you know why it always throws 404 error?

I think the link was wrong, i editted my comments. if that doesn't work search istiod in the drive

It works. Thanks


Template Not Loading on Safari Browser

Describe the bug
After publishing this template to Azure Static Web Apps, it loads fine on my desktop which is running the latest version of chrome. However, when I try running this on my iphone with safari the loading bar stops at 100% and says "An unhandled error has occurred."
To Reproduce
Steps to reproduce the behavior:

Go to https://thankful-glacier-004d8be0f.5.azurestaticapps.net/ on an iphone using the safari browser.

Device info (if applicable):

OS: iOS 16.0
Browser: Safari
Version: NA

Additional context
This isn't only happening with Safari on my iphone; it is also happening with google chrome on my phone. There is one other user experiencing this issue when accessing the site with safari on iphone. The URL provided is hosting the template provided with no changes.

Update:
After updating my iphone to the latest os version there was not any change.

The template being used is from here: https://github.com/staticwebdev/blazor-starter. Sorry for the confusion.

After updating my iphone to the latest version the site loads fine. Unfortunately when this is going to be running in production, people use phones that are not up to date. With that being said I would still like to get to the bottom of this. Unfortunately I don't have a mac so I can't debug ios devices. If anyone has any insight as to why the template I'm using ( https://github.com/staticwebdev/blazor-starter) would be causing incompatibility issues, that would be greatly appreciated. My only thought is that older versions of ios may be using incompatible version of http.


Could you share folder thathas NC program at github? I can't get it from onedrive.

Sure, let me get to it, but please don't spam the other issues with the same request...

I pushed the folder to git and changed the default path, so now the GUI should open with the correct folder selected.