Apicurio-studio: Problem beim Speichern von API-Änderungen während der Zusammenarbeit

Erstellt am 20. Nov. 2019  ·  13Kommentare  ·  Quelle: Apicurio/apicurio-studio

Die gleichzeitige Nutzung von apicurio studio durch zwei Entwickler verursacht Speicherprobleme für den Entwickler, der nicht der Schöpfer von Api ist.
Der 'Nicht-Eigentümer' der API erhält keine Nachricht, dass seine Datenänderungen nicht in der Datenbank gespeichert wurden. Wenn der Cache aktualisiert wird, gehen alle Änderungen verloren und eine alte Version seiner Arbeit erscheint.
Der API-Besitzer hat diese Probleme nicht. Seine Änderungen werden gespeichert.
Als Nicht-API-Besitzer kann ich eine Kopie der API erstellen und mit dem Normalen weiterarbeiten. Aber dann hat der Kollege die Gedächtnisprobleme

@fangen
@bodograumann

bug

Hilfreichster Kommentar

Hallo Erik,

danke für den Tipp. Wir "behoben" unser Problem, indem wir share-for-everyone auch auf -ws-Pods gesetzt haben. Ich habe es nicht als Option auf https://hub.docker.com/r/apicurio/apicurio-studio-ws gesehen. Deshalb habe ich es dort nicht eingetragen.

Wenn du möchtest, würde ich die k8s-configs bereinigen und dir einen Pull-Request damit schicken. Ich denke, das kann ich bis Anfang nächster Woche erledigen.

Alle 13 Kommentare

Das ist nicht gut. Welche Version von Apicurio verwendest du? Geschieht dies in der Cloud-Version oder führen Sie es lokal aus? Ich habe vor kurzem ein Problem wie dieses gefunden und behoben (aber nur bei Verwendung der SHARE_FOR_EVERYONE Funktion), aber wenn Sie die neueste Version verwenden oder diese Funktion nicht verwenden, kann dies ein neuer Fehler sein.

Wir haben die neueste Version 0.243.final in kubernetes laufen und SHARE_FOR_EVERYONE ist aktiviert.

Danke, dass Sie sich so schnell bei uns gemeldet haben @EricWittmann.
Seltsamerweise werden die Änderungen im Aktivitätsprotokoll angezeigt, obwohl sie nach einem erneuten Laden nicht persistent sind.
Hoffentlich kann @t-rap bald einen Blick in die Datenbank werfen.

Hey,

Entschuldigung für die späte Antwort:

Wir führen apicurio-studio auf Kubernetes mit den Docker-Images aus, die Sie über den Docker-Hub bereitstellen.
So
Apicurio-studio-ui, -ws, -api, -db (Bild: percona:5.7)

Wenn unsere Entwickler es verwenden, lautet die Debug-Meldung auf apicurio-studio-api die folgende:

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

Für apicurio-studio-ws gibt:

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

Dies war also definitiv der Fehler, den ich kürzlich behoben habe - es ist möglich, dass ich ihn nach der neuesten Version behoben habe. Lass mich das überprüfen und melde mich hier wieder.

OK Ich habe bestätigt, dass mein Fix für dieses Problem nach der neuesten Version durchgeführt wurde. Sie haben also zwei Möglichkeiten, dies zu beheben:

1) Warte auf die nächste Veröffentlichung
2) Erstellen Sie die neueste Version von Master und führen Sie diese aus

Option (2) ist wahrscheinlich zugänglicher, als Sie vielleicht denken, aber offensichtlich immer noch nicht ideal für Sie. Ich könnte wahrscheinlich Ende der Woche eine weitere Veröffentlichung machen. Es wurden einige experimentelle Funktionen hinzugefügt, die ich deaktivieren (oder zumindest in der Benutzeroberfläche als solche markieren) muss, bevor ich eine Veröffentlichung auslösen kann.

Ich starte gerade eine neue Version - wird den Fix für dieses Problem enthalten. Als geschlossen markieren, damit es in den Versionshinweisen enthalten ist. :)

hallo erik,

