Apicurio-studio: Problème d'enregistrement des modifications de l'API pendant la collaboration

Créé le 20 nov. 2019  ·  13Commentaires  ·  Source: Apicurio/apicurio-studio

L'utilisation simultanée d'apicurio studio par deux développeurs pose des problèmes d'économie pour le développeur qui n'est pas le créateur d'Api.
Le 'non-propriétaire' de l'api ne reçoit aucun message indiquant que ses modifications de données n'ont pas été stockées dans la base de données. Lorsque le cache est actualisé, toutes les modifications sont perdues et une ancienne version de son travail apparaît.
Le propriétaire de l'API n'a pas ces problèmes. Ses modifications seront stockées.
En tant que propriétaire non-api, je peux faire une copie de l'api et continuer à travailler avec la normale. Mais alors le collègue a des problèmes de mémoire

@piéger
@bodograumann

bug

Commentaire le plus utile

Salut Éric,

merci pour l'astuce. Nous avons "résolu" notre problème en définissant également share-for-everyone sur les pods -ws. Je ne l'ai pas vu comme une option sur https://hub.docker.com/r/apicurio/apicurio-studio-ws. C'est pourquoi je ne l'ai pas mis dedans.

Si vous le souhaitez, je nettoierais les k8s-configs et vous enverrais une pull request avec. Je pense que je peux le faire jusqu'au début de la semaine prochaine.

Tous les 13 commentaires

Ce n'est pas bon. Quelle version d'Apicurio utilisez-vous ? Est-ce que cela se produit dans la version cloud ou l'exécutez-vous localement ? J'ai un peu récemment trouvé et résolu un problème comme celui-ci (mais uniquement lors de l'utilisation de la fonctionnalité SHARE_FOR_EVERYONE ), mais si vous utilisez la dernière version ou n'utilisez pas cette fonctionnalité, cela pourrait être un nouveau bogue.

Nous avons la dernière version 0.243.final en cours d'exécution dans kubernetes et SHARE_FOR_EVERYONE est activé.

Merci de nous avoir répondu si rapidement @EricWittmann.
Curieusement, les modifications sont affichées dans le journal d'activité même si elles ne sont pas persistantes après un rechargement.
Espérons que @t-rap pourra bientôt jeter un œil à la base de données.

Hey,

Désolé pour la réponse tardive:

Nous exécutons apicurio-studio sur kubernetes avec les images docker que vous fournissez via le hub docker.
Donc
Apicurio-studio-ui, -ws, -api, -db (image: percona:5.7)

Lorsque nos Devs l'utilisent, le message de débogage sur apicurio-studio-api est le suivant :

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

Pour apicurio-studio-ws donne :

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

C'est donc certainement le bogue que j'ai corrigé récemment - il est possible que je l'aie corrigé après la version la plus récente. Laissez-moi vérifier cela et revenez vers vous ici.

OK, j'ai confirmé que mon correctif pour ce problème a été fait après la version la plus récente. Vous avez donc deux options pour résoudre ce problème :

1) Attendez la prochaine version
2) Construisez le dernier à partir du maître et exécutez-le

L'option (2) est probablement plus accessible que vous ne le pensez, mais toujours évidemment pas idéale pour vous. Je pourrais faire une autre sortie probablement à la fin de la semaine. Il y a quelques fonctionnalités expérimentales qui ont été ajoutées que je dois désactiver (ou au moins marquer comme telles dans l'interface utilisateur) avant de pouvoir déclencher une version.

Je lance une nouvelle version en ce moment - inclura le correctif pour ce problème. Marquage comme fermé afin qu'il soit inclus dans les notes de version. :)

salut Eric,

Le problème semble toujours être là, mais il lève une exception maintenant. Je ne sais pas si c'est de notre faute ou non. Avez-vous un indice où je peux approfondir?

