I have a webservice using RemObjects and a TROIndyHTTPServer using Delphi XE.
I don't know how to close manually the application without generate an access violation when
the clients are executing webservice operations. I don't know how to abort the
threads of the webservice that are executing the operations. If I close the application
sometimes the exe remains indefinitely executing and generates an access violation.
Thanks for the help
The Indy HTTP/TCP server (normally) allows clients to complete their current request when the server shuts down (by setting Active := False).
If long-running requests cause this problem, it should be possible to reproduce it and use the debugger to analyze the AV further.
Related
I'm having a GRPC service written in Go that wraps a C++ library.
Now, once in a while, the server hangs on a grpcurl based client call, while it succeeds at other times in sending out a response.
I have tried exporting the grpc traces variable and setting the verbosity to DEBUG, but they didn't seem to help.
I am following the ListFeatures() example in this tutorial: https://github.com/grpc/grpc/blob/v1.31.0/examples/cpp/route_guide/route_guide_client.cc
My server is in Java and my client application is in c++.
I have both the server and the client running locally. What I am observing is that my application crashes when I try to read the stream response via `reader->Read(&feature). I can verify that the server receives the api call and is sending responses back. I am also able to successfully hit the server from bloomRPC.
Any ideas why I can't receive responses in my c++ client application?
Much appreciated!
I had this problem when the context used to create the ClientReader fell out of scope. The context needs to be persistent while the ClientReader is in use.
Putting existing problems aside, I was moving to test the ability of the server to handle multiple requests in my server application in universal app. It appears that it cannot handle multiple requests as advertised in the documentation. (See the source file ServerTask.cpp and MainPage.xaml.cpp for the related code and the README for background information.)
In background i.e. suspended mode, subsequent requests end up with
WinRT information: The object identifier does not represent a valid object.
EDIT: Just run again and the background ServerTask is not executing at all. When ClientTask is triggered, the app is automatically woken up from Suspended state and netstat indicates that it is listening to the appropriate port but not responding to the requests.
While in the foreground mode, subsequent requests end up with
WinRT information: An existing connection was forcibly closed by the remote host.
which mean that I should not do
delete args->Socket;
after handling the request in MainPage::OnConnectionReceived. If I delete that line, it can handle 2-3 requests and still end up with the same exception. On the other hand, is it the right way to go, leaving open sockets?
How should it be implemented?
I have a question around biztalk and what happens when certain conditions around web service ports are met.
basically we have two applications - a main application (lets call it 'MainApplication') (containing the orchestration) and a web service application (lets call it 'MainApplicationWS'), where we expose a web service (created from biztalks web service tool) to take messages from wherever.
we have a testing tool which replays messages to the MainApplicationWS to simulate messages coming through from various external systems.
I have noticed that if we partial stop the MainApplicationWS application, and send messages through to the web service listed as a recieve location, nothing happens (obviously!) (also, the web service is still running, even though its been delisted as a recieve location). however, if i start up the MainApplicationWS again and bounce the host instances the messages are picked up from somewhere and played through to the orchestration and through to our application.
Im just a bit puzzled as to where its storing these messages while the MainApplicationWS is partially stopped. is the web service somehow hanging on to these? or does it still post through to the biztalk message box?
any clarification would be greatly appreciated :)
cheers,
adam
In short, I can't repeat your behaviour in Biztalk 2009. The closest to 'queueing' messages is if the orchestration is stopped but remains enlisted, such that messages are suspended resumable.
In long - I'm not quite sure what you mean by 'delisted as a receive location'. In Biztalk 2009:
Receive Locations can be enabled or disabled
Orchestrations can be stopped, and unenlisted
A Partial Stop on your BTS application disables receive ports and stops orchestrations (but doesn't unenlist them)
A full stop stops and unenlists orchestrations
The below is observed behaviour on BizTalk 2009 for a simple orchestration with a WCF Request/Response port, which receives a message, Maps the Send back to the same Port
The port is Direct Bound (MessageBox).
If the Isolated Host App Pool is disabled in IIS
A synchronous error is returned to the client - Standard IIS Error (503 Service Unavailable etc)
BizTalk receives no messages at all
If the BizTalk receive Location is disabled
WSDL: Syncrhonous error returned to the client - The Messaging Engine failed to register the adapter for "WCF-BasicHttp" for the receive location "xyz.svc". Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases
Service Call : The requested service, xyz.svc could not be activated. See the server's diagnostic trace logs for more information.
If the Orchestration is stopped, but not unenlisted
The received message is Suspended, resumable. The client times out (no response is issued).
If the orch is started and the message resumed, the message is then processed. The client will only get a successful reply if the orch start and the suspended message resume are done before the client's configured WS / WCF timeout.
If the Orchestration is unenlisted
The received message is Suspended, not resumable.
The client receives an error - The server was unable to process the request due to an internal error.
With the WCF CustomBinding it is also possible to listen directly on the relevant BizTalk ReceiveHost (i.e. no need for IIS at all to listen to BasicHTTP or WSHTTP, although we generally still use the Wizard generated svc in IIS solely for the hosting and publication of the WSDL. We then create a new WCF Custom receive location directly in BizTalk and point the client to this)
Hope this helps?
I have an application that sends requests to an out of proc COM server whom handles the requests and sends them back to the requesting application.
The client application is really in control of the start-stop of this Out-of-Proc COM server and determines its lifetime so to say.
Because this application has many hundreds of requests at any given time, it mostly has at least 4 of the same COM servers to handle these requests.
The problem is that sometimes this COM servers gets hung up handling a request, which is caught by the requesting application, whom kills the out of proc COM server. This however does not always happen.
What sometimes happens is that the client application requests a COM server kill, which results in the client releasing all references to the COM Server, but the COM server ends up just using 25% of the CPU and just never dies. It seems it just hangs and uses CPU constantly.
The client has mechanism to attempt to kill the COM Server process forcibly if it fails to die, however even that does not seem to work in the cases where the COM server gets into the CPU usage and just hangs.
Has anybody experienced something similar or has some advice on how one could resolve a situation like this?
You need to design all calls in the COM server in such way that they all end in some reasonably short time. Once a new call arrives from the client COM spawns a separate thread and dispatches a call onto that thread. There's no reliable way to interrupt the call - the call needs to end on itself (just return). You achieve this by designing your algorithm appropriately.