I can also reproduce this with the following non-ASP code.

using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Data.Odbc;

namespace Project2
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                for (int i = 0; i < 100; i++)
                {
                    String sSql = String.Format("select az_get_daylight_time('{0}')", DateTime.Now.ToString("yyyy-MM-dd"));
                    Console.WriteLine(SelectCommand(sSql));
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }

        private const String DATABASE_CONNECTION = "Driver=SQL Anywhere 17;ENG=JackDemo;LINKS=TCPIP(HOST=127.0.0.1);Uid=dba;Pwd=sql;";

        public static String SelectCommand(String szCommand)
        {
            String result = "<null>";
            OdbcConnection conn = new OdbcConnection(DATABASE_CONNECTION);
            conn.Open();
            OdbcCommand command = new OdbcCommand(szCommand, conn);
            try
            {
                OdbcDataReader reader = command.ExecuteReader();
                while (reader.Read())
                {
                    result = "Daylight is " + reader.GetInt32(0);
                }
                reader.Close();
            }
            catch (OdbcException ex)
            {
                Console.WriteLine(ex.ToString());
            }
            conn.Close();
            return result;
        }
    }
}

System.Data.Odbc.OdbcException (0x80131937): ERROR [40001] [SAP][ODBC Driver][SQL Anywhere]All threads are blocked
   at System.Data.Odbc.OdbcConnection.HandleError(OdbcHandle hrHandle, RetCode retcode)
   at System.Data.Odbc.OdbcDataReader.Read()

My first attempt at a reproducible connected once and iterated the command 1000 times with no issue and then disconnected.

This version is connecting/disconnecting on every iteration. I'll check into this.

While we are looking into this problem, consider this workaround implemented in C++ (well mostly C).

#include "extfnapi.h"
#include <stdio.h>
#include <time.h>

// cl isDaylight.cpp /LD /IC:\sa17\sdk\include

#define DLL_FN __declspec(dllexport)

extern "C"
DLL_FN unsigned int extfn_use_new_api( )
{
    return( EXTFN_API_VERSION );
}

extern "C"
DLL_FN void isDaylightSavings( an_extfn_api *api, void *arg_handle )
{
    an_extfn_value      args[1];
    an_extfn_value      retval;
    time_t              secs;
    struct tm           tmbuf;
    int                 i;
    int                 isdaylight = -1;
    int                 msecs;
    char                sep;
    char                buf[33];

    for( i = 0; i < 1; i++ ) 
    {
        if( ! api->get_value( arg_handle, i+1, &args[i] ) ) break;

        if( args[0].type != DT_VARCHAR ) break;

        tmbuf.tm_wday = 0;
        tmbuf.tm_yday = 0;
        tmbuf.tm_isdst = -1; // force Daylight Savings Time determination

        sscanf( (const char *)args[0].data, "%d%c%d%c%d %d%c%d%c%d%c%d",
                &tmbuf.tm_year,
                &sep,
                &tmbuf.tm_mon,
                &sep,
                &tmbuf.tm_mday,
                &tmbuf.tm_hour,
                &sep,
                &tmbuf.tm_min,
                &sep,
                &tmbuf.tm_sec,
                &sep,
                &msecs );
        tmbuf.tm_year -= 1900;
        tmbuf.tm_mon  -= 1;
        secs = mktime( &tmbuf );
        localtime_s( &tmbuf, &secs );
        isdaylight = tmbuf.tm_isdst;
    }        
    retval.type = DT_INT;
    retval.data = (void*) &isdaylight;
    retval.piece_len = retval.len.total_len = (a_sql_uint32) sizeof( int );
    api->set_value( arg_handle, 0, &retval, 0 );
    return;
}

The SQL interface is (you'll have to change the path below):

CREATE OR REPLACE FUNCTION isDaylightSavings( IN datetimestr VARCHAR(32) )
RETURNS INT
EXTERNAL NAME 'isDaylightSavings@c:\\c\\isDaylight.dll' LANGUAGE C_ESQL64;

and the expected argument is a string, for example:

SELECT isDaylightSavings('2016-03-13 01:00:00.000000'), 
       isDaylightSavings('2016-03-13 03:00:00.000000'), 
       isDaylightSavings('2016-11-06 00:59:59.000000'), 
       isDaylightSavings('2016-11-06 01:00:00.000000');

Hi Louis-Joel,

first: Are you familiar with the thread deadlock (http://dcx.sap.com/index.html#sa160/en/dbusage/deadlock.html*d5e46598) phenomenon?
The usual ways to deal with this is to either reduce the number of blocked processes or (with the network server engine) to increase the number of server threads (aka "multiprogramming level"; -gn / -gna command line options).
Assuming that your call shouldn't last too long (what's the expected run time?), the error situation seen indicates that it is. Is the external function you call capable of multi- thread operation? If it isn't, your call may be stalled inside the external function, which will be propagated to the database engine. sa_conn_info or sa_conn_properties may return useful information to narrow this down.
Can you debug the external function on c# level?
Unfortunately, I can only ask more questions rather than provide an answer. HTH Anyway.

Volker Stöffler
DB-TecKnowledgy

Is there some reason to avoid using the technique shown in the SQL Anywhere 17 CLR samples folder?

C:\Users\Public\Documents\SQL Anywhere 17\Samples\SQLAnywhere\ExternalEnvironments\CLR

using Sap.Data.SQLAnywhere;
using Sap.SQLAnywhere.Server;