Apicurio-studio: Salvar problemas de alterações de API durante a colaboração

Criado em 20 nov. 2019  ·  13Comentários  ·  Fonte: Apicurio/apicurio-studio

O uso simultâneo do apicurio studio por dois desenvolvedores causa problemas de salvamento para o desenvolvedor que não é o criador do Api.
O 'não-proprietário' da api não recebe nenhuma mensagem de que suas alterações de dados não foram armazenadas no banco de dados. Quando o cache é atualizado, todas as alterações são perdidas e uma versão antiga de seu trabalho aparece.
O proprietário da API não tem esses problemas. Suas alterações serão armazenadas.
Como não proprietário de uma API, posso fazer uma cópia da API e continuar trabalhando com o normal. Mas então o colega tem problemas de memória

@armadilha
@bodograumann

bug

Comentários muito úteis

Ei Eric,

obrigado pela dica. Nós "consertamos" nosso problema configurando o compartilhamento para todos também em pods -ws. Eu não vi isso como uma opção em https://hub.docker.com/r/apicurio/apicurio-studio-ws. É por isso que não o coloquei lá.

Se você quiser, eu limparia o k8s-configs e enviaria uma solicitação de pull com ele. Acho que posso fazer isso até o início da próxima semana.

Todos 13 comentários

Isso não é bom. Qual versão do Apicurio você está usando? Isso está acontecendo na versão em nuvem ou você está executando localmente? Recentemente, encontrei e resolvi um problema como este (mas apenas ao usar o recurso SHARE_FOR_EVERYONE ), mas se você estiver usando a versão mais recente ou não estiver usando esse recurso, então este pode ser um novo bug.

Temos a versão mais recente 0.243.final em execução no kubernetes e SHARE_FOR_EVERYONE está ativado.

Obrigado por nos responder tão rapidamente @EricWittmann.
Curiosamente, as mudanças são mostradas no log de atividades, embora não sejam persistentes após uma recarga.
Espero que @ t-rap possa dar uma olhada no banco de dados em breve.

Ei,

Desculpe pela resposta tardia:

Estamos executando o apicurio-studio no kubernetes com as imagens do docker fornecidas por meio do hub do docker.
Então
Apicurio-studio-ui, -ws, -api, -db (imagem: percona: 5.7)

Quando nossos desenvolvedores o usam, a mensagem de depuração em apicurio-studio-api é a seguinte:

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

Para apicurio-studio-ws dá:

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

Portanto, esse foi definitivamente o bug que consertei recentemente - é possível que o tenha corrigido após o lançamento mais recente. Deixe-me verificar isso e voltar para você aqui.

OK, eu confirmei que minha correção para este problema foi feita após o lançamento mais recente. Portanto, você tem duas opções para consertar isso:

1) Aguarde o próximo lançamento
2) Compilar o mais recente do mestre e executá-lo

A opção (2) é provavelmente mais acessível do que você imagina, mas ainda obviamente não é a ideal para você. Eu poderia fazer outro lançamento no final da semana provavelmente. Há alguns recursos experimentais que foram adicionados que preciso desativar (ou pelo menos marcar como tal na IU) antes de poder acionar uma versão.

Estou lançando um novo lançamento agora - incluirá a correção para esse problema. Marcando como fechado para que seja incluído nas notas de lançamento. :)

oi Eric,

O problema parece ainda estar lá, mas lança uma exceção agora. Não tenho certeza se é nossa culpa ou não. Você tem alguma dica de onde eu possa examiná-lo mais profundamente?

