Re: .Net Service provider XmlSerialization problems

Sorry that I hadn't replied yet, I was looking for more information on=20=

this last night. I just saw your post on the mono-users list, so I=20
figure I will give you a status update :-)

 =46rom my experiments, it looks like if for the Microsoft CLI=20
implementation, the XmlSerializer (Type, String) constructor will reuse=20=

generated code if needed. The (Type, Type[]) always creates new code.=20
 =46rom talking to the Mono-ers, their implementation does not appear to=20=

do this; they always cache.

The solutions I am currently looking at for this problem:

1. The Mono implementation of XmlSerializer apparently has thread-safe=20=

implementations of Serialize and Deserialize. The Microsoft=20
implementation makes no such claim; hopefully, the Microsoft=20
implementation supports multiple threads using the same serializer at=20
once.  If so, the serializer can just be a static value created at=20
runtime.
2. If not, investigate into using thread locals to create one copy per=20=

thread. Since the threading mechanism of the ASP.NET container is not=20
exposed, there is no way to know without trying if this would correct=20
the problem - threads could be created rather than pooled and reused.
3. Investigate if Mono will create concrete (reusable) assemblies, and=20=

if these assemblies could be bundled and used rather than creating a=20
new XmlSerializer.
4. Manually edit the classes and add all subtypes as XmlInclude=20
attributes, and switch to the (Type) constructor. This does not seem=20
maintainable in the long run.

-David Waite

On May 19, 2004, at 1:17 AM, [email protected] wrote:

> 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=20=

> get
> recreated, they're just reused.
>
> With the XmlSerialization we use to serialize the saml request this=20
> does
> not happen. Every time a user logs on seven objects are added to the
> assembly cache untill the server starts misbehaving horribly because=20=

> 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=20=

> the
> total number of assemblies.
>
> I know this problem might not be a SourceID specific problem, but I'm=20=

> just
> 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=20
> sender, and
> Sanlam accepts no liability therefore, except where the sender=20
> specifically
> states them to be those of Sanlam.
> Enige sienswyses of stellings wat in hierdie boodskap uitgedruk word=20=

> is di=E9
> van die individuele afsender, en Sanlam aanvaar geen aanspreeklikheid
> daarvoor nie, behalwe waar die afsender uitdruklik vermeld dat dit di=E9=
=20
> van
> Sanlam is.
>
>
> _______________________________________________
> sso-dev mailing list
> [email protected]
> http://mail.sourceid.org/mailman/listinfo/sso-dev