Erreur lors de l'import d'un module dans une instance créée via Docker

Bonjour,

Je n’arrive pas à importer un module dans une instance Docker.

2019-12-11 15:51:01,521 ERROR [com.simplicite.objects.System.Module] SIMPLICITE|http://497bab9c5149:8080||ERROR|designer|com.simplicite.objects.System.Module|importModule||Evénement: Unable to import module Immo from Git
    org.eclipse.jgit.api.errors.TransportException: remote: internal server error
     at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:255)
     at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:290)
     at com.simplicite.util.tools.GitTool.pull(GitTool.java:395)
     at com.simplicite.objects.System.Module.importModule(Module.java:921)
     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
     at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at java.base/java.lang.reflect.Method.invoke(Method.java:567)
     at com.simplicite.util.engine.ObjectManager.invokeActionSync(ObjectManager.java:3487)
     at com.simplicite.util.ObjectDirect.invokeAction(ObjectDirect.java:672)
     at com.simplicite.util.ObjectDB.invokeAction(ObjectDB.java:1697)
     at com.simplicite.util.ScriptedObjectDB.invokeAction(ScriptedObjectDB.java:961)
     at com.simplicite.webapp.tools.JSONServletTool.action(JSONServletTool.java:1448)
     at com.simplicite.webapp.ObjectJson.action(ObjectJson.java:650)
     at com.simplicite.webapp.tools.JSONServletTool.businessObjectService(JSONServletTool.java:575)
     at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:68)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
     at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
     at com.simplicite.webapp.filters.AuthMethodFilter.doFilter(AuthMethodFilter.java:115)
     at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
     at com.simplicite.webapp.filters.RewriteFilter.doFilter(RewriteFilter.java:77)
     at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:526)
     at com.simplicite.tomcat.valves.APISessionValve.invoke(APISessionValve.java:187)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
     at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
     at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:367)
     at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
     at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860)
     at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1591)
     at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
     at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
     at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
     at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
     at java.base/java.lang.Thread.run(Thread.java:830)
    Caused by: org.eclipse.jgit.errors.TransportException: remote: internal server error
     at org.eclipse.jgit.transport.BasePackFetchConnection.doFetch(BasePackFetchConnection.java:400)
     at org.eclipse.jgit.transport.TransportHttp$SmartHttpFetchConnection.doFetch(TransportHttp.java:1084)
     at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:323)
     at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:314)
     at org.eclipse.jgit.transport.FetchProcess.fetchObjects(FetchProcess.java:265)
     at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:163)
     at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:124)
     at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1271)
     at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:244)
     ... 47 more
    Caused by: org.eclipse.jgit.errors.TransportException: remote: internal server error
     at org.eclipse.jgit.transport.SideBandInputStream.needDataPacket(SideBandInputStream.java:176)
     at org.eclipse.jgit.transport.SideBandInputStream.read(SideBandInputStream.java:139)
     at org.eclipse.jgit.transport.PackParser.fill(PackParser.java:1261)
     at org.eclipse.jgit.transport.PackParser.readPackHeader(PackParser.java:933)
     at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:557)
     at org.eclipse.jgit.internal.storage.file.ObjectDirectoryPackParser.parse(ObjectDirectoryPackParser.java:197)
     at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:529)
     at org.eclipse.jgit.transport.BasePackFetchConnection.receivePack(BasePackFetchConnection.java:823)
     at org.eclipse.jgit.transport.BasePackFetchConnection.doFetch(BasePackFetchConnection.java:393)
     ... 55 more

Voici l’instance :

J’arrive à importer ce même module normalement vers une instance créée par SIM :


Merci d’avance pour votre aide.
Abed.

Quels est l’URI Git de ce module ?

De ce que je vois des erreurs c’est sans doute que le container Docker n’arrive pas à se connecter à l’URI du repo Git du module (d’où ma question ci-dessus).

NB : J’ai passé la question en “Support” car il n’y a rien de specifique à votre cas ici, la raison du pb (et la solution) pourront sans doute intéresser d’autres personnes.

Voici l’uri :

