Apicurio-studio: Проблема с сохранением изменений API во время совместной работы

Это не хорошо. Какую версию Apicurio вы используете? Это происходит в облачной версии или вы используете ее локально? Недавно я обнаружил и исправил такую ​​же проблему (но только при использовании функции SHARE_FOR_EVERYONE ), но если вы используете последнюю версию или не используете эту функцию, это может быть новой ошибкой.

У нас есть последняя версия 0.243.final, работающая в кубернетах, и активирован SHARE_FOR_EVERYONE.

Спасибо, что так быстро связались с нами, @EricWittmann.
Любопытно, что изменения отображаются в журнале активности, даже если они не сохраняются после перезагрузки.
Надеюсь, @ t-rap скоро сможет взглянуть на базу данных.

Привет,

Извините за поздний ответ:

Мы запускаем apicurio-studio на кубернетах с образами докеров, которые вы предоставляете через концентратор докеров.
Так
Apicurio-studio-ui, -ws, -api, -db (изображение: percona: 5.7)

Когда наши разработчики используют его, сообщение об отладке apicurio-studio-api выглядит следующим образом:

2019-11-20 15:12:05,053 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-66) Selecting the most recent api_content row of type 'document' for: 12 2019-11-20 15:12:05,056 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-66) Inserting an Editing Session UUID row: REDACTED 2019-11-20 15:12:05,070 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-66) Created Session ID: REDACTED 2019-11-20 15:12:05,070 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-66) Secret: REDACTED 2019-11-20 15:12:14,973 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-66) Retrieving contributors list for design with ID: 12 2019-11-20 15:12:14,973 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-66) Selecting all contributors for API Design: 12 2019-11-20 15:12:14,973 DEBUG [io.apicurio.studio.shared.config.Configuration] (default task-65) Config Property: APICURIO_SHARE_FOR_EVERYONE/apicurio.share.for.everyone = true 2019-11-20 15:12:14,973 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-65) Selecting activity for API Design: 12 from 0 to 10 2019-11-20 15:12:14,983 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-64) Selecting mock activity for API Design: 12 from 0 to 20 2019-11-20 15:12:14,997 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) Getting an API design with ID 12 2019-11-20 15:12:14,997 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-67) Selecting a single API Design: 12 2019-11-20 15:12:17,810 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) Getting an API design with ID 12 2019-11-20 15:12:17,810 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-67) Selecting a single API Design: 12 2019-11-20 15:12:17,860 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) Editing an API Design with ID 12 2019-11-20 15:12:17,860 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) USER: REDACTED 2019-11-20 15:12:17,860 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-67) Selecting the most recent api_content row of type 'document' for: 12 2019-11-20 15:12:17,862 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-67) Inserting an Editing Session UUID row: REDACTED 2019-11-20 15:12:17,875 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) Created Session ID: REDACTED 2019-11-20 15:12:17,875 DEBUG [io.apicurio.hub.api.rest.impl.DesignsResource] (default task-67) Secret: REDACTED

Для apicurio-studio-ws дает:

2019-11-20 15:14:31,640 DEBUG [io.apicurio.hub.core.editing.ops.processors.CommandProcessor] (default task-3) user: REDACTED 2019-11-20 15:14:31,640 DEBUG [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-3) Inserting a 'command' content row for: 12 2019-11-20 15:14:31,659 DEBUG [io.apicurio.hub.core.editing.ops.processors.CommandProcessor] (default task-3) ACK sent back to client. 2019-11-20 15:14:31,659 DEBUG [io.apicurio.hub.core.editing.ops.processors.CommandProcessor] (default task-3) Command propagated to 'other' clients. 2019-11-20 15:14:33,145 DEBUG [io.apicurio.hub.core.editing.ops.processors.OperationProcessorDispatcher] (default task-3) Received a "ping" message/operation from a client for API Design: 12 2019-11-20 15:14:44,989 DEBUG [io.apicurio.hub.core.editing.ops.processors.OperationProcessorDispatcher] (default task-3) Received a "ping" message/operation from a client for API Design: 15 2019-11-20 15:14:46,691 DEBUG [io.apicurio.hub.editing.EditApiDesignEndpoint] (default task-3) Closing a WebSocket due to: 2019-11-20 15:14:46,692 DEBUG [io.apicurio.hub.editing.EditApiDesignEndpoint] (default task-3) designId: 12

Так что это определенно была ошибка, которую я исправил недавно - возможно, я исправил ее после самого последнего выпуска. Позвольте мне проверить это и вернуться к вам здесь.

Хорошо, я подтвердил, что исправление этой проблемы было сделано после выхода самой последней версии. Итак, у вас есть два варианта исправить это:

