I'm guessing here, but these lines:
/usr/share/racket/pkgs/db-lib/db/private/mysql/message.rkt:417:0:
parse-packet
/usr/share/racket/pkgs/db-lib/db/private/mysql/connection.rkt:105:4:
recv* method in connection%
suggest to me that the issue is:
1) The connection handle is stale or not established
2) It's failing to make the connection before the initial call is
made, so it receives something that isn't a packet back (my guess
would be #f, but that's purely a guess).
3) The connection then finishes being made so the second call works.
The reason it works on localhost is that the DB is instantly available
with no network latency and your handles are not stale.
As an aside, I would suggest using bind params for your SQL instead of
assembling it as a string. It will be faster, might fix your problem,
and will be substantially more secure depending on where your data is
coming from. It will also allow the handle to cache statements for
future use. The only change you need is to get rid of the
string-append:
(query-exec
dbc
"INSERT INTO participant (subscribed, next_matrix,
completion_code, comprehension_incorrect, comprehension_question)
VALUES (1, 1, ?, 0, 0)"
(random 1000000))
Hope this helps,
Dave
On Wed, Apr 5, 2017 at 12:08 PM, Marc Kaufmann
<[email protected]> wrote:
> Hi all,
>
> I have the following code that occasionally throws an error when called, but
> definitely not always:
>
> "
> (define (study-add-participant! a-study)
> (displayln-date)
> (define dbc (study-db a-study))
> (displayln "Inserting new participant...")
> (query-exec
> dbc
> (string-join
> '(
> "INSERT INTO participant (subscribed, next_matrix,
> completion_code, comprehension_incorrect, comprehension_question)"
> "VALUES (1, 1, ?, 0, 0)"))
> (number->string (random 1000000)))
> (displayln "New participant inserted. Getting id of new participant...")
> ... ; More stuff
> "
>
> Sometimes I hit the following error, but never if I refresh the page that
> calls 'study-add-participant!, and usually I don't hit the error at all.
>
> "
> Servlet (@ /tutorial) exception:
> io:read-le-intN: internal error;
> unexpected eof; got #<eof>
>
> context...:
> /usr/share/racket/collects/db/private/generic/interfaces.rkt:209:0: error*9
> /usr/share/racket/pkgs/db-lib/db/private/mysql/message.rkt:417:0:
> parse-packet
> /usr/share/racket/pkgs/db-lib/db/private/mysql/connection.rkt:105:4: recv*
> method in connection%
> .../more-scheme.rkt:261:28
> /usr/share/racket/collects/db/private/generic/common.rkt:276:13
>
> /usr/share/racket/collects/db/private/generic/../../../racket/private/more-scheme.rkt:261:28
> [repeats 1 more time]
> /usr/share/racket/collects/db/private/generic/functions.rkt:141:0:
> compose-statement
> /usr/share/racket/collects/db/private/generic/functions.rkt:216:0:
> query-exec
> /home/marc/mturk/model.rkt:99:0: study-add-participant!
> /home/marc/mturk/pages.rkt:563:0: tutorial
>
> /usr/share/racket/collects/racket/contract/private/arrow-higher-order.rkt:342:33
> [repeats 1 more time]
>
> /usr/share/racket/pkgs/web-server-lib/web-server/dispatchers/dispatch-servlets.rkt:58:2
>
> /usr/share/racket/collects/racket/contract/private/arrow-higher-order.rkt:342:33
> [repeats 1 more time]
> ...
> "
>
> From the logs, I know that this happens in the query-exec, since I see the
> first `displayln message, but not the second one. What I do not understand is
> how I can hit the message sometimes but not other times? What (hidden?) state
> is there that is changing and sometimes causes the io:read-le-intN to fail?
>
> If it helps with diagnosing:
>
> - The query did not get run successfully on the database.
> - The query itself is correct, since it succeeds the second time, and since
> it succeeded yesterday. Thus, it's not that I am addressing a missing
> database or anything.
> - I have never yet hit this error when running the code on localhost for
> testing and development. This is on the live server.
>
> I am happy to provide more logs or run commands to figure out what is going
> on, but unfortunately I cannot even replicate the bug reliably (I hit it 4
> times so far.
>
> Thanks,
> Marc
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
