It would coincide with a typical fd ulimit of 2048. If the issue is actually too many tcp connections, I can't see why, as both the client and server should close the connection after completion. And, you are running these client connections serially. Maybe try dummying out the database calls. I think Peter is right that it's trying to serialize a database exception and failing. One option would be to handle the db open or query exception yourself in your server and print out the exception (before reraising it). Jim
> On Dec 8, 2015, at 17:42, Matt Welland <[email protected]> wrote: > >> On Tue, Dec 8, 2015 at 12:44 AM, Peter Bex <[email protected]> wrote: >> On Mon, Dec 07, 2015 at 10:38:33PM -0700, Matt Welland wrote: >> > I don't understand why this is crashing. I'm guessing I'm failing to close >> > a connection or finalize something. I also saw the same problem when I used >> > sqlite3 instead of sql-de-lite. Any help or suggestions of where to look >> > would be appreciated. >> >> From the call chain, it looks like something broke during query execution >> and it's trying to serialize the exception object, which probably contains >> a reference to the database connection (which is a pointer). >> >> Try catching all exceptions and raising a placeholder exception with a >> simple (error "foo") > > Thanks Peter. I'm not sure where to add this but I'll experiment with it > tonight. > > I did test on a different system today and it kept going past 6k calls. > However running "netstat|wc -l" showed a rapidly increasing number of TCP > connections. It seems likely I'm not closing the connection but I don't see > where to add the close. > >> >> Cheers, >> Peter > > _______________________________________________ > Chicken-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/chicken-users
_______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
