Your confirmation is needed (ok 3000288)

[Lyris ListManager]

Your email address 'archive@mail-archive.com' has been submitted to be
unsubscribed from the 'ldap' mailing list.

This unsubscribe command requires your confirmation that you want to be
unsubscribed.

To confirm that you do want to unsubscribe, reply to this message so that
the words "ok 3000288" appear somewhere on the subject line.

Make sure that your reply message is addressed to
unsubscribe-conf...@listserver.itd.umich.edu

You will receive notification that your confirmation has been received, and
that you have been unsubscribed.

If you do not want to unsubscribe, do nothing.  You will be kept on the
mailing list.

---

Return-Path: 
Received: from a-net.ne.jp ([183.93.3.7]) by listserver.gpcc.itd.umich.edu with 
SMTP (Lyris ListManager LINUX version 7.0f); Wed, 09 Mar 2011 20:42:19 -0500
Received: from sosnqyhwd1 (unknown [71.155.188.132])
by smtp51 (Coremail) with SMTP id yPBJFZ84pPYYyDkV.1
for ; Fri, 11 Mar 2011 
10:43:26 +0800 (CST)
X-Originating-IP: [71.155.188.132]
Subject: 
From: =?gb2312?B?c2p4OQ==?= 
To: ldap-request
X-Mailer: Microsoft Outlook Express 
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_NextPart_000_0019_01CBDFD8.8AE7AD00"
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180

# Mail sent to leave-ldap-3000288l was converted to these commands: 
unsubscribe ldap archive@mail-archive.com confirm
end

# This is the text of the message that triggered the action:

Return-Path: 
Received: from a-net.ne.jp ([183.93.3.7]) by listserver.gpcc.itd.umich.edu with 
SMTP (Lyris ListManager LINUX version 7.0f); Wed, 09 Mar 2011 20:42:19 -0500
Received: from sosnqyhwd1 (unknown [71.155.188.132])
by smtp51 (Coremail) with SMTP id yPBJFZ84pPYYyDkV.1
for ; Fri, 11 Mar 2011 
10:43:26 +0800 (CST)
X-Originating-IP: [71.155.188.132]
Subject: =?iso-2022-jp?B?GyRCPXckTyRkJEMkUSRqPGMhOSQ3JDUkLCQkJCQkaCRNISkbKEI=?=
From: =?gb2312?B?c2p4OQ==?= 
To: 
X-Mailer: Microsoft Outlook Express 
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_NextPart_000_0019_01CBDFD8.8AE7AD00"
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180

This is a multi-part message in MIME format.

--=_NextPart_000_0019_01CBDFD8.8AE7AD00
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

