I found that Quarkus Server binds io.quarkus.grpc.runtime.supports.blocking.BlockingServerInterceptor for each gRPC service with the #Blocking annotation before it starts.
If some global interceptors (with #GlobalInterceptor) set the Context value will not work. The Context will still be empty in the actual rpc method handler.
Is it a normal phenomenon because Context should be placed after BlockingServerInterceptor's vert.x executeBlocking? There are some associated issues: https://github.com/quarkusio/quarkus/issues/14665, https://github.com/quarkusio/quarkus/issues/13959.
Finaly I replace the #GlobalInterceptor with #RegisterInterceptor(MyInterceptor.class) , everything is to be ok that seems to prove my point.
I don't particularly understand the technical details of it, and these are what I got from trying and Debug. I've been using Spring and Micronaut before.
Related
I am using axon distributed command bus autoconfiguration using spring cloud and eureka
I observed all the required beans are getting created./member-capabilities is also exchanging the command information with other services and it is I can see this mapping exists in request mappings as well. Now when the command is being sent from another service by internally making a post-call to /spring-command-bus-connector/command endpoint
I am getting 404.
I checked that SpringHttpCommandBusConnector's bean is loaded in application context
I tried adding a component scan as well
Also tried registering this mapping manually with dispatcher servlet still no luck
This is a more general Spring question that isn't necessarily a Spring Social Facebook issue; however, I'm asking the question here because it is not clear to me how Spring is managing the Facebook reference that is passed into the controller constructor.
I'm running this in a Spring boot app, version 1.5.3.RELEASE.
I've googled around and have read many things about how scoped-proxies work and whether the Controller is a singleton and such; but something is still not clear to me with this particular use case. My concern is over whether or not two or more simultaneous request will cause one reference to interfere with the other. It seems to me that there will be a conflict regardless of the scoped-proxy solution. To address this concern, I injected a Facebook and ConnectionRepository object into the controller constructor wrapped in a Provider class.
#Inject
public CopyGroupController(
Provider<Facebook> facebook,
Provider<ConnectionRepository> connectionRepository) {
It appears to have injected meaningful data; but when attempting to run this code:
#PostConstruct
public void init() {
ConnectionRepository repo = connectionRepository.get();
this.userManager.createOrGetUser(
repo.findPrimaryConnection(Facebook.class));
}
This failure occurs:
java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
This creates more uncertainty because I thought the FacebookTemplate was being managed as a request or session scoped bean and that it would Inject as a Provider so the object would reside on ThreadLocale; so two or more concurrent requests will not conflict. Passing a request scoped bean in a controller singleton constructor doesn't make any sense to me either. So I'm puzzled as to why a user specific reference would even be passed into a constructor that should only be called once.
I've tried setting breakpoints in the constructor to verify whether or not there is a conflict; but The same error as above would occur. Could someone please explain to me whether or not this is an issue and if so; how is the best, most modern way to resolve it.
Any assistance would be greatly appreciated.
Thank you in advance.
You have to register a RequestContextListener
Here you can find the problem detail
And here you can get how to add in using spring boot
I want to know what will happen when there are no ejbs available in the pool and a client is trying to access a web service which uses the ejb.
We are receiving a NPE at the line where the ejb instance is used to call a method. Unfortunately I do not have access to the logs right now and I am trying to figure out what is wrong. So I am thinking in all possible ways and this question spawned in my head.
Can anyone please tell me?
What I think is, the web service will not be initialized until an ejb instance is available in the pool. So In this case the request will be queued and after sometime the client will receive a timeout error or appropriate message. Am I right?
P.S
BTW, if it makes any difference, I am injecting the ejb using #EJB annotation.
If you use a reference to a SLSB the initialization is just a proxy, no instance is needed.
At runtime the invocation try to get an instance from the pool, if there are all instances busy it will be blocked for a while (5sec by default) and throw an Exception in case of timeout, otherwise just continue.
If you get a NPE this seems to me a different issue where you can't get a reference.
A stateful bean is different, but I think you don't use that.
I think it should be the same no matter which container you use.
I am using SimpleIOC from mvvm-light along with the ViewModelLocator class / pattern provided to provide ViewModels with the correct dependencies injected. The problem I have is that the dependency that is being injected in to my ViewModel is a WCF ClientBase instance that can "break" if it encounters a fault. One example would be if the service it is trying to connect to doesn't exist it will cause a fault. I don't know how to handle this properly. Once the ClientBase derived class is in a fault state it will no longer work. The ViewModelLocator keeps injecting this broken instance of my service proxy so even if this service becomes accessible the proxy will error out when used because it can't recover from a faulted state. How should I deal with this?
I was able to figure this one out on my own. The answer was to create a wrapper around the ClientBase proxy class so that when a call created a fault, the wrapper class could properly handle the exception yet still be ready to handle the next call.
I'm looking for an example showing how can I configure my CXF project, so that I can call a service method asynchronously; meaning my invocation in the client side doesn't block for the response and when the response is ready the logic will be done. I'm very thankful if somebody can help me
Best
The simplest way is to use #Oneway annotation on the server side. CXF will handle the request on the server side in a separate thread, so the client won't be blocked and will return immediately after receiving 200 response code and empty response body.
Of course in this case you cannot receive any response (by definition of request-only SOAP operation), which is not an option for you. Unfortunately you're need to implement this by hand using thread pool and future tasks. Fortunately this is very simple since Java 5, start by studying ExecutorService API.