I wish for jOkHttpUtils2 to use a unique base temp folder.
Why?
Because without a unique base temp folder, multiple applications written in B4J that run on the same user account / OS / machine and are using HttpJob to make HTTP calls can cross access each other's temp folder or block each other's temp folder (used in processing the HTTP calls). I'm attaching a test server and test client to demonstrate the issue.
Here are some of the common issues that can occur:
A)
Both of the above are attempts of one process to access another process's temp folder created/managed by jOkHttpUtils2
B)
It gets even weirder. Apps can actually access and/or overwrite each other's information that is returned by jOkHttpUtils2.
For the A) and B) above, I ran the included spawnclients.cmd file and let it start 10 clients, for 10 seconds, with 10 milliseconds between each HTTP call, and not applying the fix. If you want to try this on your system, extract the attached file. Run the server in release mode and keep it running. Run the Client_NonUI once in release mode and kill the process. Then, in a command prompt, run the included spawnclients.cmd file. The batch file will ask for the number of clients to create, for how many seconds to run, how many milliseconds to separate each HTTP call, and if a fix should be applied (see below).
Right now, the solution is to set up a unique temporary folder for each application that uses jOkHttpUtils2. This is accomplished by setting the
to a unique value.
One way this can be accomplished is by using @Erel's GUID code (https://www.b4x.com/android/forum/threads/b4x-guid.99529/):
This code needs to be placed before the first HTTP call.
This method is used in the test client and can be activated using the spawnclients.cmd batch file by answering the "Apply TempFolder fix?" with Y.
Notes:
0) This is a client only issue. The server returns the correct responses. It's the client processing the returned values that is messing up. And with client I mean the underlying client HTTP library that is implemented by jOkHttpUtils2.
1) This only applies the B4J code section of the library that deals with the TempFolder.
2) It could also affect the jServer portion, even using/activating the thread safe code path of the library, if more than one jServer application is running on the same account / OS / machine (untested).
3) I initially bumped into this, and so did @Diceman back in 2019 (see https://www.b4x.com/android/forum/t...session-id-in-jrdc2-client.108642/post-686343), but I did not spend any more time investigating, since the issue only seemed to occur during testing. @Diceman seemed to have a good guess as to what may be happening then (https://www.b4x.com/android/forum/t...session-id-in-jrdc2-client.108642/post-686351)
Why?
Because without a unique base temp folder, multiple applications written in B4J that run on the same user account / OS / machine and are using HttpJob to make HTTP calls can cross access each other's temp folder or block each other's temp folder (used in processing the HTTP calls). I'm attaching a test server and test client to demonstrate the issue.
Here are some of the common issues that can occur:
A)
Both of the above are attempts of one process to access another process's temp folder created/managed by jOkHttpUtils2
B)
It gets even weirder. Apps can actually access and/or overwrite each other's information that is returned by jOkHttpUtils2.
For the above output, I'm sending Veronica to the server and the server replies with Hello Veronica, and jOkHttpUtils2 writes the answer out to a file in the temporary directory it has created for that session. But on occasion, the current process is accessing some other processes temp folder (Hello Tootie) or another process overwrote the data of the current process (Hello Trixieca, where Hello Trixie overwrites Hello Veronica). On other occasions, I'm not sure if the process is accessing another temp folder or if the currents temp folder was manipulated by another process (where the message is blank). This is on top of the "process cannot access the file because it is being used by another process" issue.
For the A) and B) above, I ran the included spawnclients.cmd file and let it start 10 clients, for 10 seconds, with 10 milliseconds between each HTTP call, and not applying the fix. If you want to try this on your system, extract the attached file. Run the server in release mode and keep it running. Run the Client_NonUI once in release mode and kill the process. Then, in a command prompt, run the included spawnclients.cmd file. The batch file will ask for the number of clients to create, for how many seconds to run, how many milliseconds to separate each HTTP call, and if a fix should be applied (see below).
Right now, the solution is to set up a unique temporary folder for each application that uses jOkHttpUtils2. This is accomplished by setting the
B4X:
HttpUtils2Service.TempFolderOne way this can be accomplished is by using @Erel's GUID code (https://www.b4x.com/android/forum/threads/b4x-guid.99529/):
B4X:
Dim guidFolder As String = GUID
File.MakeDir(File.DirTemp, guidFolder)
HttpUtils2Service.Service_Create
HttpUtils2Service.TempFolder = File.Combine(File.DirTemp, guidFolder)This method is used in the test client and can be activated using the spawnclients.cmd batch file by answering the "Apply TempFolder fix?" with Y.
Notes:
0) This is a client only issue. The server returns the correct responses. It's the client processing the returned values that is messing up. And with client I mean the underlying client HTTP library that is implemented by jOkHttpUtils2.
1) This only applies the B4J code section of the library that deals with the TempFolder.
2) It could also affect the jServer portion, even using/activating the thread safe code path of the library, if more than one jServer application is running on the same account / OS / machine (untested).
3) I initially bumped into this, and so did @Diceman back in 2019 (see https://www.b4x.com/android/forum/t...session-id-in-jrdc2-client.108642/post-686343), but I did not spend any more time investigating, since the issue only seemed to occur during testing. @Diceman seemed to have a good guess as to what may be happening then (https://www.b4x.com/android/forum/t...session-id-in-jrdc2-client.108642/post-686351)
