Having zilch for experience with WAP sites and the F5 load balancer,
I cannot be 100% certain that this is the issue but...
If it happens periodically it may be that the ISP that
the mobile device runs its traffic through is running
their own outgoing traffic network proxy server. In PC
based browsers, this causes the load balancer to send
the request to the wrong server in the farm. I "suspect"
that this may be occurring to some of your users.
Purely a guess on my part.
If this is, in fact, the issue, there is a product
called ScaleOut StateServer that can remedy this.
http://www.eggheadcafe.com/articles/scaleout_server.asp
--
Robbe Morris - 2004/2005 Microsoft MVP C#
Earn money answering .NET Framework
messageboard posts at EggHeadCafe.com.
http://www.eggheadcafe.com/forums/merit.asp
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I have a WAP site powered by ASP.NET Mobile controls. We're using
> cookieless sessions and have an F5 Load Balancer that balances the load
> between two web servers.
>
> Every once in a while we'll get the following exception:
>
> System.FormatException: Invalid length for a Base-64 char array. at
> System.Convert.FromBase64String(String s) at
> System.Web.UI.LosFormatter.Deserialize(String input) at
> System.Web.UI.MobileControls.MobilePage.LoadPageStateFromPersistenceMedium()
> at System.Web.UI.Page.LoadPageViewState() at
> System.Web.UI.Page.ProcessRequestMain()
>
> We've configured our F5 to route all traffic to the same machine based
> on the session ID in the URL. But what about the first request to the
> site?
>
> I suspect what's happening is this. The user's phone loads up the site
> and the URL they load has no session ID in it because its the first
> request. Any subsequent traffic has a session ID and so the F5 will
> always send that traffic to the same machine.
>
> But that machine isn't necessarily the same machine that issued the
> original session ID! Since the first request was essentially routed
> randomly to one of the two web servers, the F5 won't know to route
> additional requests back to that same server since there was no session
> ID in the first URL the user requested.
>
> Does anybody agree with this assesment? Any suggestions on how to fix
> it?
>