1) Дождитесь следующего релиза
2) Создайте последнюю версию от мастера и запустите ее

Вариант (2), вероятно, более доступен, чем вы думаете, но все же явно не идеален для вас. Я мог бы сделать еще один релиз в конце недели. Было добавлено несколько экспериментальных функций, которые мне нужно отключить (или, по крайней мере, отметить как таковые в пользовательском интерфейсе), прежде чем я смогу запустить релиз.

Я сейчас запускаю новую версию - в нее будет включено исправление этой проблемы. Помечено как закрытое, чтобы включить его в примечания к выпуску. :)

привет Эрик,

Проблема, похоже, все еще существует, но теперь возникает исключение. Я не уверен, наша вина в этом или нет. Есть ли у вас какие-нибудь подсказки, где я могу глубже разобраться в этом?

`` 2019-11-22 10: 16: 14,057 ОШИБКА [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (задача по умолчанию-1) Ошибка при получении последнего документа с содержимым: java.lang.IllegalStateException: ожидается один элемент , но не нашел
в org.jdbi.v3.core.result.ResultIterable.one (ResultIterable.java:135)
в io.apicurio.hub.core.storage.jdbc.JdbcStorage.lambda $ getLatestContentDocument $ 23 (JdbcStorage.java:655)
в org.jdbi.v3.core.Jdbi.withHandle (Jdbi.java:341)
в io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument (JdbcStorage.java:648)
в io.apicurio.hub.core.storage.jdbc.JdbcStorage $ Proxy $ _ $$ _ WeldClientProxy.getLatestContentDocument (неизвестный источник)
в io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:56)
в io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:108)
в io.apicurio.hub.core.storage.RollupExecutor $ Proxy $ _ $$ _ WeldClientProxy.rollupCommands (неизвестный источник)
в io.apicurio.hub.core.editing.EditingSession.close (EditingSession.java:131)
в io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession (EditingSessionManager.java:116)
в io.apicurio.hub.core.editing.EditingSessionManager $ Proxy $ _ $$ _ WeldClientProxy.closeEditingSession (неизвестный источник)
в io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession (EditApiDesignEndpoint.java:215)
в sun.reflect.NativeMethodAccessorImpl.invoke0 (собственный метод)
в sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
в sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
в java.lang.reflect.Method.invoke (Method.java:498)
в io.undertow.websockets.jsr.annotated.BoundMethod.invoke (BoundMethod.java:87)
в io.undertow.websockets.jsr.annotated.AnnotatedEndpoint $ 4.run (AnnotatedEndpoint.java:201)
в io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:169)
в io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:166)
в io.undertow.servlet.core.ContextClassLoaderSetupAction $ 1.call (ContextClassLoaderSetupAction.java:43)
в org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda $ create $ 0 (SecurityContextThreadSetupAction.java:105)
в org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
в org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
в org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
в org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
в io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod (ServerWebSocketContainer.java:603)
в io.undertow.websockets.jsr.ServerWebSocketContainer $ 6.run (ServerWebSocketContainer.java:589)
в io.undertow.websockets.jsr.OrderedExecutor $ ExecutorTask.run (OrderedExecutor.java:67)
в org.jboss.threads.ContextClassLoaderSavingRunnable.run (ContextClassLoaderSavingRunnable.java:35)
в org.jboss.threads.EnhancedQueueExecutor.safeRun (EnhancedQueueExecutor.java:1985)
в org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.doRunTask (EnhancedQueueExecutor.java:1487)
в org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.run (EnhancedQueueExecutor.java:1378)
в java.lang.Thread.run (Thread.java:748)

