On a WCF rest service I am dealing with streams. In a service method I am uploading a stream in a data contract which works fine. And on service side I process the stream and its position is now at eof. After doing that I need to set its position to 0 again therefore I can save it there. But it throws the exception:
Specified method is not supported.
Does it mean I can't process a stream more then once? If it does I will need a workaround for that :/ and only solution pops into my mind is sending the stream two times so I can process it separately, but it is not good since I would have to upload it twice.
Any help would be appreciated.
Funny that I found my own solution :) first I saved the stream, then read it from that path for further processes over that stream. its interesting that finding the solution didn't require more detailed, technical information but a change of logical approach.
Related
I'm developing Soap service for Sonos. The service is partially accepted BY SONOS. But still having the problems that some of the mp3 tracks lead to "unable to play track not encoded correctly" when making skip (forward or backward) during playing the track (inside the track). I have compared encoding procedure for 'good' and 'bad' tracks and I don't see any real reason that part of them doesn't make skip inside the track. I will appreciate very much any hint related to this issue.
Best regards,
Krzys
Are you attempting to use HLS? Can you provide any more information on the calls and responses that you are sending or on the exact text of the error messaging you are seeing?
I'm still trying to master Twisted while in the midst of finishing an application that uses it.
My question is:
My application uses LineReceiver.sendLine to send messages from a Twisted TCP server.
I would like to know if the sendLine succeeded.
I gather that I need to somehow add a success (and error?) callback to sendLine but I don't know how to do this.
Thanks for any pointers / examples
You need to define "succeeded" in order to come up with an answer to this.
All sendLine does immediately (probably) is add some bytes to a send buffer. In some sense, as long as it doesn't raise an exception (eg, MemoryError because your line is too long or TypeError because your line was the number 3 instead of an actual line) it has succeeded.
That's not a very useful kind of success, though. Unfortunately, the useful kind of success is more like "the bytes were added to the send buffer, the send buffer was flushed to the socket, the peer received the bytes, and the receiving application acted on the data in a persistent way".
Nothing in LineReceiver can tell you that all those things happened. The standard solution is to add some kind of acknowledgement to your protocol: when the receiving application has acted on the data, it sends back some bytes that tell the original sender the message has been handled.
You won't get LineReceiver.sendLine to help you much here because all it really knows how to do is send some bytes in a particular format. You need a more complex protocol to handle acknowledgements.
Fortunately, Twisted comes with a few. twisted.protocols.amp is one: it offers remote method calls (complete with responses) as a basic feature. I find that AMP is suitable for a wide range of applications so it's often safe to recommend for new development. It largely supersedes the older twisted.spread (aka "PB") which also provides both remote method calls and remote object references (and is therefore more complex - in my experience, more complex than most applications need). There are also some options that are a bit more standard: for example, Twisted Web includes an HTTP implementation (HTTP, as you may know, is good at request/response style interaction).
I have configured a WCF service to transfer data on a streamed transfer mode. I think I have set the configurations properly because I'm able to transfer files above 100Mb and that's more than I need.
Now I'm calling my transfer service three times to get three different files that don't pass the 2 Mb each. The problem is that as soon as I call for the third file, my program freezes and I don't get any response anymore, forcing me to close the program.
I don't think this is a file size issue because I have tested passing files of 20 Mb of size and only the first two get to the client just fine. But i don't have any response from the third call.
Is this a configuration issue which may limit the service calls to just two?
Best regards
HALF-SOLVED
Well, First of all I could not find out why the client cannot reach the server after two succesful requests, it hangs out spectacularly.
Now I know that I'm able to transfer 500 Mb on the service I'm sending data to the client as a zipped file. Then I call to 7z.exe (7zip) to unzip my files.
This is not a way to solve this issue. The problem still exists and I think there's a way to solve it the right way. I'll be posting the answer as soon as I find it, but in the mean time, my users will keep using my system.
I don't expect anyone to be able to help out with this but let's give it a go.
I have a WinForms app that uses a WCF service to pull down a rather large JSON document serialised into a string. I have changed the client's Reader Quota on strings to 8192000 (arbitrary but suitable for most cases) and put the service onto a custom binding with an explicit readerquota of 8192000
checking the service reference in Notepad by eye the quota in the .svcinfo files is set to 8192 although this could be a red herring.
I'm at the end of my tether, I've followed every piece of advice I can find on Google:
http://www.haveyougotwoods.com/archive/2008/03/29/wcf-and-large-messages.aspx
http://msdn.microsoft.com/en-us/magazine/cc163394.aspx
to name but two and all the suggested answers I could find on here i.e.
WCF service The maximum array length quota (16384) has been exceeded
WCF Maximum Message Size Quota
Maximum array length quota
and I looked at this:
http://wildermuth.com/2009/09/10/Using_Large_Message_Requests_in_Silverlight_with_WCF
which was a response to one of the above or one of the many other things I have looked at that I have not retrieved from my "Recently Closed Tabs" list.
Basically I can't think of anything else to do to increase this limit and yet it still insists upon first encountering a string longer than 64k in length that the limits have not been altered at all.
So could anyone just give me a really basic step-by-step to altering this one setting for a WinForms app serialising and then deserialising JSON data as a string on either end of the transaction? A lot of the other advice has been about silverlight or some other scenario and for whatever reason it just fails to affect this case.
I tried the solution as shown in the last article I linked to again, just to go over my previous work. This time instead of preventing the WCF services from working at all (which is what had happened previously) it instead started to work and upped the limits.
I don't know what I was doing wrong the first time or what I did right this time... one of those things I guess.
Before a client gets the full payload of the web request, we'd like to first send it a measurement of the size of the response it will get. If the response will be too large, the client will present a message to the user giving them the option to abort the operation.
We can write some custom code to preload the response on the server, determine the size, and then pass it on to the client, but we'd rather not if there's another way to do it.
Does anyone know if WCF has any tricky way to do this? Or are there any free third party tools out there that will accomplish this?
Thanks.
I don't think there's anything "tricky" in WCF or the .NET framework to do this, really. What are you passing back to the client? An instance of a class?
What you could do is run the query or however you fetch the response, and then serialize that into a memory stream and see how big it gets. This won't be a totally accurate size - the SOAP messages has some overhead to it, like SOAP envelope and headers and stuff - but it can give you a ballpark figure of whether you're about to return a few hundred bytes, or a couple megabytes.
Trouble is: this might take a while on the server just to assemble / query, and then to actually "measure", too. Plus you'd almost have to have two calls - one to "MeasureResult" which returns an Int or Long or something, and then a second call "GetResult" to actually get the results. So you'll incur that effort to assemble the message twice....
I don't really have a good answer for you, but maybe you just need to figure out some other way to allow the client to abort a call if it takes too long. Or find a way to more quickly figure out an indicator as to how large the response will be (without getting all the details of the response itself).