$B=w;R!{3X@8!&=w;R!{9;@8$,$*>.8/$$M_$7$5$K!&!&!&(B

$BEv7G<(HD$,K?M-L>;(;o$K>
http://reqrer.com/sapolove/ 


$B%5%$%HJD:?$b;~4V$NLdBj$G$9(B!!

$BK\Ev$K%d%P%$$s$G;22C$r4uK>$5$l$kJ}$O(B

$B%U%j!<%"%I%l%9$r;22C$r$*4+$a$7$^$9!#(B

$B0lF|$N=q$-9~$_?tJ?6Q(B2,000$B7o0J>e$"$j$^$9$,(B

$B=w;RCf3X@8!&=w;R9b9;@8$H$N@-9T0Y$OK!N'$G6X;_$5$l$F$$$^$9!#(B


$B!L$$$^$9$0%5%$%H$X(BGO$B!M(B>>
http://reqrer.com/sapolove/




$BG[?.ITMW(B
info_tas...@yahoo.co.jp $
--=_NextPart_000_0019_01CBDFD8.8AE7AD00
Content-Type: text/html;
charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable








=1B$B=3Dw;R!{3X@8!&=3Dw;R!{9;@8$,$*>.8/$$M_$7$5$K!&!&!&=1B(B
 
=1B$BEv7G<(HD$,K?M-L>;(;o$K
 
=1B$B!L$$$^$9$05-;v$r8+$k!M=1B(B>>http://reqrer.com/sapolove/";>http://reqrer.com/sapolove/ =

 
=1B$B%5%$%HJD:?$b;~4V$NLdBj$G$9=1B(B!!
 
=1B$BK\Ev$K%d%P%$$s$G;22C$r4uK>$5$l$kJ}$O=1B(B
 
=1B$B%U%j!<%"%I%l%9$r;22C$r$*4+$a$7$^$9!#=1B(B
 
=1B$B0lF|$N=3Dq$-9~$_?tJ?6Q=1B(B2,000=1B$B7o0J>e$"$j$^$9$,=1B(B
 
=1B$B=3Dw;RCf3X@8!&=3Dw;R9b9;@8$H$N@-9T0Y$OK!N'$G6X;_$5$l$F$$$^$9!#=1B=
(B
 
=1B$B!L$$$^$9$0%5%$%H$X=1B(BGO=1B$B!M=1B(B>>http://reqrer.com/sapolove/";>http://reqrer.com/sapolove/
 
 
 
=1B$BG[?.ITMW=1B(Bmailto:info_tas...@yahoo.co.jp";>info_tas...@yahoo.co.jp =
   =20
$

--=_NextPart_000_0019_01CBDFD8.8AE7AD00--

WebSphere Application Server: Re: EJB Activation Error after EJB Timeout

[dWForums]

Author:
gas

Message:
Hi,

These are two different things.
Bean state is passivated when it is not in transaction, based on activation 
policy (see bkail response in your other post).
Timeout is used by the container to detect 'abandoned' beans that should be 
removed. You are hitting that one. Your bean is inactive longer than 10 
minutes, so removed.

Unfortunately you can not change it in the FEP EJB 3.0, see limitations on this 
page:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.ejbfep.multiplatform.doc/info/ae/ae/rejb_limitationsejbfp.html

If you need longer timeout you can:
- migrate to WAS v7, where this setting is supported - 
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.express.doc/info/exp/ae/cejb_bindingsejbfp.html
- switch to use EJB 2.1, where you can override it per bean
- introduce a heartbeat in the app, that will call bean once a few minutes.

It is very strange that you are hitting this timeout, as it means that client 
has not called the bean for very long time.
SFSBs usually act as Facade to the application, so they should be limited in 
number and called quite often.

To respond to this post, please click the following link:



Unsubscribe via the "binocular" icon on the web

WebSphere Application Server: Re: EJB Activation Error after EJB Timeout

[dWForums]

Author:
RBS8_Amitesh_Sharma

Message:
Hi QAS, Thankyou very for the reply.

I have below EJB spec reference from " O'Reilly Enterprise JavaBeans, 3.0 5th 
Edition ebook"
<<

When an EJB server needs to conserve resources, it can evict stateful session 
beans from memory. When a bean is evicted, its conversational state is 
serialized to secondary storage. *When a client invokes a method on the EJB 
object, a new stateful session bean instance is instantiated and populated with 
the state from the initial bean.*

Since a stateful bean class does not have to be serializable, the exact 
mechanism for activating and passivating stateful beans is up to the vendor.
>>

I am using EJB 3.0 Stateful Beans

And as per above spec WAS should return a new instance to the same Client with 
prev state(Even if the Client was idle for some time). And the application 
should not throw exception/or App state should not get destroyed.  

If application state would start getting destroyed. 
And there's no way out to even extend the EJB3 (Feature Pack) timeout. I think 
there's no use of having EJB3 support on WAS 6.1)

It's looking like a Web Sphere specification implementation mismatch/problem. 

Please confirm if my understanding is correct.

To respond to this post, please click the following link:



Unsubscribe via the "binocular" icon on the web

Subscription probe for MoPo-L - please ignore

[LISTSERV.AMERICAN.EDU LISTSERV Server (15.5)]

Wed, 9 Mar 2011 06:00:08

This message is  a "probe" for your subscription to  the MoPo-L list. You
do not need to  take any action to remain subscribed to  the list, and in
particular you should  not reply to this message. Simply  discard it now,
or  read on  if  you would  like  to  know more  about  how this  probing
mechanism works.

A  "probe"  is a  message  like  the one  you  are  reading, sent  to  an
individual subscriber  and tagged  with a  special signature  to uniquely
identify  this  particular  subscriber  (you can  probably  not  see  the
signature because it is in the  mail headers). If the subscriber's e-mail
address is no longer valid, the  message will be returned to LISTSERV and
the faulty  address will be  removed from  the list. If  the subscriber's
address is still valid, the message will not bounce and the user will not
be deleted.

The main advantage  of this technique is that it  can be fully automated;
the list owner does not need to read a single delivery error. For a large
or active  list, the manpower  savings can  be tremendous. In  fact, some
lists are  so large that it  is virtually impossible to  process delivery
errors manually. Another advantage is that the special, unique signatures
make it possible to accurately process delivery errors that are otherwise
unintelligible, even to an experienced technical person.

The  drawback,  however,  is  that  this  method  lacks  flexibility  and
forgiveness. Since the Internet does not provide a reliable mechanism for
probing an  e-mail address without  actually delivering a message  to the
human  recipient, the  subscribers  need to  be  inconvenienced with  yet
another "junk message". And, unlike  a human list owner, LISTSERV follows
a number of  simple rules in determining when and  whether to terminate a
subscription. In  particular, a common  problem with automatic  probes is
mail gateways  that return a delivery  error, but do deliver  the message
anyway.  LISTSERV  has no  way  to  know that  the  message  was in  fact
delivered, and in most cases the subscriber is not aware of the existence
of these  "false" error reports.  If this  happens to you,  LISTSERV will
send you  another message with a  copy of the delivery  error returned by
your mail system, so that you can show it to your technical people.

Subscription probe for MoPo-L - please ignore

[LISTSERV.AMERICAN.EDU LISTSERV Server (16.0)]

Wed, 9 Mar 2011 06:00:00

This message is  a "probe" for your subscription to  the MoPo-L list. You
do not  need to  take any  action to  remain subscribed  to the  list. In
particular, you should not reply to  this message. Simply discard it now,
or  read on  if  you would  like  to  know more  about  how this  probing
mechanism works.

A  "probe"  is a  message  like  the one  you  are  reading, sent  to  an
individual subscriber  and tagged  with a  special signature  to uniquely
identify  this  particular subscriber  (you  may  not see  the  signature
because it is in the mail  headers). If the subscriber's email address is
no longer  valid, then the message  will be returned to  LISTSERV and the
faulty address will be removed from the list. If the subscriber's address
is still valid, then the message will not bounce and the user will not be
deleted.