|
|
You're in the
dotnet web services enhancements
group:Logged WSE 2.0 error: WSE350
dotnet web services enhancements:
Hello,
I get a WSE 2.0 exception in an acceptance environment. The logged error is: HTTP/ASMX Message Receive Failure: Microsoft.Web.Services2.Dime.DimeFormatException: WSE350: In the record -390353390, the number of bytes in the Data field is less than 409600, which is the value indicated in the ContentLength field. at Microsoft.Web.Services2.Dime.DimeRecord.Close(Boolean endOfMessage) at Microsoft.Web.Services2.Dime.DimeAttachmentCollection..ctor(DimeReader reader) at Microsoft.Web.Services2.Messaging.SoapDimeFormatter.Microsoft.Web.Services2.Messaging.ISoapFormatter.Deserialize(Stream stream) at Microsoft.Web.Services2.WebServicesExtension.BeforeDeserializeServer(SoapServerMessage message) What causes this error. It seems to happen at random and so far I could not reproduce this exception in our development environment or catch the actually called exception server-side or client-side since it occurs so randomly. What causes this error and what is the solution for it? Regards, --
Hello Robbert,
From your description, one of your ASP.NET webservice(uses WSE 2.0) will randomly report the following exception: ========================= Microsoft.Web.Services2.Dime.DimeFormatException: WSE350: In the record -390353390, the number of bytes in the Data field is less than 409600, which is the value indicated in the ContentLength field. ======================== As for the webservice application, is it newly deployed or has been running for long time and just occured the problem recently? Based on my research, there is some web thread discussing on the same problem which is caused by network issue, see the post below: http://www.topxml.com/Webservices-Enhancements/rn-228881_WSE350-Error---Dime -attachment-Content-Length-error.aspx Actually, the error message indicate that the request's content is less than the expected number in the ContentLength field. It is possible that some underlying network packet is corrupted or get problem. If possible you can also test the same webservice on other machine to see whether it will raise the same error. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ==================================================
Hello Steven,
I too found this message thread, but the supposed cause (a network package got corrupted) is happening regularly on our server(s) which host a WebService on the internet. So the corruption could occur anywhere on the network/internet and breaks my code. I need more information on this error from MS. I want to know detailed information on why this Exception is raised in WSE 2.0 and what the code does that raises this exception. This might immediately lead to a simple solution (like chopping large DIME-attachments into smaller pieces or resending the request). Our current attachement size is 409600 bytes. Since I have no way of reproducing this myself I want some 'code-based' advise on what to do. regards, -- rvangeldrop [quoted text, click to view] "Steven Cheng[MSFT]" wrote:
> Hello Robbert, > > From your description, one of your ASP.NET webservice(uses WSE 2.0) will > randomly report the following exception: > > ========================= > Microsoft.Web.Services2.Dime.DimeFormatException: WSE350: In the record > -390353390, the number of bytes in the Data field is less than 409600, > which > is the value indicated in the ContentLength field. > ======================== > > As for the webservice application, is it newly deployed or has been running > for long time and just occured the problem recently? Based on my research, > there is some web thread discussing on the same problem which is caused by > network issue, see the post below: > > http://www.topxml.com/Webservices-Enhancements/rn-228881_WSE350-Error---Dime > -attachment-Content-Length-error.aspx > > Actually, the error message indicate that the request's content is less > than the expected number in the ContentLength field. It is possible that > some underlying network packet is corrupted or get problem. If possible you > can also test the same webservice on other machine to see whether it will > raise the same error. > > Sincerely, > > Steven Cheng > > Microsoft MSDN Online Support Lead > > > > ================================================== > > Get notification to my posts through email? Please refer to > http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif > ications. > > > > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues > where an initial response from the community or a Microsoft Support > Engineer within 1 business day is acceptable. Please note that each follow > up response may take approximately 2 business days as the support > professional working with you may need further investigation to reach the > most efficient resolution. The offering is not appropriate for situations > that require urgent, real-time or phone-based interactions or complex > project analysis and dump analysis issues. Issues of this nature are best > handled working with a dedicated Microsoft Support Engineer by contacting > Microsoft Customer Support Services (CSS) at > http://msdn.microsoft.com/subscriptions/support/default.aspx. > > ================================================== > > >
Hello Steven,
This is very helpful. It means that I can catch this exception client-side and resend the request. I have one more question (since I was not able to trap the client-side exception for this in my debugger or any tracing logs): Is the DimeFormatException derived from or encapsulated by another exception (like WebException)? Regards, Robbert -- rvangeldrop [quoted text, click to view] "Steven Cheng[MSFT]" wrote:
> Thanks for your quick response Robbert, > > AS for the WSE350 exception, it is thrown from the WSE 2.0 DIMO > attachment's deserialize code as the callstack you provided as indicated. > It is the "Microsoft.Web.Services2.Dime" class's "close" method that throw > this exception. In this method, it has the following code logic: > > ** check if the the upstream code has marked the message as arriving end > > ** if marked as end, it will compare the current readed bytes length with > the message's content lengh field(get from the DIME message). > > ** if the value mismatch, it will report the exception as you encountered. > > Here is the disassembled code through reflector: > > ============================ > internal void Close(bool endOfMessage) > { > if (!this.m_closed) > { > this.m_closed = true; > if (this._mode == FileAccess.Read) > { > if (this.m_bytesReadWritten == this.m_contentLength) > { > if (!endOfMessage) > { > return; > } > return; > } > throw new DimeFormatException(SR.GetString("WSE350", new > object[] { this.m_id, this.m_contentLength })); > } > if (this._mode == FileAccess.Write) > { > if (this.m_chunked) > { > this.WriteChunkedPayload(true, endOfMessage); > } > else if (endOfMessage && !this.m_endOfMessage) > { > this.WriteMessageEndRecord(); > } > else if (this.m_contentLength == 0) > { > this.WriteHeader(true, (long) 0); > } > } > } > else if ((endOfMessage && !this.m_endOfMessage) && (this._mode == > FileAccess.Write)) > { > this.WriteMessageEndRecord(); > } > } > ================================================= > > Therefore, I think the code logic here is very straightforward, also I > don't think it is your application's code logic that will cause this error. > Very likely that the DIME message's content has been corrupted over the > wire. > > > Sincerely, > > Steven Cheng > > Microsoft MSDN Online Support Lead > >
Thanks for your quick response Robbert,
AS for the WSE350 exception, it is thrown from the WSE 2.0 DIMO attachment's deserialize code as the callstack you provided as indicated. It is the "Microsoft.Web.Services2.Dime" class's "close" method that throw this exception. In this method, it has the following code logic: ** check if the the upstream code has marked the message as arriving end ** if marked as end, it will compare the current readed bytes length with the message's content lengh field(get from the DIME message). ** if the value mismatch, it will report the exception as you encountered. Here is the disassembled code through reflector: ============================ internal void Close(bool endOfMessage) { if (!this.m_closed) { this.m_closed = true; if (this._mode == FileAccess.Read) { if (this.m_bytesReadWritten == this.m_contentLength) { if (!endOfMessage) { return; } return; } throw new DimeFormatException(SR.GetString("WSE350", new object[] { this.m_id, this.m_contentLength })); } if (this._mode == FileAccess.Write) { if (this.m_chunked) { this.WriteChunkedPayload(true, endOfMessage); } else if (endOfMessage && !this.m_endOfMessage) { this.WriteMessageEndRecord(); } else if (this.m_contentLength == 0) { this.WriteHeader(true, (long) 0); } } } else if ((endOfMessage && !this.m_endOfMessage) && (this._mode == FileAccess.Write)) { this.WriteMessageEndRecord(); } } ================================================= Therefore, I think the code logic here is very straightforward, also I don't think it is your application's code logic that will cause this error. Very likely that the DIME message's content has been corrupted over the wire. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead
Hello Steven,
In case of a SoapException we already have client-side exception handling in place. This leaves me with one question: Can I switch of logging WSE exceptions to the Event Viewer (or redirect it to another category). My potential customer is very annoyed by this since it very much pollutes the Event Viewer now with 'foney' problems. Thanks, -- rvangeldrop [quoted text, click to view] "Steven Cheng[MSFT]" wrote:
> Hello Robbert, > > Thanks for your response. > > I think you need to catch another exception type > ----System.Web.Services.SoapException. This is because ASP.NET webservice > always serialize any unhandled exception occured in webservice server-side > code into a soap <fault> element in the response SOAP Message. And when the > webservice client receive the message, the client runtime will deserialize > the <fault> element into a SoapException and rethrow it so that client-side > applciation can get awared of the exception. You can capture this type of > exception and inspect its sub properties for the original exception's > information. > > Here is the msdn reference also describes this: > > #Handling and Throwing Exceptions in XML Web Services > http://msdn.microsoft.com/library/en-us/cpguide/html/cpconhandlingraisingexc > eptionsinxmlwebservices.asp?frame=true > > Please feel free to let me know if there is anything else you wonder. > > Sincerely, > > Steven Cheng > > Microsoft MSDN Online Support Lead > >
Hello Robbert,
Thanks for your response. I think you need to catch another exception type ----System.Web.Services.SoapException. This is because ASP.NET webservice always serialize any unhandled exception occured in webservice server-side code into a soap <fault> element in the response SOAP Message. And when the webservice client receive the message, the client runtime will deserialize the <fault> element into a SoapException and rethrow it so that client-side applciation can get awared of the exception. You can capture this type of exception and inspect its sub properties for the original exception's information. Here is the msdn reference also describes this: #Handling and Throwing Exceptions in XML Web Services http://msdn.microsoft.com/library/en-us/cpguide/html/cpconhandlingraisingexc eptionsinxmlwebservices.asp?frame=true Please feel free to let me know if there is anything else you wonder. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead
Hello Steven,
You misunderstood me here. The server application uses WSE 2.0 and this component (the WSE component from MS) logs exceptions to the Windows Event Viewer, polluting it in this way since the error has no relevance and is handled correctly. So I need a way to tell the WSE component NOT to log exceptions that occur to the Event Viewer. Regards, -- rvangeldrop [quoted text, click to view] "Steven Cheng[MSFT]" wrote:
> Hello Robbert, > > Thanks for the followup. > > As for the further question you mentioned: > > ================== > Can I switch of logging WSE exceptions to the Event Viewer (or redirect it > to another category). My potential customer is very annoyed by this since > it > very much pollutes the Event Viewer now with 'foney' problems. > ================== > > Do you mean you have originally use some logging component to log unhandled > exceptions at client-side? I think you can surely separate such WSE error > from other application/business logic specific errors. You can check the > soapException's inner properties to get whether the soapException is > originally raised by a WSE runtime exception (like the WSE 350 here). > > Please feel free to let me know if there is anything I missed or anything > else you wonder. > > Sincerely, > > Steven Cheng > > Microsoft MSDN Online Support Lead > >
Hello Robbert,
Thanks for the followup. As for the further question you mentioned: ================== Can I switch of logging WSE exceptions to the Event Viewer (or redirect it to another category). My potential customer is very annoyed by this since it very much pollutes the Event Viewer now with 'foney' problems. ================== Do you mean you have originally use some logging component to log unhandled exceptions at client-side? I think you can surely separate such WSE error from other application/business logic specific errors. You can check the soapException's inner properties to get whether the soapException is originally raised by a WSE runtime exception (like the WSE 350 here). Please feel free to let me know if there is anything I missed or anything else you wonder. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead
Hi Robbert,
Thanks for your further description. I think this may be a bit difficult since the WSE component has been well encapsulated. Anyway, I can help consult some other WSE team's product engineers to see whether we still have any options here. I'll update you soon. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead
Hi rvangeldrop,
Steven is not feeling well today. So the response may be delayed for some time. We will get back here as soon as possible. If you have any other concern or update, please feel free to post here. Thanks very much for your understanding. Sincerely, Yanhong Huang Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================
Hello Robbert,
After some further discussion with other webservice engineers, they think there hasn't any other better means for directly intercept the underlying exception logging in WSE server-side. The problem here is that the logging engine is not configurable which is internally integrated in the WSE component. If you do think this is quite important, I would suggest you contact the CSS or Consulting service for a dedicated solution on this. http://support.microsoft.com/ Sincerely, Steven Cheng Microsoft MSDN Online Support Lead
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |