Gelöst ACHTUNG: Neuer Beta Connector 2.1

daniel.jtl

Moderator
12. März 2014
1.277
28
Also das Problem liegt in dem Fall am ziehen der Kunden.
An den Memory-Limits können wir auch leider nichts ändern. Es ist nun mal unumgänglich dass der Connector bei jedem Abgleich per Join auf die Link-Tabelle prüft welche Daten zu übermitteln sind.
Je nach Menge der Daten und der Tabellen-Struktur kann das erhebliche Last verursachen.
Das Problem lässt sich aber nur durch performanteren Webspace lösen, oder das ausmisten alter Daten (sofern denn möglich).
 

B M S

Gut bekanntes Mitglied
19. Juli 2016
100
2
@daniel.jtl wie definierts du performanten Webspace?
btw. das läuft gerade bei mir alles auf nen Localhost UWAMP Server hier auf meinem Rechner.. Da Memory Limit liegt sogar bei 3084M!
Kann man die Daten irgendwie identifizieren an denen das hängen bleibt, irgendwie hilft mir das ErrorLog nicht viel?
 

B M S

Gut bekanntes Mitglied
19. Juli 2016
100
2
so die Kunden sind jetzt alle drin.. aber jetzt streikt er bei den Payments (bzw Payment.statistic)... im Log sieht man das der sich immer wiederholt ( versucht immer die gleichen Daten zu schreiben ) woran könnte das liegen?
Aus was wird den die endpoint_id zusammengesetzt.. bei alle jtl tabellen kann ich mir das erklären nur bei der payments ergibt sich hier kein sinn für mich.. vielleicht finde ich dann raus woran es hakt!
(ja macht auch kein Sinn wenn das was in das Feld geschrieben werden soll, falsch formatiert ist.. siehe Post 84)
 
Zuletzt bearbeitet:

B M S

Gut bekanntes Mitglied
19. Juli 2016
100
2
@daniel.jtl man man man... weißte worans lag? Wieder ne Falsche Formatierung... die endpoint_id in der Tabelle jtl_connector_link_payment war mit Typ Int(10) gesetzt.. da kahm natürlich nur kuddelmuddel raus (zb PayPal ID ist 17Zeichen und mit Buchstaben).. habe das Feld jetzt auch auf VarChar(20).. unds Connector rennt..

So langsam Frage ich mich ob das jemand mit absicht gemacht hat!?! :)
 
Zuletzt bearbeitet:

daniel.jtl

Moderator
12. März 2014
1.277
28
die endpoint_id in der Tabelle jtl_connector_link_payment war mit Typ Int(10) gesetzt.
Werde das mal für zukünftige Updates höher setzen.
Es wundert mich allerdings dass das bei hunderten Installationen, abgesehen von dir, noch bei keinem Probleme gemacht hat.
Muss mal gucken ob sich da seitens Gambio eventuell auch was geändert hat, dass das noch keinem aufgefallen ist...
 

B M S

Gut bekanntes Mitglied
19. Juli 2016
100
2
@daniel.jtl ja keine Ahnung..
aber mußte noch zusätzlich von int in varchar ändern damit das mit PayPal funktioniert..
und wenn de schon dabei bist.. hatte ja gepostet das ich den varchar der endpoint_id in der jtl_connector_link_product Tabelle auf 20 gesetzt habe.. 10 ist zu kurz fals die Artikel mit Varianten die 10000 übersteigen dann wird abgeschnibbelt und der Connector dreht im Kreis (daher kommen dann auch die out of memory errors).. siehe Post 79
 

B M S

Gut bekanntes Mitglied
19. Juli 2016
100
2
@daniel.jtl in welcher Tabelle werden den die Varakombis gespeichert.. suche den Datenbestand, damit ich direkt auf die Tabelle zugreifen kann und Bestandsupdate machen kann.. Über die Ameise dauert das irgendwie ewig.. was de mit sql befehlen in sec erledigen kannst..
 

