.Net Service provider XmlSerialization problems
[email protected] Wed, 19 May 2004 09:17:26 +0200
| Newsgroups | gmane.comp.sourceid.sso.devel |
|---|---|
| Message-ID | <OFA7683FCA.39ECB87B-ON42256E99.00272D57-42256E99.00280C64@sanlam.co.za> |
Hi guys
We've implemented SSO using SourceID's code as a base with a java idp
backend running on our mainframe and .Net service providers on the
front-end.
This works great except for one thing: XmlSerialization is killing our
servers on the front-end.
Under normal circumstances the first time you serialize an object of a
specific type to XML seven assemblies get created and loaded into the
assembly cache. The next time you serialize those seven objects don't g=
et
recreated, they're just reused.
With the XmlSerialization we use to serialize the saml request this doe=
s
not happen. Every time a user logs on seven objects are added to the
assembly cache untill the server starts misbehaving horribly because of=
all
the references in memory.
Here is the serialization code:
//Serialize assertionequest to requestDocument
XmlDocument requestDocument =3D new XmlDocument();
XmlSerializer requestSerializer =3D new XmlSerializer(typeof
(Bindings.Saml.Protocol.RequestType), new Type[]{typeof
(Core.SignedSAMLRequestType)});
requestSerializer.Serialize
(new XmlNodeWriter(requestDocument, false),
assertionRequest,
new
XmlSerializerNamespaces(SourceID.Constants.Namespace.Namespaces));
Has anyone come across the same problem yet ?
To check to see if this happens, just open the performance monitor on a=
service provider server and add .Net loading as a counter and look at t=
he
total number of assemblies.
I know this problem might not be a SourceID specific problem, but I'm j=
ust
wondering if any of the .Net guys might have run into the same problem.=
Thanks for any help
***************
Any views expressed in this message are those of the individual sender,=
and
Sanlam accepts no liability therefore, except where the sender specific=
ally
states them to be those of Sanlam.
Enige sienswyses of stellings wat in hierdie boodskap uitgedruk word is=
di=E9
van die individuele afsender, en Sanlam aanvaar geen aanspreeklikheid
daarvoor nie, behalwe waar die afsender uitdruklik vermeld dat dit di=E9=
van
Sanlam is.
=