2012-05-02 115 views
2

現在、Tomcat 6クラスタ環境のliferay 6.0.6を設定中です。 セッション複製を持つ4つのノード。スティッキーセッションはありません。重大度:マネージャ[localhost#/]:TCPチャネル経由でメッセージを受信できません

だから、このサイトで提供されるガイド以下の私は、次のようでした:

のwebapps/confに/ context.xmlに追加: のwebapps/ROOT/WEB-INF/web.xmlのが追加されます。ファイルの先頭に、最初のブラケットの後。 また、すべてのカスタム・ポートレットweb.xmlにdistributableを追加しました。 setenv.shで :-Djava.net.preferIPv6Addresses = falseを-Djava.net.preferIPv4Stack = trueを

Webアプリケーション/ CONF/server.xmlの

<Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcatA" /> 

tomcatA/B/C/Dはaccrossノード。

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" 
    channelSendOptions="8"> 
    <Manager className="org.apache.catalina.ha.session.DeltaManager" 
     expireSessionsOnShutdown="false" notifyListenersOnReplication="true" /> 
    <Channel className="org.apache.catalina.tribes.group.GroupChannel"> 
     <Membership className="org.apache.catalina.tribes.membership.McastService" 
      address="228.0.0.10" port="45564" frequency="500" dropTime="3000" /> 
     <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver" 
      address="auto" port="4000" autoBind="100" selectorTimeout="5000" 
      maxThreads="6" /> 
     <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> 
      <Transport 
       className="org.apache.catalina.tribes.transport.nio.PooledParallelSender" timeout="30000" /> 
     </Sender> 
     <Interceptor 
      className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector" /> 
      <Interceptor 
      className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor" /> 
    </Channel> 
    <Valve className="org.apache.catalina.ha.tcp.ReplicationValve" 
     filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.css;.*\.txt;" /> 
    <ClusterListener 
     className="org.apache.catalina.ha.session.ClusterSessionListener" /> 
</Cluster> 

起動時に、各ノードが互いを検出して動作するように見えます。

SEVERE: Manager [localhost#/]: Unable to receive message through TCP channel 
java.lang.IllegalStateException: setAttribute: Session already invalidated 
    at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1326) 
    at org.apache.catalina.ha.session.DeltaSession.setAttribute(DeltaSession.java:594) 
    at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:164) 
    at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1487) 
    at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1437) 
    at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1171) 
    at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:92) 
    at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:901) 
    at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:882) 
    at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:269) 
    at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) 
    at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:110) 
    at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) 
    at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) 
     at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:241) 
    at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:225) 
    at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:188) 
    at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:91) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 
    at java.lang.Thread.run(Thread.java:662) 

私liferay-ext.properties:誰かがWebContentのを修正しようとしたときしかし、我々は、エラーを取得アイブ氏はまた、すべてのノード上のJSPを作成し

cluster.link.autodetect.address=www.google.com:80 
lucene.replicate.write=true 
cluster.link.enabled=true 

net.sf.ehcache.configurationResourceName=/cache/hibernate-clustered.xml 
ehcache.multi.vm.config.location=/cache/liferay-multi-vm-clustered.xml 

<td> 
    Session ID</td> 
<td><%= session.getId() %></td> 
<% session.setAttribute("abc","abc"); %> 
</tr> 
<tr> 
<td> 
    Created on</td> 
    <td><%= new java.util.Date(session.getCreationTime()).toString() %></td> 
</tr> 
</table> 
</body> 
</html> 

同じユーザーで私はサーバーを切り替えることができ、セッションは問題なく複製されているようです。しかし、私はまだliftayの何かを変更する行くstacktraceを取得します。

私は今、しばらくの間立ち往生しています。 すべてのサーバーとJVM時刻がNTPサーバーと正しく同期されていることを確認しました。 ポートがブロックされていません。サーバーはインターネットにアクセスできません。 これらはすべてVM上で実行されています。

誰もが間違って何をしているアイデアがありますか?

ありがとうございました。

答えて

6

いくつかの注意事項...

1)あなたは報告されている問題がchannelSendOptionsのために使用されている値としなければならないことがあります。

SEVERE: Manager [localhost#/]: Unable to receive message through TCP channel java.lang.IllegalStateException: setAttribute: Session already invalidated

あなたの現在の構成は の値にchannelSendOptionsを設定しています。つまり、ノード間でメッセージが送信されると、非同期で送信されます。これはスピードには優れていますが、データが不整然に到着する可能性があります[1]。

エラーメッセージは、セッション属性を更新するメッセージを受信したことを示していますが、更新するセッションは既に無効化(つまり削除)されています。このエラーが発生する一般的な理由は、メッセージが順不同で受信されたためです。多くの場合

、あなたはの値にchannelSendOptionsを設定することで、この問題を修正することができます。これにより、メッセージが同期して送信され、注文が保証されます。 [1]

からhttps://tomcat.apache.org/tomcat-6.0-doc/config/cluster.html#Attributes

2)もう一つの可能​​性は、可能性が低いにもかかわらず、あなたがTomcatの中にバグをヒットしていることです。使用しているTomcatの特定のバージョンはリストされていませんが、最新のTomcat 6.0.xバージョンにアップグレードすることもお勧めです。

3.)「セッションはスティッキセッションなしでは複製できません」と指定しました。これは間違っています。セッションの複製とセッションの粘着性は、2つの別々のプロセスです。それらはしばしば一緒に使用されますが、セッションレプリケーションはスティッキセッションを必要とせず、スティッキセッションはセッションレプリケーションを必要としません。

セッション複製(Tomcatによる「クラスタリング」と呼ばれる)は、複数のTomcatサーバー間でセッションデータを複製するプロセスです。セッションデータが複数のノードにまたがってレプリケートされる場合、すべてのセッションデータが同じであるため、ユーザーの要求がどのノードに送信されるかは問題になりません。

セッション「スティッキー」は、ロードバランサによって実行され、ロードバランサのプロセスで、1つのセッションが常に同じバックエンドTomcatサーバーに送信されるようにします。

たとえば、ロードバランサはTomcat Server Aに要求を送信し、その要求によってセッションが作成されます。セッション・スティッキーを有効にすると、ロード・バランサは同じセッションIDを持つすべての追加要求をTomcatサーバーAに送信します。セッションがないか、セッションが異なる他の要求は、引き続き通常どおりロード・バランシングされます。

チョコレートとピーナッツバターのように、スティッキセッションとセッションレプリケーションはよく一緒に使用されますが、必須条件ではありません。基本的なロード・バランシングはスティッキー・セッションのみで実行できますが、バックエンドのTomcatノードで障害が発生した場合にセッション・データが失われます。セッション複製とスティッキーセッションの両方で、バックエンドのTomcatノードの1つで障害が発生しても、ユーザーは影響を受けません。それらは自動的にロードバランサによって別のノードにルーティングされ、そのノードにはユーザーのセッションデータのコピーが格納されます。

+0

説明をお願い致します。物事をもっとはっきりさせる。 – SpikerTom

関連する問題