daniel.jtl

Moderator
12. März 2014
1.277
28
In der Wawi? Kann ich dir leider nichts zu sagen, da müsstest du im Wawi-Forum mal nachfragen. Generell ist es aber keine gute Idee da manuell einzugreifen, da die Wawi-DB extrem viele Trigger und Relationen hat...
 

Kurzschluss1964

Aktives Mitglied
14. September 2013
67
0
Moin zusammen,

habe auch mal den neuen Connector testen wollen.

Folgende Fehlermeldung kommt:

Abgleich-Protokoll:
Onlineshop-Abgleich beendet für ' Gambio JTL-Connector'.


Fehler:
Exception: Can't use method return value in write context
Can't use method return value in write context
Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.


Gruß

Habe den Test agbebrochen, verwende wieder den 2.0
 
Zuletzt bearbeitet:

tecaustria

Gut bekanntes Mitglied
22. Dezember 2014
113
13
Natters
Bis wann ist denn der NEUE Connector verfügbar? Werden dort Sonderpreise auch übernommen?? Kundenpreise wie bei der WAWI neu -> JTL SHOP auch möglich??

LG
 

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
2.510
1.002
@tanuschka89 konnte Dir schon geholfen werden? Habe jetzt auch so ein Memory Problem.. Das ensteht bei Import von Bestellungen aufjedenfall machter in der Tablle jtl_connector_link_payment mal wieder nicht weiter...

Code:
JTL-Wawi: End sync
Exception: DeserializeObject-Error: Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: <. Path '', line 0, position 0.
   bei Newtonsoft.Json.JsonTextReader.ParseValue()
   bei Newtonsoft.Json.JsonTextReader.ReadInternal()
   bei Newtonsoft.Json.JsonTextReader.Read()
   bei Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadForType(JsonReader reader, JsonContract contract, Boolean hasConverter)
   bei Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   bei Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   bei Newtonsoft.Json.JsonConvert.DeserializeObject(String value, Type type, JsonSerializerSettings settings)
   bei Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value, JsonSerializerSettings settings)
   bei jtlCore.ControllerClasses.Connector.Core.Json.DeserializeObject[T](String json)

Json:<br />
<font size='1'><table class='xdebug-error xe-fatal-error' dir='ltr' border='1' cellspacing='0' cellpadding='1'>
<tr><th align='left' bgcolor='#f57900' colspan="5"><span style='background-color: #cc0000; color: #fce94f; font-size: x-large;'>( ! )</span> Fatal error: Out of memory (allocated 2621440) (tried to allocate 4194304 bytes) in Unknown on line <i>0</i></th></tr>
</table></font>
Exception bei Customer.statistic:

DeserializeObject-Error: Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: <. Path '', line 0, position 0.
   bei Newtonsoft.Json.JsonTextReader.ParseValue()
   bei Newtonsoft.Json.JsonTextReader.ReadInternal()
   bei Newtonsoft.Json.JsonTextReader.Read()
   bei Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadForType(JsonReader reader, JsonContract contract, Boolean hasConverter)
   bei Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   bei Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   bei Newtonsoft.Json.JsonConvert.DeserializeObject(String value, Type type, JsonSerializerSettings settings)
   bei Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value, JsonSerializerSettings settings)
   bei jtlCore.ControllerClasses.Connector.Core.Json.DeserializeObject[T](String json)

Json:<br />
<font size='1'><table class='xdebug-error xe-fatal-error' dir='ltr' border='1' cellspacing='0' cellpadding='1'>
<tr><th align='left' bgcolor='#f57900' colspan="5"><span style='background-color: #cc0000; color: #fce94f; font-size: x-large;'>( ! )</span> Fatal error: Out of memory (allocated 2621440) (tried to allocate 4194304 bytes) in Unknown on line <i>0</i></th></tr>
</table></font>