Das Problem scheint immer noch vorhanden zu sein, aber es löst jetzt eine Ausnahme aus. Ich bin mir nicht sicher, ob es unsere Schuld ist oder nicht. Habt ihr einen Tipp wo ich tiefer reinschauen kann?

```2019-11-22 10:16:14,057 FEHLER [io.apicurio.hub.core.storage.jdbc.JdbcStorage] (Standardaufgabe-1) Fehler beim Abrufen des neuesten Inhaltsdokuments: java.lang.IllegalStateException: Ein Element erwartet , aber keine gefunden
unter org.jdbi.v3.core.result.ResultIterable.one(ResultIterable.java:135)
unter io.apicurio.hub.core.storage.jdbc.JdbcStorage.lambda$getLatestContentDocument$23(JdbcStorage.java:655)
unter org.jdbi.v3.core.Jdbi.withHandle(Jdbi.java:341)
unter io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument(JdbcStorage.java:648)
at io.apicurio.hub.core.storage.jdbc.JdbcStorage$Proxy$_$$_WeldClientProxy.getLatestContentDocument(Unbekannte Quelle)
unter io.apicurio.hub.core.storage.RollupExecutor.rollupCommands(RollupExecutor.java:56)
unter io.apicurio.hub.core.storage.RollupExecutor.rollupCommands(RollupExecutor.java:108)
unter io.apicurio.hub.core.storage.RollupExecutor$Proxy$_$$_WeldClientProxy.rollupCommands(Unbekannte Quelle)
at io.apicurio.hub.core.editing.EditingSession.close(EditingSession.java:131)
at io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession(EditingSessionManager.java:116)
at io.apicurio.hub.core.editing.EditingSessionManager$Proxy$_$$_WeldClientProxy.closeEditingSession(Unbekannte Quelle)
unter io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession(EditApiDesignEndpoint.java:215)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Methode)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at io.undertow.websockets.jsr.annotated.BoundMethod.invoke(BoundMethod.java:87)
bei io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$4.run(AnnotatedEndpoint.java:201)
unter io.undertow.websockets.jsr.ServerWebSocketContainer$1.call(ServerWebSocketContainer.java:169)
unter io.undertow.websockets.jsr.ServerWebSocketContainer$1.call(ServerWebSocketContainer.java:166)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod(ServerWebSocketContainer.java:603)
unter io.undertow.websockets.jsr.ServerWebSocketContainer$6.run(ServerWebSocketContainer.java:589)
at io.undertow.websockets.jsr.OrderedExecutor$ExecutorTask.run(OrderedExecutor.java:67)
unter org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
unter org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
bei java.lang.Thread.run(Thread.java:748)

2019-11-22 10:16:14,057 FEHLER [io.apicurio.hub.core.editing.EditingSession] (Standardaufgabe-1) Fehler beim Schließen einer Bearbeitungssitzung erkannt.: io.apicurio.hub.core.Exceptions.NotFoundException
unter io.apicurio.hub.core.storage.jdbc.JdbcStorage.getLatestContentDocument(JdbcStorage.java:659)
at io.apicurio.hub.core.storage.jdbc.JdbcStorage$Proxy$_$$_WeldClientProxy.getLatestContentDocument(Unbekannte Quelle)
unter io.apicurio.hub.core.storage.RollupExecutor.rollupCommands(RollupExecutor.java:56)
unter io.apicurio.hub.core.storage.RollupExecutor.rollupCommands(RollupExecutor.java:108)
unter io.apicurio.hub.core.storage.RollupExecutor$Proxy$_$$_WeldClientProxy.rollupCommands(Unbekannte Quelle)
at io.apicurio.hub.core.editing.EditingSession.close(EditingSession.java:131)
at io.apicurio.hub.core.editing.EditingSessionManager.closeEditingSession(EditingSessionManager.java:116)
at io.apicurio.hub.core.editing.EditingSessionManager$Proxy$_$$_WeldClientProxy.closeEditingSession(Unbekannte Quelle)
unter io.apicurio.hub.editing.EditApiDesignEndpoint.onCloseSession(EditApiDesignEndpoint.java:215)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Methode)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at io.undertow.websockets.jsr.annotated.BoundMethod.invoke(BoundMethod.java:87)
bei io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$4.run(AnnotatedEndpoint.java:201)
unter io.undertow.websockets.jsr.ServerWebSocketContainer$1.call(ServerWebSocketContainer.java:169)
unter io.undertow.websockets.jsr.ServerWebSocketContainer$1.call(ServerWebSocketContainer.java:166)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod(ServerWebSocketContainer.java:603)
unter io.undertow.websockets.jsr.ServerWebSocketContainer$6.run(ServerWebSocketContainer.java:589)
at io.undertow.websockets.jsr.OrderedExecutor$ExecutorTask.run(OrderedExecutor.java:67)
unter org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
unter org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)```

