Apicurio-studio: Guardar el problema de cambios de API mientras se colabora

Creado en 20 nov. 2019  ·  13Comentarios  ·  Fuente: Apicurio/apicurio-studio

El uso simultáneo de apicurio studio por dos desarrolladores provoca problemas de ahorro para el desarrollador que no es el creador de Api.
El 'no propietario' de la API no recibe ningún mensaje de que sus cambios de datos no se han almacenado en la base de datos. Cuando se actualiza la caché, todos los cambios se pierden y aparece una versión antigua de su trabajo.
El propietario de la API no tiene estos problemas. Sus cambios se almacenarán.
Como no propietario de una API, puedo hacer una copia de la API y seguir trabajando con el archivo normal. Pero luego el colega tiene problemas de memoria

@trampa
@bodograumann

bug

Comentario más útil

Oye Eric,

gracias por la pista. "Solucionamos" nuestro problema estableciendo share-for-Everyone también en -ws pods. No lo vi como una opción en https://hub.docker.com/r/apicurio/apicurio-studio-ws. Por eso no lo puse ahí.

Si lo desea, limpiaría los k8s-configs y le enviaría una solicitud de extracción con él. Creo que puedo hacerlo hasta principios de la semana que viene.

Todos 13 comentarios

Eso no es bueno. ¿Qué versión de Apicurio estás usando? ¿Está sucediendo esto en la versión en la nube o lo está ejecutando localmente? Recientemente encontré y solucioné un problema como este (pero solo cuando uso la función SHARE_FOR_EVERYONE ), pero si está usando la última versión o no usa esa función, entonces esto podría ser un nuevo error.

Tenemos la última versión 0.243.final ejecutándose en kubernetes y SHARE_FOR_EVERYONE está activado.

Gracias por respondernos tan rápido @EricWittmann.
Curiosamente, los cambios se muestran en el Registro de actividad aunque no son persistentes después de una recarga.
Con suerte, @ t-rap podrá echar un vistazo a la base de datos pronto.

Oye,

Lo siento por la respuesta tardía:

Estamos ejecutando apicurio-studio en kubernetes con las imágenes de la ventana acoplable que proporciona a través del concentrador de la ventana acoplable.
Entonces
Apicurio-studio-ui, -ws, -api, -db (imagen: percona: 5.7)

Cuando nuestros desarrolladores lo usan, el mensaje de depuración en apicurio-studio-api es el siguiente:

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 ofrece:

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

Así que este fue definitivamente el error que solucioné recientemente; es posible que lo haya arreglado después de la versión más reciente. Déjame comprobarlo y volver a ponerte en contacto contigo.

De acuerdo, he confirmado que mi solución para este problema se realizó después de la versión más reciente. Entonces tienes dos opciones para arreglar esto:

1) Espere el próximo lanzamiento
2) Construya lo último a partir del maestro y ejecútelo

La opción (2) es probablemente más accesible de lo que piensa, pero obviamente no es ideal para usted. Probablemente podría hacer otro lanzamiento al final de la semana. Hay un par de funciones experimentales que se han agregado que necesito deshabilitar (o al menos marcar como tales en la interfaz de usuario) antes de poder activar una versión.

Estoy lanzando una nueva versión en este momento; incluirá la solución para este problema. Marcar como cerrado para que se incluya en las notas de la versión. :)

Hola Eric,

El problema parece seguir ahí, pero ahora lanza una excepción. No estoy seguro de si es culpa nuestra o no. ¿Tiene algún indicio de que pueda analizarlo más a fondo?