Response: <br />
<font size='1'><table class='xdebug-error xe-fatal-error' dir='ltr' border='1' cellspacing='0' cellpadding='1'>
<tr><th align='left' bgcolor='#f57900' colspan="5"><span style='background-color: #cc0000; color: #fce94f; font-size: x-large;'>( ! )</span> Fatal error: Out of memory (allocated 2621440) (tried to allocate 4194304 bytes) in Unknown on line <i>0</i></th></tr>
</table></font>


Also bei mir ist eine derartige Fehlermeldung (ich hatte sie jetzt nicht auswendig gelernt, aber der Inhalt war ähnlich bis auf die Speichermeldung) aufgetaucht, als ich den Connector mit Standardeinstellungen per FTP hochgeladen habe. Danach habe ich es noch einmal im Binärmodus getan und dann lief er...

Allerdings hatten wir unter type=2 und type=4 jeweils einen doppelten Eintrag, den ich erst noch händisch löschen musste, damit die Datenbankmigration einwanfrei durchlief.

Ansonsten habe ich gesehen, dass es im gitlab bereits die Version 2.2 gibt (https://gitlab.jtl-software.de/jtlconnector/gambio-connector-gx3/blob/master/version).
Die Changelog.md hängt leider immer noch bei der 1.9 fest und ansonsten konnte ich keine großen Änderungen anstatt Bugfixes und "tmp fallback" erkennen. Ist die 2.1 damit aus dem Beta-Stadium raus und die 2.2 produktiv verwendbar?
Was hat es ansonsten mit der 2.2 auf sich?
 

daniel.jtl

Moderator
12. März 2014
1.277
28
Was hat es ansonsten mit der 2.2 auf sich?
In der 2.2 gab es:
- Fallback für tmp Dateien (nicht funktionierendes sys_get_temp_dir() aufgrund fehlerhafter Server-Einstellungen wird damit umgangen)
- Problem-Behebung im Zusammenhang mit Einheiten (diese wurden in manchen Konstellationen bei jedem Ableich leer neu angelegt)

Der Connector kann auch gerne unter:
http://downloads.jtl-software.de/jtlconnector/Gambio/jtl_connector_gambio_2.2.zip
geladen und getestet werden.

Dieser wird in Kürze auch "normal" veröffentlicht...
 
  • Gefällt mir
Reaktionen: dietrim2

bork

Sehr aktives Mitglied
26. Januar 2007
838
99
Also seit Beta 2.2 kommt es immer wieder mal vor, dass Variationen doppelt in einen JTL Wawi Auftrag importiert werden. Entweder läuft da was mit der Migration von 2.1 auf 2.2. nicht richtig, oder in der Datenbank stimmt was nicht, was vorher nicht von Bedeutung war und seit 2.2 Probleme macht. Bin für jeden Tipp dankbar um das Problem zu tracken (und empfehle vorerst nicht, aus der 2.2 eine Release Version zu machen)...
 

bork

Sehr aktives Mitglied
26. Januar 2007
838
99
Die Sache mit den unendlich anschwellenden quantity_units habe ich auch noch nicht lösen können, aber vielleicht ist das nur ein Einzelproblem bei uns. Schaut doch mal nach ob das Problem bei euch auch besteht: Sehr viele Einträge in der Gambio-Datenbank in Tabelle quantity_unit. Ich habe jetzt erstmal in der features.json alles abgestellt was mit Grundpreisen und Mengeneinheiten zu tun hat, aber darüber lässt sich der Upload offenbar auch nicht unterbinden. Bei uns läuft gerade ein Cronjob, der in der Gambio-DB wöchentlich alle quantity_units mit id > 22.000 löscht.

@daniel.jtl du hast ja gesagt, ich soll mal schauen, ob da was in der Datenbank nicht stimmt. Welche Datenbank meinst du und in welcher Tabelle muss ich nach was suchen?
 

Ähnliche Themen