Usually what happens in a clustered environment, whether failover is involved or not, is that all information that would otherwise be stored in memory gets saved to a database, or some other persistent storage mechanism, that all servers have access to. In many cases this is a database that all servers share.

Some servers will simply synchronize between themselves without a shared persistence mechanism. So for instance when you add an attribute to a sesison object on one server, it will send that information to all the other servers in the cluster and they store it as well. Then, if a failover ocurrs (or if you are just balancing load between the servers), they all have the same redundant data on them, so any server can take the place of any other at any point in time. The same is true if they are all sharing a database instance.

All of this happens independant of the application, except to the extent that your objects to store need to be serializable as you said. I have heard of some cases where servers will expose information to your app, like what node of a cluster you are running on, and that is sometimes important to know. Generally speaking though, unless you have a reason to do otherwise, your app should be written without concern for clustering or failover, let it be handled at the app server level.

Frank


From: "Wang, Yuanbo" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Subject: RE: Single ActionForm accross multiple Actions
Date: Fri, 11 Jun 2004 10:59:19 -0500

Interesting topic. I am new to server clustering so I'd like to discuss
about how fail-over get implemented in a clustering env.

I understand any ActionForms and custom data objects in the session need
to be serializable, so in case one node server fails, all the
information can be serialized and recreated in another node server. And
the end user will not aware of this fail over happened.

But when does the Serialization happen? Think of the extreme case of a
fatal memory error in one node server, if the session data does not get
serialized before, then this node server may not have the chance to do
the serialization.

So if my logic is correct, the server need to serialize the session
object often enough with each http request, to be safe. Then if your
session object is big, there will be a lot of IO involved to do the
serialization. That may be the reason IBM suggest to keep session object
under 4K.

Am I right on this?

Thanks,
Yuanbo


-----Original Message----- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, June 10, 2004 9:42 AM To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions


That's good info, thank you! I was suspecting this was an issue that arises in a distributed environment and probably isn't quite as critical on a single server. I think the thought of keeping session as small as possible is ALWAYS a good idea, but my suspicion is that it only really becomes very important with multiple servers involved, as you point out.

Your point about session vs. cost of back-end work is important, and was
the
reason I personally did what I did in the app I'm thinking of... The
back-end calls in a couple of cases were fairly expensive, and keeping
the
data in session improved performance noticably.  However I may now in
fact
be moving into a distributed environment, so I may have to do some
refactoring to cut down session size

Interestingly, using the code from Ken yesterday I discovered that my
user's
session in this app average 8k-10k, but peak up to 25k-30k at certain
points... I also discovered that I'm never clearing out that session
info to
get it back down to 10k.  I thought I was all this time.  Leaving that
info
there doesn't affect the functioning of the application in any way
because
it's constantly being overwritten with fresh data, but the fact is that
I
really should clear it out to reduce the size of session when possible.

Fortunately there is one place in the app that makes perfect sense to do

this, the app kind of flows through this one spot, so that's a nice
thing.
I'm going to be looking into cutting out some of that data, but I
already
know there's not much I can do in that regard.

Frank

>From: "Jesse Alexander (KXT)" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
>Subject: RE: Single ActionForm accross multiple Actions
>Date: Thu, 10 Jun 2004 09:01:57 +0200
>
>As far as I know...
>
>The recommendation to keep the session below the 4-5 kB limit comes
>from clustering.
>
>When you build a cluster for your webapp and specify "session
>failover", meaning that a session should be taken over by a running
>instance in the cluster if the original instance crashes, then the
>session must be replicated everytime it changes to all instances in the

>cluster. This session-replication usually scales well, IF the
>information to be broadcasted does not exceed 4 kB.
>
>At least that's what I was taught. I operate in WLS-area, but I believe

