Support
Till senaste kommentaren
Detta inlägg är gammalt och kan innehålla inaktuell information.

Problem med Realtidsinformation 4 och https

Hej
jag har sedan några dagar haft problem att nå tjänsten Realtidsinfromation 4. När jag började felsöka så märkte jag att det fungerade med http men inte med https. I applikationen (node.js baserad) får jag "Connection reset" om jag kör med https.
https anrop fungerar ibland men kanske en gång på hundra.
Har ni gjort några förändringar i hur ni levererar https svar dom senaste dagarna? Ser på er driftsstatus att det har varit lite störningar.
Mvh
Anders

Kommentarer

  • Hej Anders,
    Jag lyckas inte återupprepa dina problem just nu. Kvarstår problemen för dig?

    Mvh Dick
    Team Trafiklab
  • Hej

    ja det gör dom. Provade nu mellan 20 och 21 då fick jag "connection reset" en fyra fem gånger initialt sedan fungerade det i en halvtimme sedan kom problemet tillbaka. Nu när jag testar så pollar jag varannan minut annars är tanken att default kör man var femte minut.

    Skulle det hjälpa om jag gjorde en liten testsnurra som ni kunde köra och se om ni får samma resultat? Mitt projekt (https://github.com/boghammar/MMM-SL-PublicTransport/tree/InToTown ) är skrivet i javascript (node.js) hela projektet är lite väl omfattande för att begära att ni testar men kanske en dedikerad testsnurra skulle funka?

    Mvh
    Anders
  • Hej Anders,

    Det har gjorts en ändring nu, har du möjlighet att kontrollera om problemet kvarstår?

    Mvh
    Erik B
  • Ja tyvärr :(. Körde några gånger idag type en 10-15 minuter med pollning varje minut.
    Först såg det ut som om antingen fungerade det eller inte men den fjärde körningen så fungerade det först och sedan slutade det att svara. Det här är loggen från min applikation:
    Module helper loaded: MMM-SL-PublicTransport
    Connecting socket for: MMM-SL-PublicTransport
    19:49:58 MMM-SL-PublicTransport: Starting helper: MMM-SL-PublicTransport
    19:50:00 MMM-SL-PublicTransport: Getting departures for station id 2322
    19:50:00 MMM-SL-PublicTransport: SL-PublicTransport: Calling https://api.sl.se/api2/realtimedeparturesV4.json
    19:50:01 MMM-SL-PublicTransport: Sending DEPARTURES 6
    19:51:00 MMM-SL-PublicTransport: Getting departures for station id 2322
    19:51:00 MMM-SL-PublicTransport: SL-PublicTransport: Calling https://api.sl.se/api2/realtimedeparturesV4.json
    19:51:01 MMM-SL-PublicTransport: Sending DEPARTURES 6
    19:52:00 MMM-SL-PublicTransport: Getting departures for station id 2322
    19:52:00 MMM-SL-PublicTransport: SL-PublicTransport: Calling https://api.sl.se/api2/realtimedeparturesV4.json
    19:52:01 MMM-SL-PublicTransport: Problems: RequestError: Error: read ECONNRESET
    19:53:00 MMM-SL-PublicTransport: Getting departures for station id 2322
    19:53:00 MMM-SL-PublicTransport: SL-PublicTransport: Calling https://api.sl.se/api2/realtimedeparturesV4.json
    19:53:01 MMM-SL-PublicTransport: Problems: RequestError: Error: read ECONNRESET
    19:54:00 MMM-SL-PublicTransport: Getting departures for station id 2322
    19:54:00 MMM-SL-PublicTransport: SL-PublicTransport: Calling https://api.sl.se/api2/realtimedeparturesV4.json
    19:54:01 MMM-SL-PublicTransport: Problems: RequestError: Error: read ECONNRESET
    19:55:00 MMM-SL-PublicTransport: Getting departures for station id 2322
    19:55:00 MMM-SL-PublicTransport: SL-PublicTransport: Calling https://api.sl.se/api2/realtimedeparturesV4.json
    19:55:01 MMM-SL-PublicTransport: Problems: RequestError: Error: read ECONNRESET
    19:56:01 MMM-SL-PublicTransport: Getting departures for station id 2322
    19:56:01 MMM-SL-PublicTransport: SL-PublicTransport: Calling https://api.sl.se/api2/realtimedeparturesV4.json
    19:56:01 MMM-SL-PublicTransport: Problems: RequestError: Error: read ECONNRESET
    19:57:01 MMM-SL-PublicTransport: Getting departures for station id 2322
    19:57:01 MMM-SL-PublicTransport: SL-PublicTransport: Calling https://api.sl.se/api2/realtimedeparturesV4.json
    19:57:01 MMM-SL-PublicTransport: Problems: RequestError: Error: read ECONNRESET


    /Anders
  • Ok, jag har tittat lite i ditt projekt. Jag undrar om det här skulle kunna vara något slags timeoutproblem även om felmeddelandet indikerar att kopplingen stängs remote.
    För att pröva så kan man testa med att ändra handshakeTimeout i tls.
    Det är bara en teori, men kan vara värt att pröva. Såg ingen setting för timeout i modulen https-proxy-agent.

    Om man kör curl mot tjänsten med https-protocoll så ser man att handshake-delen ibland tar lite längre tid, men att svaret kommer till slut, har inte observerat något fel ännu på vår sida.

    Mvh
    Erik  B.
  • Upplever samma problem fast när jag använder HTTP. Om jag väntar 5minuter mellan requests så kommer det i princip varje gång resultera i att nästa request efter 5min ger "Connection reset by peer", om jag direkt gör ett nytt anrop med samma request så får jag ett korrekt svar.

    curl_getinfo dumpat från php för request som failar:
    (
        [url] => http://api.sl.se/api2/realtimedeparturesV4.JSON?key=YYYYY&siteid=3470&timewindow=60
        [content_type] =>
        [http_code] => 0
        [header_size] => 0
        [request_size] => 264
        [filetime] => -1
        [ssl_verify_result] => 0
        [redirect_count] => 0
        [total_time] => 0.008188
        [namelookup_time] => 0.004145
        [connect_time] => 0.00633
        [pretransfer_time] => 0.006368
        [size_upload] => 0
        [size_download] => 0
        [speed_download] => 0
        [speed_upload] => 0
        [download_content_length] => -1
        [upload_content_length] => -1
        [starttransfer_time] => 0
        [redirect_time] => 0
        [redirect_url] =>
        [primary_ip] => 194.68.78.66
        [certinfo] => Array
            (
            )

        [primary_port] => 80
    )

    och curl_error($c) rapporterar: Recv failure: Connection reset by peer
  • Ja jag börjar luta åt det också. Har sett att jag får problem även vid http anrop :(. Inte lika frekvent som vid https men ändå.
    Får börja luska i hur jag fångar det här på bästa sätt och antingen gör ett nytt anrop så fort jag får connection reset eller ökar på en timeout.

    @Nick: Bra du bekräftar mina misstankar. Har också sett att har man väl fått ett fel så kommer ett antal av följande kommande request också att faila, sedan börjar det fungera helt plötsligt. I det som jag googlat på "connection reset" och "node request" så säger dom också att det kan hjälpa att göra en ny request direkt efter en failad.
  • Tack för informationen.
    Jag har också observerat "connection reset" nu.
    Återkommer när jag har mer information.

    Mvh
    Erik B.
  • Tack Erik.

    Återkommer också om jag hittar en väg fram på min sida.

    Mvh
    Anders
  • Hej

    Jag tror att jag har ett liknande problem med Realtidsinformation 4. Kör också med node.js och ett mycket enkelt projekt som enbart gör en GET request då en websida laddas.

    Får i princip alltid ECONNRESET vid första anropet (http och https). Efter det funkar det blixtsnabbt tills jag väntar några minuter och så blir det ECONNRESET igen.

    Kör jag samma url direkt i webläsare så funkar det alltid perfekt. Har tillfälligt löst det med med att använda modulen 'requestretry' som gör en ny request vid fel. Men skulle gärna vilja veta problemet beror på.

    Mitt testprojekt finns på github: https://github.com/bitpwr/bondebussen

  • Jag får också ECONNRESET fel på API:erna SL Platsuppslag och SL Reseplanerare 2 (har inte provat på era andra api:er). Jag kör http och inte https. Log historiken från mobilappen så verka detta fel börja i mitten av Oktober. Appen har inte ändrats på ett halvår.

    Jag prova att skicka frågan från CURL och lyssna på trafiken med Wireshark. Och ni svarar med ett TCP packet med längden 0 och RST, ACK. Ni stänger socketen utan att skicka tillbaka något svar.



    Om man försöker ett par gånger så får man detta fel.

    Man kan få liknande fel om man har en lastbalanserare som är fel konfigurerad och skickar vidare frågan till en maskin som inte finns.
  • Samma problem här. Med en "port knocking" fungerar det dock, men det dubblerar ju nästan antalet requests om man inte sätter en levtid på knockingen.

    Vad är status på problemet, SL?
  • Jag upplever samma problem i min iOS app. Första requesten dör, därefter fungerar det en stund.
  • Vi upplever ett liknande problem oavsett om vi använder http eller https med en tjänst som varit aktiv sedan Februari 2017. Vi har inte gjort några förändringar alls i projektet. Nu har vi haft återkommande fel sedan 5 November, varje minut. Vårt script är skrivet med PHP och utvecklaren hade valt att använda file_get_contents() istället för cURL. När vi nu har bytt till cURL fungerar det bättre men några av våra anrop som vi gör får "Connection reset by peer" istället för att få en tydlig StatusCode med information om att vi exempelvis har gjort för många anrop per minut.
  • Nu har vi testat mer ordentligt med cURL och även det började strula efter ett tag. Mycket märkligt? Vi har hittat ett riktigt fulhack som fungerar bra däremot:

    Vi gör först ett anrop mot APIet, får "Connection reset by peer", sedan kör vi en sleep(1) och efter det gör vi ett nytt cURL anrop mot APIet. Då fungerar allt såsom det ska! Det verkar onekligen som att det är något strul med er miljö.
  • .. och vi har testat detta från vår serverhall samt lokalt från olika ip-adresser och från olika miljöer. Vi har samma problem över allt.
  • Exakt så har vi också fått göra. Dvs anrop fail, sleep(1), anrop success.

    SL??
  • Hej,

    Vi arbetar fortfarande med det här och vi har antagligen hittat orsaken till problemen.
    Vi återkommer med mer information så snart som möjligt.

    Mvh
    Erik B
  • Status på detta?
  • Jag kör inte kontinuerligt mot tjänsterna men den senaste tiden har jag upplevt att det fungerar mycket bättre så något har dom gjort.
  • Ja, vi har identifierat orsaken till detta och det ska vara åtgärdat.
    Meddela gärna om problemet kvarstår.

    Mvh
    Erik B

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägg kan ses av alla. Din e-post visas aldrig publikt.