Using node-rfc on web workers

[Berdmanfolk]

Hello @bsrdjan!
Question about web workers.
Due to the fact that I experience the effect of freezing the application interface when calling FM modul that produce a large number of records, I decided to use web workers to solve this problem.
But when setting up on the web workrer encountered another problem. I was able to open the client(client.open()) in the web worker, but when executing the client.invoke(), the application crashed when the data was received.
Moreover, when setting a breakpoint in the FM abap code, I see that the connection is happening and the data is being collected, but at the moment of sending everything collapses.
Have you had experience using node-rfc on web workers?

[bsrdjan]

I used node worker threads, not web workers. Do you mean these web workers nodejs/node#43583 ?

It looks like violation of RFC SDK threading rules, described on pg. 34 of SAP NetWeaver RFC SDK 7.50 Programming Guide

This seems to be an appropriate point to say a few words about thread-safety. Of course, the NW RFC Library is thread-safe in the sense that you can call any API simultaneously in different threads. However, that does not mean the application can also use the same “object”, like a connection or a table, in several threads at the same time and expect something reasonable to happen. Here are two typical examples, that were implemented in practice:
* A connection handle is shared between two threads and both of them are trying to execute a function call at the same time. Common sense already indicates that this can lead to no good. This would be similar to opening one single HTTP connection to an HTTP server and then sending two different GET or POST requests over that connection at the same time from two parallel threads. Even if the HTTP server would somehow be able to correctly recognize and serve both requests, there would be no guarantee as to which of the two threads receives which HTTP response... Most probably both threads would end up reading parts of each other’s responses.
As is the case with any kind of connection-based network programming (like HTTP connections, ODBC connections, etc.) an RFC_CONNECTION_HANDLE must not be shared between different threads.
* A table handle is shared across two threads, and both threads start filling rows into that table. Even if the insert operations were synchronized, it would not help: the end result would still be a completely intermingled sequence of thread A’s and thread B’s data, depending mainly on how the CPU distributes the time-slots between the two threads.
Therefore, for best performance, the NW RFC API does not synchronize any table operations and relies on table handles not being shared between two threads.
Consequently, as a general rule, all NW RFC library objects that are represented by a HANDLE, must not be shared across threads, the exception being immutable objects like metadata descriptions.