>WS
>is
>behaving similar in that area (everybody is cooking with the same water
;-)
>).
>
>I know of applications that scale well with session up into the
>MB-area!
>Their
>problem is not the memory on the mid-tier server. You just must give
them
>all
>the memory you can buy... These applications cache some data they must
>request
>from a backend. And the backend-mechanism make it perform and scale
better
>when
>the data is cached in the session. But these apps are special cases!!!
>(Cost of
>calling the backend must also be considered...).
>
>hth
>Alexander
>
>-----Original Message-----
>From: Frank Zammetti [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 9. Juni 2004 20:02
>To: [EMAIL PROTECTED]
>Subject: RE: Single ActionForm accross multiple Actions
>
>
>I had that thought too, but I don't know enough about WebSphere to know

>if it does that all the time... I know that I just installed 5.0 on a
>test box and didn't have to set up a database or anything, so unless it

>(a) set one up itself and is using it "under the hood", or (b) is
>persisting to the file system, which I tend to doubt, then I'm thinking

>along the same lines as you
>I think, which is to say that this recommendation, while probably valid
all
>the time, doesn't carry the same weight if session is in-memory only.
>
>Can anyone shed more light on this?
>
>Frank
>
>
> >From: [EMAIL PROTECTED]
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Subject: RE: Single ActionForm accross multiple Actions
> >Date: Wed, 9 Jun 2004 13:26:40 -0400
> >
> >http://www.redbooks.ibm.com/redbooks/pdfs/sg246176.pdf
> >
> >I'm not 100% sure, but it seems that the recommendation for session
> >size being < 4-5K is targeted to the scenario where the server has to
>serialize
> >the session for persistence.
> >
> >Dennis
> >
> >
> >
> >
> >
> >"Frank Zammetti" <[EMAIL PROTECTED]>
> >06/09/2004 01:10 PM
> >Please respond to
> >"Struts Users Mailing List" <[EMAIL PROTECTED]>
> >
> >
> >To
> >[EMAIL PROTECTED]
> >cc
> >
> >Subject
> >RE: Single ActionForm accross multiple Actions
> >
> >
> >
> >
> >
> >
> >Very interesting (in a bad way for me!)... does anyone know if there
> >is
>an
> >
> >easy way to see exactly how big the session object is at any given
> >point in time?  Preferably something not specific to WebSphere... is
> >there a
>method
> >
> >of session I'm unaware of that might help?
> >
> >Frank
> >
> >
> > >From: "Yulin Zhao" <[EMAIL PROTECTED]>
> > >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > >Subject: RE: Single ActionForm accross multiple Actions
> > >Date: Wed, 9 Jun 2004 11:57:49 -0500
> > >
> > >
> > >
> > >
> > >Regarding WebSphere session performance, IBM redbook sg246176
> > >chapter
> >15.10
> > >has
> > >some details that might help you. We use WAS4 so that's for WAS4.
> > >Here is some note from it: "In general the best performance will be

> > >realized with session objects that are less than 2 KB in size. Once

> > >the session object starts to
>exceed
> >
> > >4-5
> > >KB in size, a significant decrease in performance can be expected."
> > >
> > >
> > >
> > >
> > >[EMAIL PROTECTED] on 06/09/2004
> >11:07:58
> > >AM
> > >
> > >Please respond to "Struts Users Mailing List"
> > ><[EMAIL PROTECTED]>
> > >
> > >To:   [EMAIL PROTECTED]
> > >cc:    (bcc: Yulin Zhao/FBFS)
> > >
> > >Subject:  RE: Single ActionForm accross multiple Actions
> > >
> > >
> > >
> > >I wasn't doubting you, as that standard practice rule is fairly
> >well-known
> > >outside WebSphere.  I think I've generally heard 32K as a limit,
> > >but whatever, the point is keep session objects small.
> > >
> > >What I was asking was if there was some technical limitation in
>WebSphere
> >I
> > >wasn't aware of.  I can't go re-architecting this particular
>application
> > >now, so if I'm storing 64K per session I was curious if WebSphere
> > >was
> >going
> > >to choke on it.  I understand the performance implications and the
>server
> > >resource implications, as I did when I took this path, but I wasn't
>sure
> >if
> > >there was something more I wasn't aware of.
> > >
> > >Thanks for the lnik in any case.  Although it's 95% stuff I knew
>already
> >(a
> > >couple of EJB points I hadn't considered), it's something I can
> > >pass
>out
> >to
> > >the more junior members of my staff.
> > >
> > >Frank
> > >
> > >
> > > >From: "Enrique Medina" <[EMAIL PROTECTED]>
> > > >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > > >To: [EMAIL PROTECTED]
> > > >Subject: RE: Single ActionForm accross multiple Actions
> > > >Date: Wed, 09 Jun 2004 16:45:04 +0200
> > > >
> > > >I am sure about this problem, believe me.
> > > >
> > > >See
> >http://www-3.ibm.com/software/webservers/appserv/ws_bestpractices.pdf
> > > >
> > > >
> > > >>From: "Frank Zammetti" <[EMAIL PROTECTED]>
> > > >>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > > >>To: [EMAIL PROTECTED]
> > > >>Subject: RE: Single ActionForm accross multiple Actions
> > > >>Date: Wed, 09 Jun 2004 09:25:16 -0400
> > > >>MIME-Version: 1.0
> > > >>X-Originating-IP: [66.98.131.150]
> > > >>X-Originating-Email: [EMAIL PROTECTED]
> > > >>X-Sender: [EMAIL PROTECTED]
> > > >>Received: from mail.apache.org ([209.237.227.199]) by
> >mc9-f7.hotmail.com
> > > >>with Microsoft SMTPSVC(5.0.2195.6824); Wed, 9 Jun 2004 06:27:06
>-0700
> > > >>Received: (qmail 19779 invoked by uid 500); 9 Jun 2004 13:27:00
>-0000
> > > >>Received: (qmail 19670 invoked by uid 99); 9 Jun 2004 13:26:59
> > > >>-0000
> > > >>Received: from [64.4.27.56] (HELO hotmail.com) (64.4.27.56)  by
> > >apache.org
> > > >>(qpsmtpd/0.27.1) with ESMTP; Wed, 09 Jun 2004 06:26:59 -0700
> > > >>Received: from mail pickup service by hotmail.com with Microsoft
> > >SMTPSVC;
> > > >>Wed, 9 Jun 2004 06:25:16 -0700
> > > >>Received: from 66.98.131.150 by by8fd.bay8.hotmail.msn.com with
> > >HTTP;Wed,
> > > >>09 Jun 2004 13:25:16 GMT
> > > >>X-Message-Info: JGTYoYF78jGOA3bTrliIqk5vRqlH20u2
> > > >>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > > >>Precedence: bulk
> > > >>List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
> > > >>List-Subscribe: <mailto:[EMAIL PROTECTED]>
> > > >>List-Help: <mailto:[EMAIL PROTECTED]>
> > > >>List-Post: <mailto:[EMAIL PROTECTED]>
> > > >>List-Id: "Struts Users Mailing List" <user.struts.apache.org>
> > > >>Delivered-To: mailing list [EMAIL PROTECTED]
> > > >>Message-ID: <[EMAIL PROTECTED]>
> > > >>X-OriginalArrivalTime: 09 Jun 2004 13:25:16.0563 (UTC)
> > > >>FILETIME=[33F46E30:01C44E25]
> > > >>X-Virus-Checked: Checked
> > > >>Return-Path:
> >[EMAIL PROTECTED]
> > > >>
> > > >>Do you know the rational behind that WebSphere warning?  I mean,

> > > >>the obvious answer is it uses up server resources and will use
> > > >>more as
> >load
> > > >>increases, but is there another reason you know of?  I ask
> > > >>because I
> > >have
> > > >>an application where we store quite considerably more than 16K
>without
> >
> > >any
> > > >>problem.  We're currently running it under Tomcat but are
> > > >>migrating
>to
> > > >>WebSphere 5, so this caught my attention.
> > > >>
> > > >>Frank
> > > >>
> > > >>
> > > >>>From: "Enrique Medina" <[EMAIL PROTECTED]>
> > > >>>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > > >>>To: [EMAIL PROTECTED]
> > > >>>Subject: RE: Single ActionForm accross multiple Actions
> > > >>>Date: Wed, 09 Jun 2004 09:57:02 +0200
> > > >>>
> > > >>>I've been reading this thread of discussion and one question
> > > >>>arises
> >in
> > >my
> > > >>>mind that you probably has not taken into consideration.
> > > >>>
> > > >>>Is there any limit with session management in your application
> >server?
> > >I
> > > >>>mean, Websphere, for example, warns you about storing more than

> > > >>>16K
> >in
> > > >>>session.
> > > >>>
> > > >>>To bypass this problem, there is a good alternative (to the
> > > >>>best of
> >my
> > > >>>knowledge): create a Map where keys would be session IDs and
> > > >>>values
> > >would
> > > >>>be data (this would lead to the need of creating a wrapper for
> > > >>>all
> >your
> > > >>>data). Then, this Map could be placed in application context,
>servlet
> > > >>>context (in case of Struts which only uses one ActionServlet)
> > > >>>or
>even
> >
> > >as
> > > >>>a static Map shared by all users in the application server (of
> >course,
> > > >>>with no clustering at all).
> > > >>>
> > > >>>I would be delighted to hear some comments and suggestions in
> > > >>>this solution.
> > > >>>
> > > >>>Enrique Medina.
> > > >>>
> > > >>>
> > > >>>>From: "Frank Zammetti" <[EMAIL PROTECTED]>
> > > >>>>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > > >>>>To: [EMAIL PROTECTED]
> > > >>>>Subject: RE: Single ActionForm accross multiple Actions
> > > >>>>Date: Tue, 08 Jun 2004 22:02:01 -0400
> > > >>>>MIME-Version: 1.0
> > > >>>>X-Originating-IP: [68.81.51.228]
> > > >>>>X-Originating-Email: [EMAIL PROTECTED]
> > > >>>>X-Sender: [EMAIL PROTECTED]
> > > >>>>Received: from mail.apache.org ([209.237.227.199]) by
> > >mc3-f6.hotmail.com
> > > >>>>with Microsoft SMTPSVC(5.0.2195.6824); Tue, 8 Jun 2004
> > > >>>>19:02:13
> >-0700
> > > >>>>Received: (qmail 97286 invoked by uid 500); 9 Jun 2004
> > > >>>>02:02:37
> >-0000
> > > >>>>Received: (qmail 97272 invoked by uid 99); 9 Jun 2004 02:02:36
>-0000
> > > >>>>Received: from [64.4.27.85] (HELO hotmail.com) (64.4.27.85)
> > > >>>>by apache.org (qpsmtpd/0.27.1) with ESMTP; Tue, 08 Jun 2004
> > > >>>>19:02:36
> > >-0700
> > > >>>>Received: from mail pickup service by hotmail.com with
> > > >>>>Microsoft SMTPSVC; Tue, 8 Jun 2004 19:02:01 -0700
> > > >>>>Received: from 68.81.51.228 by by8fd.bay8.hotmail.msn.com with
> > >HTTP;Wed,
> > > >>>>09 Jun 2004 02:02:01 GMT
> > > >>>>X-Message-Info: JGTYoYF78jEng6W3tuLSY7svF94DHMWf
> > > >>>>Mailing-List: contact [EMAIL PROTECTED]; run by
> > > >>>>ezmlm
> > > >>>>Precedence: bulk
> > > >>>>List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
> > > >>>>List-Subscribe: <mailto:[EMAIL PROTECTED]>
> > > >>>>List-Help: <mailto:[EMAIL PROTECTED]>
> > > >>>>List-Post: <mailto:[EMAIL PROTECTED]>
> > > >>>>List-Id: "Struts Users Mailing List" <user.struts.apache.org>
> > > >>>>Delivered-To: mailing list [EMAIL PROTECTED]
> > > >>>>Message-ID: <[EMAIL PROTECTED]>
> > > >>>>X-OriginalArrivalTime: 09 Jun 2004 02:02:01.0481 (UTC)
> > > >>>>FILETIME=[C0FB5790:01C44DC5]
> > > >>>>X-Virus-Checked: Checked
> > > >>>>Return-Path:
> > >[EMAIL PROTECTED]
> > > >>>>
> > > >>>>You can set the scope attribute of your action mappings to
>session,
> > >then
> > > >>>>you don't have to do the code you have below.  The form
> > > >>>>instance
> >that
> > >is
> > > >>>>passed into execute() will either be what was in session, or a
>newly
> > > >>>>created one.
> > > >>>>
> > > >>>>I'm not sure about the answer to the second part of your
> > > >>>>question,
> >but
> > > >>>>I'm about 99.99% sure you can still use it (anyone else
> > > >>>>verify?)
> > > >>>>
> > > >>>>Frank
> > > >>>>
> > > >>>>
> > > >>>>>From: "Kunal H. Parikh" <[EMAIL PROTECTED]>
> > > >>>>>Reply-To: "Struts Users Mailing List"
> > > >>>>><[EMAIL PROTECTED]>
> > > >>>>>To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> > > >>>>>Subject: RE: Single ActionForm accross multiple Actions
> > > >>>>>Date: Wed, 9 Jun 2004 10:34:27 +1000
> > > >>>>>
> > > >>>>>Great ...... thanks for all the responses...
> > > >>>>>
> > > >>>>>I think I will go with the ActionForm stored in
> > > >>>>>session-scope.
> > > >>>>>
> > > >>>>>Just wanting to confirm, that I will need to perform the
>following
> > >code
> > > >>>>>changes:
> > > >>>>>
> > > >>>>>==================
> > > >>>>>public ActionForward execute( ActionMapping actionMapping,
> >ActionForm
> > > >>>>>actionForm, HttpServletRequest httpServletRequest,
> > >HttpServletResponse
> > > >>>>>httpServletResponse ) throws Exception
> > > >>>>>{
> > > >>>>>     actionForm =
> > >httpServletRequest.getSession().getAttribute("myForm");
> > > >>>>>     // ...
> > > >>>>>     // normal code follows!!!
> > > >>>>>}
> > > >>>>>==================
> > > >>>>>
> > > >>>>>Also, would I be correct in saying that I will be unable to
> > > >>>>>use
>the
> > > >>>>>ValidatorActionForm.
> > > >>>>>
> > > >>>>>
> > > >>>>>TIA,
> > > >>>>>
> > > >>>>>Kunal
> > > >>>>>
> > > >>>>>
> > > >>>>>-----Original Message-----
> > > >>>>>From: Frank Zammetti [mailto:[EMAIL PROTECTED]
> > > >>>>>Sent: Tuesday, 8 June 2004 23:21
> > > >>>>>To: [EMAIL PROTECTED]
> > > >>>>>Subject: RE: Single ActionForm accross multiple Actions
> > > >>>>>
> > > >>>>>This is more or less what a session-scope ActionForm is for.

> > > >>>>>As
> >long
> > > >>>>>as the
> > > >>>>>
> > > >>>>>ActionForm class contains all the properties and methods for
> > > >>>>>all
> >the
> > > >>>>>screen
> > > >>>>>it will service, just putting it in session I think is your
> > > >>>>>best
> >bet.
> > > >>>>>As
> > > >>>>>someone else said, hidden form fields are your other choice.
> > >Actually,
> > > >>>>>you
> > > >>>>>could also store the data temporarily to a database, but if
> > > >>>>>you
> >would
> > > >>>>>even
> > > >>>>>consider that, session is really the right answer.
> > > >>>>>
> > > >>>>>Frank
> > > >>>>>
> > > >>>>>
> > > >>>>> >From: "Kunal H. Parikh" <[EMAIL PROTECTED]>
> > > >>>>> >Reply-To: "Struts Users Mailing List"
> > > >>>>> ><[EMAIL PROTECTED]>
> > > >>>>> >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> > > >>>>> >Subject: Single ActionForm accross multiple Actions
> > > >>>>> >Date: Tue, 8 Jun 2004 12:08:25 +1000
> > > >>>>> >
> > > >>>>> >Hi All!
> > > >>>>> >
> > > >>>>> >I want to maintain a single ActionForm across multiple
> > > >>>>> >Actions.
> > > >>>>> >
> > > >>>>> >I want to get the info from the user in a step-by-step
> > > >>>>> >manner,
> >but
> > > >>>>>only
> > > >>>>> >wanna talk to the SessionBean at the end when they hit
>"confirm".
> > > >>>>> >
> > > >>>>> >The alternative that I can think of is writing a JavaBean
> > > >>>>> >with
> >all
> > > >>>>>the
> > > >>>>> >properties, and pass the JavaBean around as a session
>attribute.
> > > >>>>> >
> > > >>>>> >Any one have a better solution ?
> > > >>>>> >
> > > >>>>> >
> > > >>>>> >TIA,
> > > >>>>> >
> > > >>>>> >Kunal
> > > >>>>> >
> > > >>>>> >
> > > >>>>> >
> > > >>>>>
> > > >-----------------------------------------------------------------
> > > >----
> > > >>>>> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >>>>> >For additional commands, e-mail:
> > > >>>>> >[EMAIL PROTECTED]
> > > >>>>> >
> > > >>>>>
> > > >>>>>_____________________________________________________________
> > > >>>>>____
> > > >>>>>Watch the online reality show Mixed Messages with a friend
and
> >enter
> > >to
> > > >>>>>win
> > > >>>>>a trip to NY
> > >
> >
> >>>>>http://www.msnmessenger-download.click-url.com/go/onm00200497ave/
> >>>>>direct/01/
> > > >>>>>
> > > >>>>>
> > >
> >
> >>>>>-----------------------------------------------------------------
> >>>>>----
> > > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >>>>>For additional commands, e-mail: [EMAIL PROTECTED]
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > >
> >
> >>>>>-----------------------------------------------------------------
> >>>>>----
> > > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >>>>>For additional commands, e-mail: [EMAIL PROTECTED]
> > > >>>>>
> > > >>>>
> > > >>>>______________________________________________________________
> > > >>>>___
> > > >>>>FREE pop-up blocking with the new MSN Toolbar ? get it now!
> > > >>>>http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
> > > >>>>
> > > >>>>
> > >
> >
> >>>>------------------------------------------------------------------
> >>>>---
> > > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >>>>For additional commands, e-mail: [EMAIL PROTECTED]
> > > >>>>
> > > >>>
> > > >>>_______________________________________________________________
> > > >>>__
> > > >>>Reserva desde ahora tus vacaciones en MSN Viajes. M?s c?modo,
m?s
> > >barato
> > > >>>y m?s opciones. http://www.msn.es/Viajes/
> > > >>>
> > > >>>
> > >
> >>>-------------------------------------------------------------------
> >>>--
> > > >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >>>For additional commands, e-mail: [EMAIL PROTECTED]
> > > >>>
> > > >>
> > > >>________________________________________________________________
> > > >>_
> > > >>Stop worrying about overloading your inbox - get MSN Hotmail
Extra
> > > >>Storage!
http://join.msn.click-url.com/go/onm00200362ave/direct/01/
> > > >>
> > > >>
> > >
> >>--------------------------------------------------------------------
> >>-
> > > >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >>For additional commands, e-mail: [EMAIL PROTECTED]
> > > >>
> > > >
> > > >_________________________________________________________________
> > > >Descarga gratis la Barra de Herramientas de MSN
> > >
> >
> >http://www.msn.es/usuario/busqueda/barra?XAPID=2031&DI=1055&SU=http%3
> >A//www.hotmail.com&HL=LINKTAG1OPENINGTEXT_MSNBH
> > >
> > > >
> > > >
> > > >-----------------------------------------------------------------
> > > >----
> > > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > >
> > >_________________________________________________________________
> > >Stop worrying about overloading your inbox - get MSN Hotmail Extra
> >Storage!
> > >http://join.msn.click-url.com/go/onm00200362ave/direct/01/
> > >
> > >
> > >-------------------------------------------------------------------
> > >--
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >-------------------------------------------------------------------
> > >--
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >_________________________________________________________________
> >Getting married? Find great tips, tools and the latest trends at MSN
> >Life Events. http://lifeevents.msn.com/category.aspx?cid=married
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
>_________________________________________________________________
>Watch the online reality show Mixed Messages with a friend and enter to

>win a trip to NY
>http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct
>/01/
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]


_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to