`` `2019-11-22 10: 16: 14,057 ERROR [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (default task-1) Erro ao obter o documento de conteúdo mais recente: java.lang.IllegalStateException: Esperado um elemento , mas não encontrou nenhum
em org.jdbi.v3.core.result.ResultIterable.one (ResultIterable.java:135)
em io.apicurio.hub.core.storage.jdbc.JdbcStorage.lambda $ getLatestContentDocument $ 23 (JdbcStorage.java:655)
em org.jdbi.v3.core.Jdbi.withHandle (Jdbi.java:341)
em io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument (JdbcStorage.java:648)
em io.apicurio.hub.core.storage.jdbc.JdbcStorage $ Proxy $ _ $$ _ WeldClientProxy.getLatestContentDocument (fonte desconhecida)
em io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:56)
em io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:108)
em io.apicurio.hub.core.storage.RollupExecutor $ Proxy $ _ $$ _ WeldClientProxy.rollupCommands (fonte desconhecida)
em io.apicurio.hub.core.editing.EditingSession.close (EditingSession.java:131)
em io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession (EditingSessionManager.java:116)
em io.apicurio.hub.core.editing.EditingSessionManager $ Proxy $ _ $$ _ WeldClientProxy.closeEditingSession (fonte desconhecida)
em io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession (EditApiDesignEndpoint.java:215)
em sun.reflect.NativeMethodAccessorImpl.invoke0 (método nativo)
em sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
em sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
em java.lang.reflect.Method.invoke (Method.java:498)
em io.undertow.websockets.jsr.annotated.BoundMethod.invoke (BoundMethod.java:87)
em io.undertow.websockets.jsr.annotated.AnnotatedEndpoint $ 4.run (AnnotatedEndpoint.java:201)
em io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:169)
em io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:166)
em io.undertow.servlet.core.ContextClassLoaderSetupAction $ 1.call (ContextClassLoaderSetupAction.java:43)
em org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda $ create $ 0 (SecurityContextThreadSetupAction.java:105)
em org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
em org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
em org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
em org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
em io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod (ServerWebSocketContainer.java:603)
em io.undertow.websockets.jsr.ServerWebSocketContainer $ 6.run (ServerWebSocketContainer.java:589)
em io.undertow.websockets.jsr.OrderedExecutor $ ExecutorTask.run (OrderedExecutor.java:67)
em org.jboss.threads.ContextClassLoaderSavingRunnable.run (ContextClassLoaderSavingRunnable.java:35)
em org.jboss.threads.EnhancedQueueExecutor.safeRun (EnhancedQueueExecutor.java:1985)
em org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.doRunTask (EnhancedQueueExecutor.java:1487)
em org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.run (EnhancedQueueExecutor.java:1378)
em java.lang.Thread.run (Thread.java:748)

2019-11-22 10: 16: 14.057 ERROR [io.apicurio.hub.core.editing.EditingSession] (tarefa-1 padrão) Erro detectado ao fechar uma sessão de edição: io.apicurio.hub.core.exceptions.NotFoundException
em io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument (JdbcStorage.java:659)
em io.apicurio.hub.core.storage.jdbc.JdbcStorage $ Proxy $ _ $$ _ WeldClientProxy.getLatestContentDocument (fonte desconhecida)
em io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:56)
em io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:108)
em io.apicurio.hub.core.storage.RollupExecutor $ Proxy $ _ $$ _ WeldClientProxy.rollupCommands (fonte desconhecida)
em io.apicurio.hub.core.editing.EditingSession.close (EditingSession.java:131)
em io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession (EditingSessionManager.java:116)
em io.apicurio.hub.core.editing.EditingSessionManager $ Proxy $ _ $$ _ WeldClientProxy.closeEditingSession (fonte desconhecida)
em io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession (EditApiDesignEndpoint.java:215)
em sun.reflect.NativeMethodAccessorImpl.invoke0 (método nativo)
em sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
em sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
em java.lang.reflect.Method.invoke (Method.java:498)
em io.undertow.websockets.jsr.annotated.BoundMethod.invoke (BoundMethod.java:87)
em io.undertow.websockets.jsr.annotated.AnnotatedEndpoint $ 4.run (AnnotatedEndpoint.java:201)
em io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:169)
em io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:166)
em io.undertow.servlet.core.ContextClassLoaderSetupAction $ 1.call (ContextClassLoaderSetupAction.java:43)
em org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda $ create $ 0 (SecurityContextThreadSetupAction.java:105)
em org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
em org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
em org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
em org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
em io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod (ServerWebSocketContainer.java:603)
em io.undertow.websockets.jsr.ServerWebSocketContainer $ 6.run (ServerWebSocketContainer.java:589)
em io.undertow.websockets.jsr.OrderedExecutor $ ExecutorTask.run (OrderedExecutor.java:67)
em org.jboss.threads.ContextClassLoaderSavingRunnable.run (ContextClassLoaderSavingRunnable.java:35)
em org.jboss.threads.EnhancedQueueExecutor.safeRun (EnhancedQueueExecutor.java:1985)
em org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.doRunTask (EnhancedQueueExecutor.java:1487)
em org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.run (EnhancedQueueExecutor.java:1378)
em java.lang.Thread.run (Thread.java:748) `` `