2019-11-22 10: 16: 14,057 ОШИБКА [io.apicurio.hub.core.editing.EditingSession] (задача по умолчанию-1) Обнаружена ошибка при закрытии сеанса редактирования .: io.apicurio.hub.core.exceptions.NotFoundException
в io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument (JdbcStorage.java:659)
в io.apicurio.hub.core.storage.jdbc.JdbcStorage $ Proxy $ _ $$ _ WeldClientProxy.getLatestContentDocument (неизвестный источник)
в io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:56)
в io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:108)
в io.apicurio.hub.core.storage.RollupExecutor $ Proxy $ _ $$ _ WeldClientProxy.rollupCommands (неизвестный источник)
в io.apicurio.hub.core.editing.EditingSession.close (EditingSession.java:131)
в io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession (EditingSessionManager.java:116)
в io.apicurio.hub.core.editing.EditingSessionManager $ Proxy $ _ $$ _ WeldClientProxy.closeEditingSession (неизвестный источник)
в io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession (EditApiDesignEndpoint.java:215)
в sun.reflect.NativeMethodAccessorImpl.invoke0 (собственный метод)
в sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
в sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
в java.lang.reflect.Method.invoke (Method.java:498)
в io.undertow.websockets.jsr.annotated.BoundMethod.invoke (BoundMethod.java:87)
в io.undertow.websockets.jsr.annotated.AnnotatedEndpoint $ 4.run (AnnotatedEndpoint.java:201)
в io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:169)
в io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:166)
в io.undertow.servlet.core.ContextClassLoaderSetupAction $ 1.call (ContextClassLoaderSetupAction.java:43)
в org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda $ create $ 0 (SecurityContextThreadSetupAction.java:105)
в org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
в org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
в org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
в org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
в io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod (ServerWebSocketContainer.java:603)
в io.undertow.websockets.jsr.ServerWebSocketContainer $ 6.run (ServerWebSocketContainer.java:589)
в io.undertow.websockets.jsr.OrderedExecutor $ ExecutorTask.run (OrderedExecutor.java:67)
в org.jboss.threads.ContextClassLoaderSavingRunnable.run (ContextClassLoaderSavingRunnable.java:35)
в org.jboss.threads.EnhancedQueueExecutor.safeRun (EnhancedQueueExecutor.java:1985)
в org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.doRunTask (EnhancedQueueExecutor.java:1487)
в org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.run (EnhancedQueueExecutor.java:1378)
в java.lang.Thread.run (Thread.java:748) ``

Я почти уверен, что это именно та ошибка, которую я ожидал бы, если бы исправления ошибки не было. Позвольте мне откопать несколько ссылок на код ...

хорошо, я только что проверил, чтобы не тратить зря ваше время, но, похоже, это последняя версия:

Версия | 0.2.44.Финал
- | -
Построен на | 21 нояб.2019 г.
Издание | CLIv7
URL проекта | http://www.apicur.io/

Мы протестировали старые API-интерфейсы, которые уже существовали, создали и протестировали новые API-интерфейсы, а также попробовали это с разными учетными записями.

Хорошо спасибо. Итак, что происходит с этой трассировкой стека, так это то, что всякий раз, когда все редакторы API заканчивают редактирование (выходят / закрывают редактор), сервер пытается объединить все изменения в моментальный снимок документа. Это делается здесь:

https://github.com/Apicurio/apicurio-studio/blob/master/back-end/hub-core/src/main/java/io/apicurio/hub/core/storage/RollupExecutor.java

Он пытается сделать это:

1) Получите ПОСЛЕДНИЙ снимок документа
2) Получить список всех изменений (команд) с тех пор
3) Применить все изменения / команды к последнему снимку документа
4) Сохраните НОВЫЙ снимок обратно в БД.

На шаге 1 он не работает, потому что не может найти предыдущий снимок. Это должно быть невозможно, потому что моментальный снимок создается при первом создании дизайна API. Однако это происходит, вероятно, из-за того, что опция «общий доступ для всех» включена для компонента -api Apicurio, но не для компонента -ws Apicurio. Таким образом, исходный снимок существует в таблице, но был создан пользователем A, поэтому, когда пользователь B пытается выполнить накопление (и общий доступ для всех отключен), при поиске снимка выполняется неправильный SQL-запрос, и он не найден. Поэтому вполне вероятно, что этот код не работает должным образом из-за неправильной конфигурации функции общего доступа только в компоненте -ws apicurio:

https://github.com/Apicurio/apicurio-studio/blob/master/back-end/hub-core/src/main/java/io/apicurio/hub/core/storage/jdbc/JdbcStorage.java#L650 - L655

Если в -api включен общий доступ для всех, но не -ws, то это произойдет.

Мне нужно было бы увидеть вашу настройку kubernetes (примечание: есть ли вероятность, что вы захотите внести это?), Но я предполагаю, что если вы основываете его на конфигурации docker compose, вам не хватает общего доступа для всех config в компоненте -ws. Вот одно из основных исправлений этой проблемы:

https://github.com/Apicurio/apicurio-studio/commit/7f4994bc907e1720ffd6f8ff81e844c032edbf79#diff -b1ff2c3381198f745ae9dc8add793d61

Привет, Эрик,

спасибо за подсказку. Мы «исправили» нашу проблему, установив общий доступ для всех также для модулей -ws. Я не рассматривал это как вариант на https://hub.docker.com/r/apicurio/apicurio-studio-ws. Вот почему я не положил его туда.

Если хотите, я бы почистил k8s-config и отправил вам запрос на перенос с ним. Думаю, я успею сделать это до начала следующей недели.

Большой! Я обновлю документы для этого изображения, чтобы включить эту опцию. Не спешите с конфигами k8s, но вклад был бы очень кстати.