2016-09-22 6 views
0

ich einen Beego HTTP-Server geschrieben haben, dass, wenn ein Benutzer einen Endpunkt hits:ImageMagick Go API HTTP Hängt auf ReadImageBlob

  • der Server ein Bild von einem anderen Server anfordert (zum Beispiel Imgur)
  • es liest die Bytes des Bildes und übergibt sie an gographics/imagick
  • diese (sollte) die Größe des Bildes und das Byte-Array des Ergebnisses

zurückkehren, was tatsächlich passiert ist, mein HTTP-Server komplett ly hängt, ich komme nicht mal zur Fehlerbehandlung, und ich bekomme ein 502 schlechtes Gateway auf allen Endpunkten des Servers.

Mein Code sieht wie folgt aus:

func processContactImage(idx int, image []byte) ([]byte, error) { 
    imagick.Initialize() 
    defer imagick.Terminate() 
    log.Println("idx: ", idx) 
    mw := imagick.NewMagickWand() 

    log.Println("reading image blob: ", image) 
    err := mw.ReadImageBlob(image) 
    if err != nil { 
     log.Println("reading blob failed: ", err) 
     return []byte{}, err 
    } 
//... 
} 

ich im Terminal die Log-Nachricht „Lesen von Bild Blob: [Byte, Bytes Bytes]“ sehen können, und ich habe die Bytes an ein anderes kleines Programm gedruckt kopiert Testen Sie die Bytes in der Tat halten ein Bild, sie tun. Es hängt vollständig auf err := mw.ReadImageBlob(image) und ich glaube nicht, dass es sogar in die if err != nil kommt, wie ich nie diese Protokollnachricht sehen.

Tipps, wie ich dies debuggen sollte willkommen sein. Ich habe ein kleines Programm geschrieben, um die Bild-Magick-Funktionen auf dem Byte-Array in einer Standalone-Umgebung zu testen, und alles funktioniert gut.

Meine Gedanken:

  • Ich verstehe nicht ganz, wie Go-Stack/Heap-Griffe, dachte ich es in der Lage war, die Dinge auf den Heap zu bewegen, wenn notwendig, und ich brauche nicht diese zu verwalten. Allerdings speichere ich ein Bild im Speicher, ich dachte vielleicht seg fault aber ich bin nicht sicher, warum es nicht abstürzt, aber hängt ...
  • ReadImageBlob erwartet eine Art von Bilddaten, und es nicht bekommen, obwohl ich hätte dann dachte, es zu dem Fehler kam

EDIT:

OK dank für Kommentare, nach mehr Forschung, scheint es, wie es mit der Tatsache verbunden ist, ich dies in Docker leite, hatte es nicht aufgetreten, dass dies jedoch ein Problem sein könnte:

  1. Ich habe die Initialisierung von ImageMagick nach Main verschoben und der Fehler tritt immer noch auf
  2. Wenn ich die Anwendung ohne Andockfenster ausführen, und ich ein Byte-Array an den Handler übergeben, wird ImageMagick Code ordnungsgemäß ausgeführt.
  3. Als ich in die Docker Behälter befestigen, ein kleines Testprogramm hinzufügen, um einen Kreis zu einem Bild mit imagemagick fügt hinzu (aber nicht einen Web-Service, nur binär) es funktioniert, wenn auch sehr langsam

Mein dockerfile sieht wie folgt aus:

FROM golang:1.7-alpine 

