• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • Communications Layer
  • hhuynh
  • Reporter: gbevin
  • June 10, 2008
  • 0
  • Watchers: 0
  • October 22, 2008
  • July 15, 2008

Description

When an L1’s connection is interrupted and re-established afterwards the following message is displayed on L2 when l1.reconnect is not enable. This message seems incorrect since the client was not from a previous run and the msg doesn’t say anything about the reconnect property:

2008-06-10 13:54:41,764 INFO - Unable to find communications stack. ConnectionID(1.410214551bd342d2b972a3c9a0a83754) not found. This is usually caused by a client from a prior run trying to illegally reconnect to the server. While that client is being rejected, everything else should proceed as normal.

Comments

Geert Bevin 2008-06-10

The same message is reported when a client reconnected when the timeout has already expired, again this doesn’t seem clear to me. In this case the message should indicate that the reconnect failed due to the timeout.

Fiona OShea 2008-06-10

Is this happening using a module (SNAPSHOT) or in a nightly trunk build. (or your personal trunk build).? thanks

Geert Bevin 2008-06-10

Personal trunk build of revision 8771

Fiona OShea 2008-06-12

Replace This is usually caused by a client from a prior run trying to illegally reconnect to the server.

with This is usually caused by a client that is not connected to the cluster (e.g. from a prior run).

Geert Bevin 2008-07-15

Changed the error message the be as such:

“2008-07-15 13:02:59,276 INFO - Unable to find communications stack. ConnectionID(0.2dc60bba42644657b816434ba2657461) not found. This is usually caused by a client that is not connected to the cluster. While that client is being rejected, everything else should proceed as normal. Some possible reasons for this situation might be: the client is from a previous run and can’t safely join this newer run; or the client couldn’t reconnect (configurable through several TC properties: ‘l2.l1reconnect.enabled’, ‘l2.l1reconnect.timeout.millis’, …)”

Gary Keim 2008-10-22

I am very confused by all of this. The facts as I see them are that with permanent-store, an orphaned client is capable of reconnecting to a restarted server cluster. So, when is l2.l1reconnect.enabled to be used? Is that only useful with temporary-swap-only persistence-mode?