“uri”: “https://conjonctiondev.e3m.simplicite.io/git/Immo

OK c’est donc une URI Git en HTTPS sur un nom d’hôte DNS public.

Pouvez vous vérifier que la configuration réseau (DNS notamment) de votre container Docker permet bien de résoudre ce nom public.

Le plus simple pour faire cette vérification c’est de se connecter en bash sur le container (sudo docker exec -it <container ID> bash) et de tenter un curl sur le /health de la même instance. S’il y a un pb de config réseau vous ce curl ne marchera pas non plus.

le résultat du \health est :

[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-11-29 13:02 (revision a22b592221c1d34f743118a95182ad313cfc3000)
Encoding=UTF-8
EndpointIP=172.17.0.2
EndpointURL=http://497bab9c5149:8080
TimeZone=Europe/Paris
SystemDate=2019-12-11 16:22:53

[Application]
ApplicationVersion=4.0
ContextPath=
ContextURL=http://ns336093.ip-37-187-147.eu:82
ActiveSessions=2
EnabledUsers=21
TotalUsers=34
LastLoginDate=2019-12-11 16:03:00

[Server]
ServerInfo=Apache Tomcat/9.0.29
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=4.15.0-72-generic
SystemEncoding=UTF-8

[Disk]
DiskFree=3749803
DiskUsable=3559091
DiskTotal=3753933

[JavaVM]
Version=13.0.1
Vendor=N/A
VMName=OpenJDK 64-Bit Server VM
VMVersion=13.0.1+9
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=108225
HeapSize=201728
HeapMaxSize=4026368
TotalFreeSize=3932865

[Cache]
GrantCache=14
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=263
ObjectCacheMax=10000
ObjectCacheRatio=2
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=10.10 (Ubuntu 10.10-0ubuntu0.18.04.1)
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.2.8
DBDate=2019-12-11 16:22:53
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=false

[Healthcheck]
Date=2019-12-11 16:22:53
ElapsedTime=5

Cet appel a bien été effectué depuis l’interieur du container Docker comme expliqué ci-dessus ?

Voici comment j’ai fait :

Pour info, j’ai réussi à importer un autre module dans cette instance :
“uri”: “https://conjonctiondev.e3m.simplicite.io/git/ImmoWorkflow

Le pb se pose donc juste avec :
“uri”: “https://conjonctiondev.e3m.simplicite.io/git/Immo

Je ne comprend vraiement pas ce que vous avez fait…

Je vous ai dit de tester un curl depuis le container sur https://conjonctiondev.e3m.simplicite.io/health pas sur cette URL dont je ne sais pas à quoi elle correspond et sans les options que vous avez ajoutées (ni -k ni -u qui ne sert à rien pour le /health).

Le but du jeu à ce stade c’était de voir s’il y a des subtilités de config réseau, DNS ou SSL sur votre container Docker qui auraient pu empêcher l’accès à l’URI du module via Git over HTTPS.

Mais si vous me dites que vous avez un autre module pour lequel l’import via Git depuis une URL sur le même hostname fonctionne c’est sans doute que c’est autre chose !

Bref, regardez les logs des deux coté (i.e. coté instance source et coté instance cible) de plus près car il y a peut être d’autres éléments exploitables que juste cette stacktace obscure coté cible qui dit juste “org.eclipse.jgit.errors.TransportException: remote: internal server error”.

De manière générale, nous envoyer uniquement des fragments de logs (genre comme ici un stacktrace sans son contexte donc sans les logs précédente, etc.) n’est vraiment pas suffisant, ça complique vraiment les investigations pour nous car il faut essayer de deviner ce qui n’est pas dit…

PS: pour rappel, le contournement si la “tuyauterie” Git ne fonctionne pas pour une raison pas bien cernée c’est les exports/imports de module via fichiers XML/ZIP.

Mea culpa, effectivement, je me suis trompé de nom d’instance dans le curl.

Il y avait sûrement un autre pb ailleurs, mais la magie a opéré : sans aucune modif de mon côté, j’ai pu relancer l’import avec succès !

Merci beaucoup, et désolé pour le dérangement.