When I use Armeria, I have 3 services:
Service A calls Service B and Service C.
Should I call B and C's blocking stub in A's blockingTaskExecutor or some other better way?
Let me assume that you're asking about gRPC. In asynchronous frameworks like Armeria, it is recommended to use a non-blocking stub to make a call, so that there are no blocking calls and thus the calls to other services (Service B and C in your case) are all done in an event loop thread. This yields potentially higher performance thanks to less amount of context switching and more robustness when the other services are not responsive enough.
You can use the default stub generated by gRPC-Java to do that, but the end result may be more complex than necessary, so I'd recommend using a third party stub generators such as reactive-grpc, which provides the integration with RxJava and Project Reactor.
If you are using Kotlin, you might want to give grpc-kotlin a try, but please keep in mind that it's at the early stage.
Related
I have an existing C/C++ application that communicates with other applications/systems through several interfaces (TCP, DB, shared memory). I would like to run the application once with the real environment and "record" all function calls and their return values (or changes to the buffers passed as parameters). I would record only the calls related with external interfaces (TCP, DB) with a "spy". Then I could run the application again but using "fake" functions that should return the previous recorded values. This way I could "replay" an execution, and check if the results match the original execution.
One important feature is to mock the time functions as well (sleep, time, GetLocalTime), because (for example) the calls to the DB may have the current date or time in the selects. It would be even better to be able to "replay" all the calls faster than the original execution (one day of execution could be replayed in a few minutes). For example a call to sleep(1000) should return without waiting, but successive calls to GetLocalTime should return 1 second more. This should take into account that other threads should have consistent values for the time (for example the library should allow 1 call to sleep(1000) for one thread and 10 calls to sleep(100) in another thread).
Ideally it shouldn't require a lot of changes or refactoring to the application, just redefining the calls to time functions as well as the calls to the libraries of the external interfaces (DB, TCP).
I would like to know if there exists some library or framework that implements these features or what could be a good starting point.
I have implemented several times solutions for similar problems, but for very simple modules, for example mocking a TCP connection to test a protocol implementation, but I feel like reinventing the wheel each time, and these simple solutions wouldn't scale well with more threads or interactions with more interfaces.
Since you mention that your application is C/C++, I will assume you have the ability to use C frameworks. I will talk about CMock and Unity in this answer. If object oriented principles are more prevalent in your task, then you can take a look at googlemock which is similar to CMock, but developed for C++ and accounts for classes.
--
CMock in combination with Unity may provide a framework for your testing needs.
CMock provides you the ability to easily mock public interfaces. For example, if you had the following trivial code to test:
void sendPacket(char * packet, int packetLen, int tcpSocket)
{
if (packet)
{
send(tcpSocket, packet, packetLen, 0);
}
}
You could use CMock to create a mock of the send call. This would allow you to verify the parameters passed to send, and thus verify content in buffers. You would also be able to verify the size returned by send. CMock's ExpectAndReturn variant of the mocked send function would allow you to perform these two verifications.
CMock also allows you to provide callbacks for mocked functions through the StubWithCallback variant. StubWithCallback will allow you to manually verify each call, in addition to doing special checks. You would be able to utilize StubWithCallback to record number of times a function is called, or almost anything else you can imagine. You would also be able to use the StubWithCallback for your needs with time, sleep, etc. You can mock individual calls with different stub callbacks-- some threads will start with a stub sleep callback that immediately returns, while threads you specify for testing can use a stub sleep callback that performs the full sleep.
You can find more information on CMock here: http://throwtheswitch.org/white-papers/cmock-intro.html
I'm wondering how asynchronous EJB methods are scheduled onto the underlying plateform (SMP/NUMA plateform for example) ?
Can anyone describe the scheduling middleware (I'm not familiar with EJB).
EJB as a spec doesn't say how this should be exactly implemented, giving implementations the free hand to choose how to do this.
That said, the implementations I've seen simply use a thread pool. It functions pretty much like an executor service does in Java SE. A call to an #Asynchronous methods results in a task being put in a queue, which is serviced by said thread pool.
SMP/NUMA properties are not directly influenced by EJB, but depend on how the underlying operating system handles threads within a single process.
I have a Web Service (in java) on a Oracle WebLogic 10.3 that does all kinds of database queries. Recently I started stress tests. It passed the repetition tests (invoke the WS several 1000 times serially) but problems become to arise when concurrency testing began. Making as much as 2 concurrent calls results in errors. When doing proper tests the results looked like the WS wasn't able to handle concurrent calls at all, which obviously should not be the case. Error included null pointer exceptions, closed connections or prepared statements, etc. I am bit stumped at this specially since I was unable to find any kind of configuration options that could effect this but then again my knowledge of the WLS is quite limited.
Thanks for any suggestions in advance.
The answer you marked as correct is totally wrong.
The webservice methods should not be made in order to be thread safe.
Webservice implenmtation of weblogic are multithreaded.
It's like for the servlets
"Servlets are multithreaded. Servlet-based applications have to recognize and handle this appropriately. If large sections of code are synchronized, an application effectively becomes single threaded, and throughput decreases dramatically."
http://www.ibm.com/developerworks/websphere/library/bestpractices/avoiding_or_minimizing_synchronization_in_servlets.html
The code inside the WS you might want to synchronize depending what you do.
Does it make sense to synchronize web-service method?
Just so there is a clear answer.
When there are several concurrent calls to a given Web Service (in this case SOAP/JAX-WS was used) on WLS, the same object is used (no pooling or queues are used), therefore the implementation must be thread safe.
EDIT:
To clarify:
Assume there is a class attribute in the WebService implementation class generated by JDeveloper. If you modify this attribute in your web method (and then use it) it will cause synchronization problems when the method is called (ie WS is called) concurrently. When I first started creating web services I though the whole WebService object was created anew for each WS call but this does not seem to be the case.
We have a project with a core functionality implemented using ACE, and architectured around it's Reactor. We want to add a small web interface using Wt.
So the question is, is it possible to replace the main loop of the wt interface with the ace reactor?
The only bad idea that comes to my mind is having a fast timer on the Reactor side which somehow invokes the wt part.
The other way round, the reactor can be run 'tick by tick' using it's handle_events method but I can't find an equivalent on the wt side.
note:
The main concern behind this question is about threads. We don't have threads, the code is not thread safe, and it would be a lot simpler for us if the HMI could be running on the same thread as the rest of the application. But having 2 blocking calls, one to theReactor->run_reactor_event_loop(), and the other to Wt::WRun() is a problem!
That can work with some modifications to the Wt connector. Wt can be compiled without thread support, so in the connector there must be a select() loop of some kind. What you need is the ability to hook into that loop with a timer.
Are you talking about the http connector? That's implemented with boost.asio, so an asio deadline_timer with an async_wait that executes theReactor->run_reactor_event_loop() may be all you need. Maybe you may even find a different idea when you dive into the boost.asio documentation...
It could even work without modifications to the connector. It's not documented, but Server::instance()->service() (in src/http/Server.h) returns you the asio service that you need to implement this.
More info -> Wt's mailing list?
Does ODBC support asynchronous calls? If it does, then can you tell me about any reference materials?
My preferred language is C++.
This MSDN article could be a starting point for you: Executing Statements ODBC:
Asynchronous Execution
From the article:
ODBC 3.8 in the Windows 7 SDK introduced asynchronous execution on connection-related operations ... an application determined that the asynchronous operation was complete using the polling method. Beginning in the Windows 8 SDK, you can determine that an asynchronous operation is complete using the notification method.
I've wanted to know the exact same thing. An obvious workaround is to maintain a pool of threads that each perform synchronous ODBC calls and are signalled (and signal back) asynchronously.
Typically it seems like such things are implemented at another abstraction level of an application, or you roll your own. Just about anything that involves a blockable "open" action can spawn a thread for the purpose of managing the open and raising a signal or setting a flag somewhere globally when it happens.
Some frameworks are pretty good about offering both flavors. Flex comes to mind, where it's helpful for it to play the tricks with the single browser/javascript/swf thread.
Asynchronous ODBC functions is feature provided by ODBC driver.
Pre ODBC3.8 only statement related calls could be async-enabled. Starting ODBC3.8 connection related function calls can also be made async-enabled.
Of course we can implement any missing functionality at applications side but having it implemented at driver makes things less painful on application side.
I am looking for a comprehensive list of driver which clearly states if a driver supports async calls out-of-the-box. Please point to me to such a list if anyone is aware of it.