In GitLab by @barry.nouwt.tno.nl on Dec 1, 2023, 13:02
There are two parts to this issue:
- one in the REST API, since it does not take the asynchronousness of the stop method of a SC into account.
- one in the Smart Connector API, since it does not actually wait until the smart connector is fully removed.
Currently, the REST API does not wait until the Smart Connector is fully stopped (and the smartConnectorStopped(...) method is called). This can cause the KB to be recreated, before it was fully removed and give the following error:
2023-12-01 08:18:52:471 +0000 [qtp1318822808-15] WARN ServletHandler -
javax.servlet.ServletException: java.lang.IllegalArgumentException: There already is a smart connector registered with ID http://knowledge-engine:8280/rest/adapter/openmotics-stg-spine-adapter
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:410)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:346)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:366)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:319)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:205)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:497)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.IllegalArgumentException: There already is a smart connector registered with ID http://knowledge-engine:8280/rest/adapter/openmotics-stg-spine-adapter
at eu.knowledge.engine.smartconnector.runtime.LocalSmartConnectorRegistryImpl.register(LocalSmartConnectorRegistryImpl.java:34)
at eu.knowledge.engine.smartconnector.impl.SmartConnectorImpl.<init>(SmartConnectorImpl.java:91)
at eu.knowledge.engine.smartconnector.spi.SmartConnectorV2Provider.create(SmartConnectorV2Provider.java:12)
at eu.knowledge.engine.rest.api.impl.RestKnowledgeBase.<init>(RestKnowledgeBase.java:240)
at eu.knowledge.engine.rest.api.impl.RestKnowledgeBaseManager.createKB(RestKnowledgeBaseManager.java:86)
at eu.knowledge.engine.rest.api.impl.SmartConnectorLifeCycleApiServiceImpl.scPost(SmartConnectorLifeCycleApiServiceImpl.java:128)
at jdk.internal.reflect.GeneratedMethodAccessor51.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$VoidOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:159)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:475)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:397)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:81)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:255)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:234)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)
... 18 more
The SmartConnectorImpl#stop() method explicitly mentions that it is asynchronous, but the RestKnowledgeBase#stop() method does not seem to take that into account.
Secondly, the SmartConnectorImpl#stop() method says it will call the smartConnectorStopped() method once it is fully stopped, but this does not actually seem to happen. It just executes the runnable unconditionally, which might sometimes occur before the Smart Connector is actually stopped.
In GitLab by @barry.nouwt.tno.nl on Dec 1, 2023, 13:02
There are two parts to this issue:
Currently, the REST API does not wait until the Smart Connector is fully stopped (and the
smartConnectorStopped(...)method is called). This can cause the KB to be recreated, before it was fully removed and give the following error:The SmartConnectorImpl#stop() method explicitly mentions that it is asynchronous, but the RestKnowledgeBase#stop() method does not seem to take that into account.
Secondly, the SmartConnectorImpl#stop() method says it will call the
smartConnectorStopped()method once it is fully stopped, but this does not actually seem to happen. It just executes the runnable unconditionally, which might sometimes occur before the Smart Connector is actually stopped.