jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <asm...@yahoo.com>
Subject Re: Timeout for determining a remote cache is down, and to reconnect
Date Tue, 27 Jun 2006 17:25:44 GMT
You can set the timeout for the client, using this
parameter:

jcs.auxiliary.RC.attributes.RmiSocketFactoryTimeoutMillis=30000

I need to update the docs.  If the value is -1, the
cache will not try to set it.  So, if you specify -1,
the default RMI timeout of 60 seconds? will be used. 
If you don't specify anything, then the cache uses a
default of 10 seconds.

    /** The default timeout for the custom RMI socket
facfory */
    public static final int
DEFAULT_RMI_SOCKET_FACTORY_TIMEOUT_MILLIS = 10000;

There is no way to configure the reconnect interval. 
I will make it configurable.  You should also run a
failover remote cache server in a cluster.



--- Paul.Lewandowski@kohls.com wrote:

> Some additional information:
> 
> I looked at my std-err logs after the run and saw
> the following sequences
> of messages:
> 
> [ERROR] RemoteCache - -Disabling remote cache due to
> error Failed to put
> 195717::147343 to 1862_object
> IDToAttributes
> [ERROR] RemoteCache - -Disabling remote cache due to
> error Failed to put
> 159971247 to 1862_ProductIDTo
> Promotions
> [ERROR] RemoteCache - -java.rmi.UnmarshalException:
> Error unmarshaling
> return header: java.io.Interrup
> tedIOException: Read timed out
> [ERROR] RemoteCache - -Disabling remote cache due to
> error Failed to get
> 194388175 from 1862_contentID
> ToContent
> [ERROR] RemoteCache - -java.rmi.UnmarshalException:
> Error unmarshaling
> return header: java.io.Interrup
> tedIOException: Read timed out
> [ERROR] RemoteCache - -java.rmi.UnmarshalException:
> Error unmarshaling
> return header: java.io.Interrup
> tedIOException: Read timed out
> [WARN] RemoteCacheFailoverRunner - -Failed to
> reconnect to primary server.
> Cache failover runner is go
> ing to sleep for 20000 milliseconds.
> [WARN] RemoteCacheFailoverRunner - -Failed to
> reconnect to primary server.
> Cache failover runner is go
> ing to sleep for 20000 milliseconds.
> [WARN] RemoteCacheFailoverRunner - -Failed to
> reconnect to primary server.
> Cache failover runner is go
> ing to sleep for 20000 milliseconds.
> 
> There were three GC's on the remote caching server
> (3.5 sec, 10.5 sec. and
> 11.2 sec) that coincide with the 3 occasions of this
> type of error message.
> 
> Paul
> 
> 
>                                                     
>                       
>              Paul.Lewandowski@                      
>                       
>              kohls.com                              
>                       
>                                                     
>                    To 
>              06/27/2006 11:14          "JCS Users
> List"                    
>              AM                       
> <jcs-users@jakarta.apache.org>      
>                                                     
>                    cc 
>                                                     
>                       
>              Please respond to                      
>               Subject 
>              "JCS Users List"          Timeout for
> determining a remote    
>              <jcs-users@jakart         cache is
> down, and to reconnect     
>                a.apache.org>                        
>                       
>                                                     
>                       
>                                                     
>                       
>                                                     
>                       
>                                                     
>                       
>                                                     
>                       
> 
> 
> 
> 
> In my testing I have occasionally seen my
> application (client side)
> determine that the remote cahce server is down when
> in fact it is not.
> Also, it then enters a retry cycle of 20000
> milliseconds before
> reconnecting.
> 
> What I believe may be happening is that because we
> are using a 2 gig remote
> cache when a large GC cycle occurs perhaps the
> client side thinks that the
> remote server is down depending on what the value is
> that determines this.
> Can you please explain this algorithm and if it can
> be user configurable?
> 
> Also, 20000 milliseconds is too long for a retry
> under heavy production
> loads.  Is this retry interval also configurable?
> 
> Thanks.
> 
> Paul
> 
> 
> 
> CONFIDENTIALITY NOTICE:
> This is a transmission from Kohl's Department
> Stores, Inc.
> and may contain information which is confidential
> and proprietary.
> If you are not the addressee, any disclosure,
> copying or distribution or
> use of the contents of this message is expressly
> prohibited.
> If you have received this transmission in error,
> please destroy it and
> notify us immediately at 262-703-7000.
> 
> CAUTION:
> Internet and e-mail communications are Kohl's
> property and Kohl's reserves
> the right to retrieve and read any message created,
> sent and received.
> Kohl's reserves the right to monitor messages by
> authorized Kohl's
> Associates at any time
> without any further consent.
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jcs-users-help@jakarta.apache.org
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: 
> This is a transmission from Kohl's Department
> Stores, Inc.
> and may contain information which is confidential
> and proprietary.
> If you are not the addressee, any disclosure,
> copying or distribution or use of the contents of
> this message is expressly prohibited.
> If you have received this transmission in error,
> please destroy it and notify us immediately at
> 262-703-7000.
> 
> CAUTION:
> Internet and e-mail communications are Kohl's
> property and Kohl's reserves the right to retrieve
> and read any message created, sent and received. 
> Kohl's reserves the right to monitor messages by
> authorized Kohl's Associates at any time
> without any further consent.
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jcs-users-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org


Mime
View raw message