Tenho certeza de que esse é exatamente o erro que eu esperaria se a correção do bug não estivesse presente. Deixe-me descobrir alguns links para o código ...

ok, acabei de verificar para não perder seu tempo, mas parece ser a versão final:

Versão | 0.2.44.Final
- | -
Construído em | 21 de novembro de 2019
Edição | CLIv7
URL do projeto | http://www.apicur.io/

Testamos APIs antigas que já existiam, criamos novas APIs e testamos e tentamos com contas diferentes.

Ok, obrigado. Então, o que está acontecendo com esse rastreamento de pilha é que, sempre que todos os editores de uma API terminarem de editar (sair / fechar o editor), o servidor tentará acumular todas as alterações em um instantâneo do documento. Isso é feito por um executor de rollup aqui:

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

Ele está tentando fazer isso:

1) Obtenha o ÚLTIMO documento instantâneo
2) Obtenha uma lista de todas as mudanças (comandos) desde então
3) Aplicar todas as alterações / comandos ao último documento instantâneo
4) Armazene o NOVO instantâneo de volta no banco de dados

Ele está falhando na etapa 1 porque não consegue encontrar o instantâneo anterior. Isso deve ser impossível porque um instantâneo é criado quando o design da API é criado pela primeira vez. No entanto, isso está acontecendo provavelmente porque a opção "compartilhar para todos" está habilitada para o componente -api Apicurio, mas não para o componente -ws Apicurio. Portanto, o instantâneo original existe na tabela, mas foi criado pelo usuário A, portanto, quando o usuário B tenta fazer o rollup (e o compartilhamento para todos está desabilitado), o SQL errado é executado ao procurar o instantâneo e não é encontrado. Portanto, é provável que este código não esteja funcionando corretamente devido a uma configuração incorreta do recurso de compartilhamento para todos apenas no componente -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

Se o compartilhamento para todos estiver habilitado em -api, mas não em -ws, isso ocorrerá.

Eu preciso ver a configuração do seu kubernetes (nota lateral: alguma chance de você querer contribuir com isso?), Mas estou supondo que se você baseou-a na configuração de composição do docker, está perdendo o compartilhamento para todos opção de configuração no componente -ws. Aqui está uma das principais soluções para esse problema:

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

Ei Eric,

obrigado pela dica. Nós "consertamos" nosso problema configurando o compartilhamento para todos também em pods -ws. Eu não vi isso como uma opção em https://hub.docker.com/r/apicurio/apicurio-studio-ws. É por isso que não o coloquei lá.

Se você quiser, eu limparia o k8s-configs e enviaria uma solicitação de pull com ele. Acho que posso fazer isso até o início da próxima semana.

Excelente! Vou atualizar os documentos dessa imagem para incluir essa opção. Sem pressa nas configurações do k8s, mas a contribuição seria muito bem-vinda.

Esta página foi útil?
0 / 5 - 0 avaliações