Ich bin mir ziemlich sicher, dass dies genau der Fehler ist, den ich erwarten würde, wenn die Fehlerbehebung nicht vorhanden wäre. Lassen Sie mich ein paar Links zum Code ausgraben ...

ok, ich habe gerade nachgesehen, um keine Zeit zu verschwenden, aber es scheint die endgültige Version zu sein:

Version | 0.2.44.Finale
-- | --
Aufgebaut | 21. November 2019
Ausgabe | CLIv7
Projekt-URL | http://www.apicur.io/

Wir haben alte APIs, die bereits existierten, getestet, neue APIs erstellt und getestet und wir haben es mit verschiedenen Konten ausprobiert.

OK danke. Was also mit diesem Stack-Trace passiert, ist, dass der Server immer dann versucht, alle Änderungen in einen Dokument-Snapshot zusammenzufassen, wenn alle Editoren einer API mit der Bearbeitung fertig sind (den Editor verlassen/schließen). Dies geschieht durch einen Rollup-Executor hier:

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

Es wird versucht, dies zu tun:

1) Holen Sie sich den LETZTEN Dokumentschnappschuss
2) Holen Sie sich eine Liste aller Änderungen (Befehle) seither
3) Wenden Sie alle Änderungen/Befehle auf den letzten Dokumentschnappschuss an
4) Speichern Sie den NEUEN Snapshot zurück in die DB

Es schlägt bei Schritt 1 fehl, weil es den vorherigen Snapshot nicht finden kann. Dies sollte unmöglich sein, da ein Snapshot erstellt wird, wenn das API-Design zum ersten Mal erstellt wird. Dies geschieht jedoch wahrscheinlich, weil die Option "Für alle freigeben" für die -api-Apicurio-Komponente aktiviert ist, aber nicht für die -ws-Apicurio-Komponente. Der ursprüngliche Snapshot ist also in der Tabelle vorhanden, wurde jedoch von Benutzer A erstellt. Wenn Benutzer B versucht, das Rollup durchzuführen (und die Freigabe für alle deaktiviert ist), wird beim Suchen nach dem Snapshot die falsche SQL ausgeführt und nicht gefunden. Es ist also wahrscheinlich, dass dieser Code aufgrund einer Fehlkonfiguration der Share-for-Jeder-Funktion nur in der Komponente -ws apicurio nicht richtig funktioniert:

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

Wenn share-for-everyone in -api aktiviert ist, aber nicht -ws, wird dies passieren.

Ich müsste Ihr Kubernetes-Setup sehen (Randnotiz: möchten Sie das vielleicht beitragen?), aber ich vermute, dass Sie die Freigabe für alle vermissen, wenn Sie es auf der Docker-Compose-Konfiguration basieren config-Option in der Komponente -ws. Hier ist eine der wichtigsten Korrekturen für dieses Problem:

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

Hallo Erik,

danke für den Tipp. Wir "behoben" unser Problem, indem wir share-for-everyone auch auf -ws-Pods gesetzt haben. Ich habe es nicht als Option auf https://hub.docker.com/r/apicurio/apicurio-studio-ws gesehen. Deshalb habe ich es dort nicht eingetragen.

Wenn du möchtest, würde ich die k8s-configs bereinigen und dir einen Pull-Request damit schicken. Ich denke, das kann ich bis Anfang nächster Woche erledigen.

Groß! Ich werde die Dokumente für dieses Bild aktualisieren, um diese Option aufzunehmen. Keine Eile auf die k8s configs, aber der Beitrag wäre sehr willkommen.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen