CSLA Light - Error when calling BeginSave "The remote server returned an unexpected response: (404) Not Found."

Sometimes I have seen .NET exceptions resulting in 404.  Did you try to put a breakpoint on the server side and trace it through to see if your calls are getting to the server and if so are there any exceptions thrown?

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

Hello All!

I am currently developing a CSLA Light application and am struggling getting my object to save, or really even hitting my server side data portal code as a result to calls to BeginSave on the silverlight client. When I call BeginSave I get a protocolexception "The remote server returned an unexpected response: (404) Not Found.". What's weird though is that I am not having any problems with calls to BeginCreate or BeginFetch. What could be different? Any ideas anyone? I just upgraded this past Friday to the latest code release Rocky mentioned on his blog. Thanks in advance for the help

Csla.Server.Hosts.Silverlight.WcfPortal.Update is the first correct breakpoint that is hit on the server.  If nothing is messing with proxy settings during update process, this should work.  You are not getting a warning on that breakpoint “no symbols have been loaded…”, do you?  It is really puzzling that fetch works without problems.  You can try to also increase quotas in your .CLientConfig to see if that makes any difference.

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

Magenic ®

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

My God man you are quick! Isn't it odd that CSLA being a free product gets better support than some of these third party vendors! WOW

Anyway, I placed breakpoints on my server side DataPortal_Update/Insert methods and they never hit. I also placed breakpoints on method Csla.Server.Hosts.Silverlight.WcfPortal.Update but it also never hits. Is this the right place to place the server side breakpoint?

Thanks for all your help!

Not really.  This sounds pretty strange to me.  If it was a serialization issues, you would have gotten a different error from formatter.  Any chance you can comment the whole GetChildren out, then start un-commenting one line at a time to see what property is killing the process?  You can also break at the server to see what size the request is to see if message size is an issue.  If it is, you can increase the quotas at the server and the client to fix it.  As a matter of cat, I would bump them to the max just to rule that out altogether.  I think the limit is 2 GB, but default is 64 K.

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

The error appears to happen only when saving my particular object. I say this because I created a dummy business object and it worked fine. However my particular object continues to bomb. One thing about this object is that it does all of its serialization manually via GetState, GetChildren, SetState, SetChildren, etc... However having said this I have no problem fetching the object, so going from the server to the client does not appear to be an issue. It's going from the client to the server where things go whack. For example, when going to the server from the client if I step over the GetChildren code such that none of child objects/collections are serialized then I am able to hit the server side code without issue. But if I let the GetChildren code run I never hit the server side code. Do you got any ideas???

In case of GA 30, the problem was the size of your object.  I added the following reader quotas to binding configuration in web.config, and the error went away.

<bindings>

                                                <basicHttpBinding>

                                                                <binding name="BasicHttpBinding_IWcfPortal" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">

                                                                                <readerQuotas maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxStringContentLength="2147483647"/>

                                                                </binding>

                                                </basicHttpBinding>

                                </bindings>

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

Fetch operation hits a breakpoint in at start of    public WcfResponse Fetch(CriteriaRequest request)

but update operation does not get to start of     public WcfResponse Update(UpdateRequest request)

Try to bump up the setting to the max – 2GB – 2147483647 just to see if this works.

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

Hi, thanks for that, unfortunately however the problem persists. It does appear to be a size problem though, but applying your settings doesn't remove the error. With >= 297 rows returned i get the error, with <= 296 I don't.

I think I am a bit confused, so I apologize in advance.  Did it finally work for you with large quotas?  Also, how wide are those rows?

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

Magenic ®

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

That was with size bumped right up to max

<binding name="WcfPortalLargeBuffer" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
      <readerQuotas maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxStringContentLength="2147483647"/>
</binding>

The error can also be reproduced by reducing the size used in <basicHttpBinding>.  .

Set the rows returned to 296, so no 404 error.

Reduce size to 4100000, get 404 error

<binding name="WcfPortalLargeBuffer" maxBufferSize="4100000" maxReceivedMessageSize="4100000">
     <readerQuotas maxArrayLength="4100000" maxBytesPerRead="4100000" maxStringContentLength="4100000"/>
</binding>

Increase size to 4200000 and no error

        <binding name="WcfPortalLargeBuffer" maxBufferSize="4200000" maxReceivedMessageSize="4200000">
          <readerQuotas maxArrayLength="4200000" maxBytesPerRead="4200000" maxStringContentLength="4200000"/>
        </binding>

UpdateRequest is 3136378 bytes long.

I was just trying to make sure I follow the description.  I think you need to adjust IIS settings.  Here is the link with explanation:

http://msdn.microsoft.com/en-us/library/e1f13641(VS.71).aspx

I think you need to increase maxRequestLength element.  The default is 4 MB (4096), which sounds like about the size you are dealing with.  Try to bump it up to see if this is the issue – I do not guaranty this J.

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

Hi Sergey, apologies for being obtuse.

No it didn't work with large quotas. The rows are not particularly wide - 18 fields, ints, dates, bools, a decimal and a few strings. This is a basic example to try and establish our approach to grid editing. So the class is a basic Users business base list containing User child objects. Populate the grid, change a few rows, save back to server.

After trying the large quotas, 2G, and still getting the 404 error, I reduced the amount of data by one row, the maximum data I can update without getting a 404 error.

Then to see if the basicHttpBinding settings were having an effect, I reduced their values to a low number, which produced the 404 error.

Playing with the size of the basicHttpBindingsettings I found that 4200000 allowed the 296 rows to update while 4100000 produced the 404 error.

Is that clearer?