`` `2019-11-22 10: 16: 14,057 ERROR [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (tarea predeterminada-1) Error al obtener el último documento de contenido: java.lang.IllegalStateException: Se esperaba un elemento , pero no encontré ninguno
en org.jdbi.v3.core.result.ResultIterable.one (ResultIterable.java:135)
en io.apicurio.hub.core.storage.jdbc.JdbcStorage.lambda $ getLatestContentDocument $ 23 (JdbcStorage.java:655)
en org.jdbi.v3.core.Jdbi.withHandle (Jdbi.java:341)
en io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument (JdbcStorage.java:648)
en io.apicurio.hub.core.storage.jdbc.JdbcStorage $ Proxy $ _ $$ _ WeldClientProxy.getLatestContentDocument (Fuente desconocida)
en io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:56)
en io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:108)
en io.apicurio.hub.core.storage.RollupExecutor $ Proxy $ _ $$ _ WeldClientProxy.rollupCommands (Fuente desconocida)
en io.apicurio.hub.core.editing.EditingSession.close (EditingSession.java:131)
en io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession (EditingSessionManager.java:116)
en io.apicurio.hub.core.editing.EditingSessionManager $ Proxy $ _ $$ _ WeldClientProxy.closeEditingSession (Fuente desconocida)
en io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession (EditApiDesignEndpoint.java:215)
en sun.reflect.NativeMethodAccessorImpl.invoke0 (método nativo)
en sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
en sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
en java.lang.reflect.Method.invoke (Method.java:498)
en io.undertow.websockets.jsr.annotated.BoundMethod.invoke (BoundMethod.java:87)
en io.undertow.websockets.jsr.annotated.AnnotatedEndpoint $ 4.run (AnnotatedEndpoint.java:201)
en io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:169)
en io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:166)
en io.undertow.servlet.core.ContextClassLoaderSetupAction $ 1.call (ContextClassLoaderSetupAction.java:43)
en org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda $ create $ 0 (SecurityContextThreadSetupAction.java:105)
en org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
en org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
en org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
en org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
en io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod (ServerWebSocketContainer.java:603)
en io.undertow.websockets.jsr.ServerWebSocketContainer $ 6.run (ServerWebSocketContainer.java:589)
en io.undertow.websockets.jsr.OrderedExecutor $ ExecutorTask.run (OrderedExecutor.java:67)
en org.jboss.threads.ContextClassLoaderSavingRunnable.run (ContextClassLoaderSavingRunnable.java:35)
en org.jboss.threads.EnhancedQueueExecutor.safeRun (EnhancedQueueExecutor.java:1985)
en org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.doRunTask (EnhancedQueueExecutor.java:1487)
en org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.run (EnhancedQueueExecutor.java:1378)
en java.lang.Thread.run (Thread.java:748)

2019-11-22 10: 16: 14,057 ERROR [io.apicurio.hub.core.editing.EditingSession] (tarea predeterminada-1) Error detectado al cerrar una sesión de edición .: io.apicurio.hub.core.exceptions.NotFoundException
en io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument (JdbcStorage.java:659)
en io.apicurio.hub.core.storage.jdbc.JdbcStorage $ Proxy $ _ $$ _ WeldClientProxy.getLatestContentDocument (Fuente desconocida)
en io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:56)
en io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:108)
en io.apicurio.hub.core.storage.RollupExecutor $ Proxy $ _ $$ _ WeldClientProxy.rollupCommands (Fuente desconocida)
en io.apicurio.hub.core.editing.EditingSession.close (EditingSession.java:131)
en io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession (EditingSessionManager.java:116)
en io.apicurio.hub.core.editing.EditingSessionManager $ Proxy $ _ $$ _ WeldClientProxy.closeEditingSession (Fuente desconocida)
en io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession (EditApiDesignEndpoint.java:215)
en sun.reflect.NativeMethodAccessorImpl.invoke0 (método nativo)
en sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
en sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
en java.lang.reflect.Method.invoke (Method.java:498)
en io.undertow.websockets.jsr.annotated.BoundMethod.invoke (BoundMethod.java:87)
en io.undertow.websockets.jsr.annotated.AnnotatedEndpoint $ 4.run (AnnotatedEndpoint.java:201)
en io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:169)
en io.undertow.websockets.jsr.ServerWebSocketContainer $ 1.call (ServerWebSocketContainer.java:166)
en io.undertow.servlet.core.ContextClassLoaderSetupAction $ 1.call (ContextClassLoaderSetupAction.java:43)
en org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda $ create $ 0 (SecurityContextThreadSetupAction.java:105)
en org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
en org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
en org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
en org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService $ UndertowThreadSetupAction.lambda $ create $ 0 (UndertowDeploymentInfoService.java:1502)
en io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod (ServerWebSocketContainer.java:603)
en io.undertow.websockets.jsr.ServerWebSocketContainer $ 6.run (ServerWebSocketContainer.java:589)
en io.undertow.websockets.jsr.OrderedExecutor $ ExecutorTask.run (OrderedExecutor.java:67)
en org.jboss.threads.ContextClassLoaderSavingRunnable.run (ContextClassLoaderSavingRunnable.java:35)
en org.jboss.threads.EnhancedQueueExecutor.safeRun (EnhancedQueueExecutor.java:1985)
en org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.doRunTask (EnhancedQueueExecutor.java:1487)
en org.jboss.threads.EnhancedQueueExecutor $ ThreadBody.run (EnhancedQueueExecutor.java:1378)
en java.lang.Thread.run (Thread.java:748) ''

Estoy bastante seguro de que este es exactamente el error que esperaría si la corrección del error no estuviera presente. Déjame buscar algunos enlaces al código ...

ok, acabo de comprobar para no perder el tiempo, pero parece ser la versión final:

Versión | 0.2.44.Final
- | -
Construido sobre | 21 de noviembre de 2019
Edición | CLIv7
URL del proyecto | http://www.apicur.io/

Probamos API antiguas que ya existían, creamos nuevas API y probamos y probamos con diferentes cuentas.

OK gracias. Entonces, lo que está sucediendo con ese seguimiento de pila es que, siempre que todos los editores de una API terminen de editar (dejar / cerrar el editor), el servidor intentará acumular todos los cambios en una instantánea del documento. Esto lo hace un ejecutor de resumen aquí:

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

Está intentando hacer esto:

1) Obtenga la ÚLTIMA instantánea del documento
2) Obtenga una lista de todos los cambios (comandos) desde entonces
3) Aplicar todos los cambios / comandos a la última instantánea del documento
4) Almacene la NUEVA instantánea en la base de datos

Está fallando en el paso n. ° 1 porque no puede encontrar la instantánea anterior. Esto debería ser imposible porque se crea una instantánea cuando se crea por primera vez el diseño de la API. Sin embargo, probablemente esté sucediendo porque la opción "compartir para todos" está habilitada para el componente -api Apicurio pero no para el componente -ws Apicurio. Entonces, la instantánea original existe en la tabla, pero fue creada por el usuario A, por lo que cuando el usuario B intenta hacer el resumen (y compartir para todos está deshabilitado), se ejecuta el SQL incorrecto cuando se busca la instantánea y no se encuentra. Por lo tanto, es probable que este código no funcione correctamente debido a una configuración incorrecta de la función compartir para todos solo en el 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

Si compartir para todos está habilitado en -api pero no es -ws, esto ocurrirá.

Necesitaría ver su configuración de kubernetes (nota al margen: ¿alguna posibilidad de que le gustaría contribuir con eso?), Pero supongo que si lo basó en la configuración de composición de la ventana acoplable, se está perdiendo el recurso compartido para todos opción config en el componente -ws. Esta es una de las soluciones clave para este problema:

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

Oye Eric,

gracias por la pista. "Solucionamos" nuestro problema estableciendo share-for-Everyone también en -ws pods. No lo vi como una opción en https://hub.docker.com/r/apicurio/apicurio-studio-ws. Por eso no lo puse ahí.

Si lo desea, limpiaría los k8s-configs y le enviaría una solicitud de extracción con él. Creo que puedo hacerlo hasta principios de la semana que viene.

¡Excelente! Actualizaré los documentos de esa imagen para incluir esa opción. No hay prisa en las configuraciones de k8s, pero la contribución sería muy bienvenida.

¿Fue útil esta página
0 / 5 - 0 calificaciones