RUN apk update && apk add git && apk add g++ && apk add bzr && \ 
    rm -rf /var/cache/apk/* 

# ENV GOPATH /go 

# Install beego & bee 
RUN go get github.com/astaxie/beego 
RUN go get github.com/beego/bee 
RUN go get github.com/tools/godep 

RUN apk add --update alpine-sdk 
RUN apk add imagemagick-dev 
RUN go get gopkg.in/gographics/imagick.v2/imagick 

ich frage mich, ob ich eine Bibliothek oder etwas und seine hängenden innerhalb des C api und Go auf eine Antwort wartet am fehlt. Gibt es eine Möglichkeit, das zu debuggen?

OK ...Wie sich herausstellt, ist das Problem etwas anderes ... vielleicht mehrere Anfragen gleichzeitig oder so etwas ... Ich bin mir nicht sicher, aber ich habe dieses gist mit imagemagick, in Go, in einem Handler erstellt, und es funktioniert lokal nicht Problem in meinem Docker Container. Das Geheimnis geht weiter ....

+0

eine Stack-Trace Route genau zu zeigen, wo alles blockiert ist. Sie können auch ein kleines Standalone-Programm erstellen, das 'ReadImageBlob (image)' auf dem gleichen Eingang aufruft. – JimB

+0

Gibt es Tipps, wie man einen Stacktrace erzwingt? – amlwwalker

+0

Senden Sie den Prozess ein 'SIGQUIT'. – JimB

Antwort

2

Tun Sie dies nicht in Ihrem Handler:

imagick.Initialize() 
defer imagick.Terminate() 

, die nur einmal durchgeführt werden soll, in Ihrem main()

Höchstwahrscheinlich werden Sie mit verschiedenen widersprüchliche Anfragen, indem Sie den gesamten ImageMagick jedes Mal abreißen, wenn eine Anfrage beendet wird.

+0

Ok ich bewegte dies, und der Fehler ging weiter, so lief ich mehr Tests und ich glaube derzeit, dass der Fehler docker bezogen ist, habe ich ursprüngliche Frage – amlwwalker

+0

ich sehe aktualisiert. Nun, ich kann nicht sagen, dass ich irgendwelche Erfahrung darin habe, Imagick in einem Docker-Setup auszuführen. Obwohl ich verwirrt bin, warum es einen Unterschied macht, es sei denn, es bezieht sich auf eine Art von Einschränkung in der Umwelt. Ich habe imagick in einem Web-basierten Dienst ausgeführt, der Bilder pro Anfrage verarbeitet und Tonnen von Anfragen ohne Problem bedient. Trotzdem nicht in einer dockernden Situation. – jdi

0

Nice one @jdi es etwas mit Alpine zu tun war ...

Hier sind meine zwei Docker Dateien, die erste, die mit Alpine @ 612MB nicht funktioniert, es hängt, wenn ImageMagick den Blob zu lesen versucht, . Die zweite mit Golang: neueste und 931MB funktioniert. Ich bin mir nicht sicher warum, aber es löst mein Problem.

Danke ich hoffe das hilft jemand anderem!

FROM golang:1.7-alpine 

RUN apk update && apk add git && apk add g++ && apk add bzr && \ 
    rm -rf /var/cache/apk/* 

RUN go get github.com/astaxie/beego 
RUN go get github.com/beego/bee 
RUN go get github.com/tools/godep 

RUN apk add --update alpine-sdk 
RUN apk add imagemagick-dev 
RUN go get gopkg.in/gographics/imagick.v2/imagick 

und die zweite:

FROM golang:latest 

RUN apt-get update && \ 
    apt-get install -qy \ 
     pkg-config \ 
     libmagickcore-dev \ 
     libmagickwand-dev \ 
     imagemagick \ 
     git \ 
     g++ \ 
     bzr \ 

    #clear up 
    && apt-get autoremove && \ 
    apt-get autoclean && \ 
    apt-get clean && \ 
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* 

RUN go get gopkg.in/gographics/imagick.v2/imagick 
RUN go get github.com/astaxie/beego 
RUN go get github.com/beego/bee 
RUN go get github.com/tools/godep 
+0

Süß. Nun, alpine hat offensichtlich entweder eine widersprüchliche Standardkonfiguration oder fehlt etwas, das von der Tatsache benötigt wird, dass Imagick eine Cgo-Bindung ist und bewirkt, dass Ihre App dynamisch verknüpft wird – jdi