Proof of library error and application error on the developer side
I have a problem with a specific java client library. Here's the situation:
I have created a program that uses a library. The program is a class named "WorkerThread" that extends Thread. To begin with, I made a main class that contains only the main () function that starts the thread and nothing else. The worker uses the library to communicate with the server and get the results. The problem comes when I want to run 2 WorkerThreads at the same time. I first did this in the main class:
public class Main
{
public static void main(String args[])
{
new WorkerThread().start(); // 1st thread.
new WorkerThread().start(); // 2nd thread.
}
}
When I run this, both threads create irrational results and, moreover, some of the results that should be received by the 1st thread are accepted by the second instead.
If instead of the above, I only run two separate processes on one thread, then everything works fine.
also:
1. There is no static class or method in WorkerThread that could cause the problem. My application consists only of a workflow class and no static fields or methods 2. The library must be used in a multi-threaded environment. In my thread, I just create a new instance of the library class and then call methods on it. Nothing more.
My question is this: Without knowing any details of my implementation, is the above situation and facts enough to prove that there is a bug in the library and not in my program? Is it safe to assume that the library might, for example, use a static object or an object shared between the threads created by the library, which are indirectly shared by my 2 threads, and that is causing the problem? If not, in what hypothetical situation does the error arise from the working class code?
EDIT: I didn't say the library because I want to know if the above facts can answer my question regardless of the library, but the library is a bunny mq java client anyway. Each thread creates 1 connection and 2 channels and uses one to publish data and the other to get results.
EDIT 2: New fact: The problem seems to depend on the speed at which cells are sent in the queue. Avoiding a slower speed reduces incorrect results.
a source to share
I would guess that the problem is really in the library.
However, I would go further, select the library sources (or use a decompiler ) and see (perhaps using a debugger) what actually happens.
This way you both prove that the problem is not your code and cannot provide a valuable bug report.
a source to share
It's hard to guess without knowing what the library is doing. Even if the library was designed to be used in a multi-threaded environment, it might still take a few extra steps from the caller's code (i.e. you) to work properly. Imagine the library is a DB driver and your streams are something with the same database. If DB queries in streams are not grouped correctly in transactions with the correct isolation level, the results can be poor.
However, if the library is not supposed to work with some kind of shared resource, the chances that something is wrong with the library is high. In this case, it would be a good idea to create a minimal test application that will prove the wrong behavior and send it as a bug report to the library author.
a source to share
From your description, I would say that the problem is that the library opens one connection to the server and does nothing to propagate access from multiple worker threads. The reason one thread for each process model is running is because the server sees separate connections and would never think of mixing them up.
I don't know if you could name this error. As we don't know more about this library. You may be responsible for passing along an additional identifier that will be returned with each request to determine the correct target. Or it may be that the library expects you to properly order your interactions with it. In this case, you need to choose a suitable location to synchronize access.
a source to share
Your library may not be error-free, but thread-safe. I guess it's pretty hard to figure this out without the necessary documentation from the owner / provider of the library. Your library can be conditionally thread safe, which is according to Joshua Block -
As unconditionally thread safe, except that some methods require external synchronization to be safely used concurrently. Examples include collections returned by Collections.synchronized wrappers, whose iterators require external synchronization
a source to share
Without knowing the details of my implementation, is the above situation and enough facts to prove that the error is in the library and not in my Program?
No.
If not, in what hypothetical situation might arise in working class code?
The hypothetical situation is that your two threads are published and received from the same queues / topics, and you have ordering expectations of messages that neither your program (for example, through coordination between threads) nor the API / library guarantees guarantees.
a source to share