New versions of Adlink Edge SDK are released on a regular basis. This page lists all the known issues for Adlink Edge SDK V1
You may also want to read the following:
Edge SDK Known Issues
|THINGAPI-1037||FlowIdFilters not working on Purged samples
A read(), read_next() or data-available listener may return purged samples with flow id's that do not match the configured 'flowIdFilters' property of the Thing's input.
Workaround: You must filter such purged samples manually. Each such sample will have the following characteristics: a) the flow-state will be PURGED; b) if the sample is IOT_NVP_SEQ data, there will be no values in the returned sequence; c) if the sample is PROTOBUF data, then VDataSample::hasData() will return false.
|THINGAPI-623||A Python Listener class defining a constructor may cause a Segmentation Fault/Access Violation
A Python Listener class that defines a constructor (that is, a __init__ method) must call the super class's __init__ method, otherwise a Segmentation Fault/Access Violation will occur when a listener instance is added via a call to one of the Python API's add_listener methods.
Workaround: See the Python API User's Guide for an example of a well formed listener class with a constructor.
|THINGAPI-775||Security Composer on Debian 9 does not start when using default Debian OpenSSL libraries
In this release, Security Compose dynamically links to OpenSSL 1.0.2 LTS libraries. Previous releases used statically linked OpenSSL v1.0.2o. By dynamically linking OpenSSL libraries, customers may incorporate any OpenSSL security updates by downloading, building and installing the latest Openssl 1.0.2 release. However, on Debian 9, the default Debian-provided link libraries are named inconsistently with then OpenSSL libraries create from openssl.org source code. Debian names the libraries libssl.so.1.0.2 and libcrypto.so.1.0.2 while libraries built from OpenSSL source code have the names libssl.so.1.0.0 and libcrypto.so.1.0.0. The Security Composer links against the latter, and, on Debian 9, will not start, producing an error such as:
/opt/ADLINK/EdgeSDK/1.1.1/tools/securitycomposer: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
Customer's can resolve this issue in one of two ways:
make symbolic links to the 1.0.2 Debian libraries:
sudo ln -s /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
sudo ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
download, build and install the latest OpenSSL 1.0.2 source. See the Release Highlights document, issue THINGAPI-718 for more information on updating OpenSSL.
|THINGAPI-438||Control-C not received by Python applications during blocking read/read_next
During a blocking call to Thing.readIotNvp, Thing.readNextIotNvp, Selector.readIotNvp and Selector.readNextIotNvp, any Ctrl-C interrupt will not be received by the Python engine.
|THINGAPI-533||Excessive cpu-load for ThingAPI read-operations on large (e.g. multi-megabyte video-)samples
When applicable: if cpu-monitoring tools such as 'top' shows about equal amount of system-time and user-time for read-operations
Work-around: to reduce the cpu-load create 2 environment variables with appropriate values:
export MALLOC_TRIM_THRESHOLD_=-1 (which causes 'mmap' to be used rather than malloc for large memory-chunks
export MALLOC_MMAP_THRESHOLD_=4000000 (a value greater than the sample/video-size)
Consequence: increased memory-usage of a process which decreases the amount of available RAM for all other processes
|THINGAPI-766||Python API treats IOT_INT8 as a Python string
In Python, a data type of IOT_INT8 gets incorrectly converted into a python String. It is intended to be an integer value with range -256 through 255.
|THINGAPI-880||NodeJS API is incomplete
The NodeJS API shipped with earlier releases of EdgeSDK remains incomplete. In particular:
* the NodeJS API contains no support for listeners.
* Examples that rely on listeners are not available.
* No User's Guide is available.
|THINGAPI-920||Python 3.8 support not available on Windows
Python 3.8 has changed how it loads DLLs referenced from language extensions such as the EdgeSDK. This was discovered late in the development of EdgeSDK 1.4 and could not be fixed within the remaining release time frame. A future release will add Python 3.8 support for Windows.
|THINGAPI-933||Protobuf examples without 'CMAKE_BUILD_TYPE=Release' on Windows
Protobuf Examples configured on Windows without '-D CMAKE_BUILD_TYPE=Release' appear to work. However during a build, errors appear: "error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug'".
Work around: Add "-D CMAKE_BUILD_TYPE=Release" to the cmake command.
|THINGAPI-934||Limitation: Pre-1.4 applications cannot fully inspect Protobuf TagGroups
Applications such as the 'thingbrowser' application inspect all TagGroups found on a DataRiver, and provide information on their contents by making use of TagGroup methods such as getToplevelType(), getTopLevelTypename(), getTypeDefinitions() and getType(). Pre-1.4 versions of such applications will 'see' Protobuf TagGroups, but they will not be able to find information their content.
Migration to 1.4: When such applications are migrated to 1.4, developers must examine their use of the above methods. On Protobuf TagGroups, they will now throw a C++ exception. Migrated code should first examine the result of the new method 'TagGroup::getWireFormat()' to determine whether the Tag Group is the 'familiar' NVP_SEQ-format or the new PROTOBUF-format. New TagGroup methods are provided in 1.4 to examine the contents of a protobuf tag group. See the C++ User's Guide for details.
|THINGAPI-937||Windows: C++ Examples cannot use the default Visual Studio 'generator'
On Windows, the C++ examples cannot be configured without explicitly specifying -G "NMake Makefiles" on the command line. Without this option, CMake attempts to use the default Visual Studio generator. However, some of the C++ examples cannot be configured this way.
Work-around: add the option -G "NMake Makefiles" to the CMake command line, and then use nmake to build. This process is described in the examples README file.
|THINGAPI-940||Windows+Protobuf: C4275 and C4800 Warnings in header files
EgdeSDK Protobuf applications compile with a C4275 and C4800 warnings. These can safely be ignored. Google documents that C4800 is unavoidable ADLINK is researching how C4275 can be addressed.
Work-around: These warnings can safely be ignored.
|THINGAPI-1064||Windows: json2proto does not work.
The EdgeSDK tool 'json2proto' does not launch correctly on Windows. ADLINK is investigating this, and will provide a fix in an upcoming release.
Operating System/Platform Related Issues
- As of ADLINK Edge SDK version 1.0.1, Ubuntu 14.04 is not supported.
- As of ADLINK Edge SDK version 1.1, Ubuntu 18.04 support has been added.
- As of ADLINK Edge SDK version 1.3, Ubuntu 18.04 AArch64 support has been added.
- As of ADLINK Edge SDK version 1.4, Python 3.8 on Linux has been added.