```2019-11-22 10:16:14,057 ERREUR [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (par défaut tâche-1) Erreur lors de l'obtention du dernier document de contenu : java.lang.IllegalStateException : un élément attendu , mais n'en a trouvé aucun
sur org.jdbi.v3.core.result.ResultIterable.one(ResultIterable.java:135)
sur io.apicurio.hub.core.storage.jdbc.JdbcStorage.lambda$getLatestContentDocument$23(JdbcStorage.java:655)
sur org.jdbi.v3.core.Jdbi.withHandle(Jdbi.java:341)
sur io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument(JdbcStorage.java:648)
sur io.apicurio.hub.core.storage.jdbc.JdbcStorage$Proxy$_$$_WeldClientProxy.getLatestContentDocument (source inconnue)
à io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:56)
à io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java: 108)
sur io.apicurio.hub.core.storage.RollupExecutor$Proxy$_$$_WeldClientProxy.rollupCommands (Source inconnue)
sur io.apicurio.hub.core.editing.EditingSession.close(EditingSession.java:131)
sur io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession(EditingSessionManager.java:116)
sur io.apicurio.hub.core.editing.EditingSessionManager$Proxy$_$$_WeldClientProxy.closeEditingSession (source inconnue)
à io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession(EditApiDesignEndpoint.java:215)
à sun.reflect.NativeMethodAccessorImpl.invoke0 (méthode native)
à 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)
sur org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
sur org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
sur org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
sur org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
sur 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)
sur org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
sur org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
sur org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
sur org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
sur java.lang.Thread.run(Thread.java:748)

2019-11-22 10:16:14,057 ERREUR [io.apicurio.hub.core.editing.EditingSession] (tâche par défaut-1) Erreur détectée lors de la fermeture d'une session d'édition. : io.apicurio.hub.core.exceptions.NotFoundException
sur io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument(JdbcStorage.java:659)
sur io.apicurio.hub.core.storage.jdbc.JdbcStorage$Proxy$_$$_WeldClientProxy.getLatestContentDocument (source inconnue)
à io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java:56)
à io.apicurio.hub.core.storage.RollupExecutor.rollupCommands (RollupExecutor.java: 108)
sur io.apicurio.hub.core.storage.RollupExecutor$Proxy$_$$_WeldClientProxy.rollupCommands (Source inconnue)
sur io.apicurio.hub.core.editing.EditingSession.close(EditingSession.java:131)
sur io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession(EditingSessionManager.java:116)
sur io.apicurio.hub.core.editing.EditingSessionManager$Proxy$_$$_WeldClientProxy.closeEditingSession (source inconnue)
à io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession(EditApiDesignEndpoint.java:215)
à sun.reflect.NativeMethodAccessorImpl.invoke0 (méthode native)
à 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)
sur org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
sur org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
sur org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
sur org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
sur 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)
sur org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
sur org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
sur org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
sur org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
à java.lang.Thread.run(Thread.java:748)```

Je suis presque sûr que c'est exactement l'erreur à laquelle je m'attendrais si la correction de bogue n'était pas présente. Permettez-moi de déterrer quelques liens vers le code...

ok, je viens de vérifier pour ne pas perdre votre temps, mais il semble que ce soit la version finale :

Versions | 0.2.44.Final
-- | --
Construit sur | 21 novembre 2019
Édition | CLIv7
URL du projet | http://www.apicur.io/

Nous avons testé d'anciennes API qui existaient déjà, créé de nouvelles API et testé et nous l'avons essayé avec différents comptes.

OK merci. Donc, ce qui se passe avec cette trace de pile, c'est que, chaque fois que tous les éditeurs d'une API ont terminé l'édition (quitter/fermer l'éditeur), le serveur essaiera de regrouper toutes les modifications dans un instantané de document. Ceci est fait par un exécuteur de rollup ici :

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

Il essaie de faire ceci :

1) Obtenez le DERNIER instantané du document
2) Obtenez une liste de tous les changements (commandes) depuis lors
3) Appliquer toutes les modifications/commandes au dernier instantané de document
4) Stockez le NOUVEAU snapshot dans la base de données

Il échoue à l'étape 1 car il ne trouve pas l'instantané précédent. Cela devrait être impossible car un instantané est créé lorsque la conception de l'API est créée pour la première fois. Cependant, cela se produit probablement parce que l'option "partager pour tout le monde" est activée pour le composant -api Apicurio mais pas pour le composant -ws Apicurio. L'instantané d'origine existe donc dans la table mais a été créé par l'utilisateur A. Ainsi, lorsque l'utilisateur B essaie d'effectuer le cumul (et que le partage pour tout le monde est désactivé), le mauvais code SQL est exécuté lors de la recherche de l'instantané et il est introuvable. Il est donc probable que ce code ne fonctionne pas correctement en raison d'une mauvaise configuration de la fonctionnalité de partage pour tous uniquement dans le composant -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 share-for-everyone est activé dans -api mais pas dans -ws, cela se produira.

J'aurais besoin de voir votre configuration kubernetes (note latérale : avez-vous une chance de contribuer à cela ?) config sur le composant -ws. Voici l'une des principales solutions à ce problème :

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

Salut Éric,

merci pour l'astuce. Nous avons "résolu" notre problème en définissant également share-for-everyone sur les pods -ws. Je ne l'ai pas vu comme une option sur https://hub.docker.com/r/apicurio/apicurio-studio-ws. C'est pourquoi je ne l'ai pas mis dedans.

Si vous le souhaitez, je nettoierais les k8s-configs et vous enverrais une pull request avec. Je pense que je peux le faire jusqu'au début de la semaine prochaine.

Super! Je vais mettre à jour les documents de cette image pour inclure cette option. Pas de précipitation sur les configs k8s, mais la contribution serait la bienvenue.

Cette page vous a été utile?
0 / 5 - 0 notes