I have a SOAP WS which I access through PHP's SoapClient (wrapped with Zend Framework's Soap Client). The webservice runs through https, and the calls take quite some time (a few minutes each).
I am making 4 calls, one after another through the same instance of SoapClient. However, after some time running, and at a random point (not allways on the same method call) I see the following error:
Warning: SoapClient::__doRequest(): SSL: Broken pipe in pathtomyfile
I still have no idea why this happened, but I've got some extra insight and a workaround.
The issue arises when, after a SOAP call that took really long to run, I try to use the same connection for another request. The first one will succeed, but upon the new call, the error raises.
This means, that as long as you don't NEED the connection to be same (which is usually the case on SOAP web services), you can just reset the connection between calls. Not the most efficient use of resources, but will work flawlessly.
I found that adding the
'keep_alive' => false
option to
new SoapClient($url, $options)
solved the issue for me.
There is a related bug report here but very little documentation about it apart from that: https://bugs.php.net/bug.php?id=60329
Related
For some client side procedures, I implement remote logging to log the calling of the procedure. The log is printed several times with different thread id, even though the procedure is only called once. Some rpc requests are sent to the sever a few times which causes some database session problem. Is it normal? Is there anyway to avoid it?
Thanks
This is not normal, and suggests there is a bug on your client causing it to send the same call more than once. Try adding logging on the client where you invoke the RPC call, and possibly add breakpoints to confirm why it is being called twice.
My best guess with no other information would be that you have more than one event handler wired up to the same button, or something like that.
--
More specifically, your servlet container starts multiple threads to handle incoming requests - if two requests come in close succession, they might be handled by different threads.
As you noted, this can cause problems with a database, where two simultaneous calls could be made to change the same data, especially if you have some checks to ensure that a servlet call cannot accidentally overwrite some newer data. This is almost certainly a bug in your client code, and debugging it should start there.
As far as I understand, in a CQRS-oriented API exposed through a RESTful HTTP API the commands and queries are expressed through the HTTP verbs, the commands being asynchronous and usually returning 202 Accepted, while the queries get the information you need. Someone asked me the following: supposing they want to change some information, they would have to send a command and then a query to get the resulting state, why to force the client to make two HTTP requests when you can simply return what they want in the HTTP response of the command in a single HTTP request?
We had a long conversation in DDD/CRQS mailing list a couple of months ago (link). One part of the discussion was "one way command" and this is what I think you are assuming. You can find out that Greg Young is opposed to this pattern. A command changes the state and therefore prone to failure, meaning it can fail and you should support this. REST API with POST/PUT requests provide perfect support for this but you should not just return 202 Accepted but really give some meaningful result back. Some people return 200 success and also some object that contains a URL to retrieve the newly created or updated object. If the command handler fails, it should return 500 and an error message.
Having fire-and-forget commands is dangerous since it can give a consumer wrong ideas about the system state.
My team also recently had a very heated discussion about this very thing. Thanks for posting the question. I have usually been the defender of the "fire and forget" style commands. My position has always been that, if you want to be able to move to an async command dispatcher some day, then you cannot allow commands to return anything. Doing so would kill your chances since an async command doesn't have much of a way to return a value to the original http call. Some of my team mates really challenged this thinking so I had to start thinking if my position was really worth defending.
Then I realized that async or not async is JUST an implementation detail. This led me to realize that, using our frameworks, we can build in middleware to accomplish the same thing our async dispatchers are doing. So, we can build our command handlers the way we want to, returning what ever makes sense, and then let the framework around the handlers deal with the "when".
Example: My team is building an http API in node.js currently. Instead of requiring a POST command to only return a blank 202, we are returning details of the newly created resource. This helps the front-end move on. The front-end POSTS a widget and opens a channel to the server's web socket using the same command as the channel name. the request comes to the server and is intercepted by middleware which passes it to the service bus. When the command is eventually processed synchronously by the handler, it "returns" via the web socket and the front-end is happy. The middleware can be disabled easily, making the API synchronous again.
There is nothing stopping you from doing that. If you execute your commands synchronously and create your projections synchronously, then it will be easy for you to just make a query directly after executing the command and returning that result. If you do this asynchronously via the rest-api, then you have no query result to send back. If you do it asynchronously within your system, then you can wait for the projection to be created and then send the response to the client.
The important thing is that you separate your write and read models in classic CQRS style. That does not mean that you cannot do a read in the same request as you do the command. Sure, you can send a command to the server and then with SignalR (or something) wait for a notification that your projection have been created/updated. I do not see a problem with waiting for the projection to be created on the server side instead for on the client.
How you do this will affect you infrastructure and error handling. Also, you will hold the HTTP request open for a longer time if you return the result at once.
I've got a Backbone web application that talks to a RESTful PHP server. For PUT and POST it matters in which order the requests arrive at the server and for GET it matters in which order the responses arrive at the client.
The web application does not need to be used concurrently by multiple users, but what might happen is that the user changes its name twice really fast. Then the order in which the server processes PUT /name/Ann and PUT /name/Bea determines whether the name is set to Ann or Bea.
Backbone.Safesync and Backbone.Sync.AjaxQueue are two libraries that try to solve this problem. Doesn't Safesync only solve the problem with GET? Sync.AjaxQueue is outdated, but might serve as inspiration to implement a custom queued sync function. Making sync synchronous would solve the problem. If a request is only sent after the previous response is received, then only one request is processed at a time.
Any advice on how to proceed?
BTW: I don't think using PATCH requests would solve anything, because in my example the same attribute is changed twice.
There's a few ways to solve this, here's two:
add a timestamp to all requests, store it in the DB as "modified" and let the server check whether the timestamp of the new request is later than the one in the DB in order to be valid
use Promises to delay the second request from being made before the first one is responded on, there's a promise/deferred mechanism built into jquery, but you can also use a 3rd party one, for instance Q or when
If you can afford the delay, an easy approach is to set the async option to false when you call whatever method you're calling that results in the Backbone.sync. For example, in the appropriate model(s) simply override the default sync method to include the additional option.
That is "After and only After" an Exception since I've been told to get it up front is a performance hit we don't want because that would be for each and every call rather than just for an Exception. Makes sense of course but I sure don't see how it can be done AFTER an Exception.
Use case goes like this: Some guys, perhaps bad guys, send us some bad SOAP and the dispatcher chucks out a SaajSoapEnvelopeException. How do I handle this gracefully?
So far what I have is an extension of MessageDispatcherServlet with an override of the doService() method. The web.xml file has been updated to show this Dispatcher for Spring's config. Within this override, surround the call to the super method with a try/catch and you catch the Exception but the problem here is that the stream for the HttpServletRequest is already closed, so you can't get the SOAP from here, AFIK.
Another problem is that I can't get a marshaller to wire in here. I have Java faults generated from our WSDL I would like to use but I think there is a problem with wiring marshallers in a non-endpoint class. Perhaps something about the namespace? I probably need to read up on how these work.
Bottum line: Is it possible to get the SOAP after an Exception or is it possible to predict that there will be an Exception so that I can grab it up front? Also, how can I get a fault marshaller into this Dispatcher or will I have to BS up a text version of the fault?
I'm fairly new to Web Services and what I know so far is mostly CXF. So far, I'm not much impressed with Spring WS. They have a long ways to go yet, IMHO. The fact that I can't get my WSDL from the service due to a known bug having to do with XSD references in WSDL not getting properly renamed to match the bean, is particularly annoying.
Have you tried a EndpointExceptionResolver?
For instance, I have used one to catch and translate authentication exceptions.
You'll probably need an EndpointInterceptor as well to wrap the exception resolver.
i need help with logging Zend Framewrok application ( version 1.11 ), every request..
I need to know time of beinning request and time of executing request. Each request i would like to save into database, but i'm not sure, where i would catch these informations.
Beggining of request i can probably catch in bootstrap.php via some _init method. But in which place should I cach information about end of execution request, if i need to be connected into database? In addition i'm using $this->_redirector->gotoSimpleAndExit() in my controllers and i need count with that case - no view is rendered and request is finished simply by exit() function.
I would like to write log information only once per request.
Thank's for help!
Registration of shut down function helped very well.
http://php.net/manual/en/function.register-shutdown-function.php
I created custom logger (singleton pattern), that i'm calling in bootstrap.. since php 5.4 is available $_SERVER['REQUEST_TIME_FLOAT']. Logger register his method as shutdown function in constructor and also call it in his destructor. Multiple calling of shutdown function is prevented.
This solution is working even if exit() function is called.
For one of my projects, I'm putting the "end of execution" logging code in my layout script. It's supposed to be one of the "last" things to be executed.
I'm not using redirections for this project, though. So, I'm not sure how it should be extended to consider your "gotoSimpleAndExit()" case.
Hope that helps,