मेरे पास एक मौजूदा Red Hat सर्वर पर जेबॉस 4.2.2 के साथ चल रही एक वेबसाइट है। मैं एक दूसरा सर्वर स्थापित कर रहा हूं ताकि क्लस्टर्ड जोड़ी हो (जो तब लोड-संतुलित हो)। हालांकि, मैं उन्हें सफलतापूर्वक क्लस्टर करने के लिए नहीं मिल सकता। मैं जो क्लस्टरिंग समर्थन भी शामिल है यह का एक संशोधित संस्करण का उपयोग कर रहा हूँ -जेबॉस 4.2.2 नोड्स क्लस्टर से शुरू होते हैं तो एक दूसरे को संदेह करते हैं
run.sh -c default -b 0.0.0.0
(मैं 'डिफ़ॉल्ट' विन्यास बॉक्स से बाहर क्लस्टरिंग का समर्थन नहीं करता पता:
मौजूदा सर्वर के साथ JBoss शुरू होता है ।) जब मैं एक ही कमांड के साथ दूसरा जेबॉस उदाहरण शुरू करता हूं, तो यह पहले को ध्यान दिए बिना अपने स्वयं के क्लस्टर बनाता है। दोनों एक ही विभाजन नाम और मल्टीकास्ट पता और बंदरगाह का उपयोग करते हैं।
मैंने मैकटाइसेवरटेस्ट और McastSenderTest प्रोग्रामों को यह जांचने की कोशिश की कि मशीन मल्टीकास्ट पर संवाद कर सकती है; वो कर सकते हैं।
मैं तो http://docs.jboss.org/jbossas/docs/Clustering_Guide/beta422/html/ch07s07s07.html पर जानकारी देखा करते हुए कहा कि JGroups करने के लिए सभी इंटरफेस बाध्य नहीं कर सकते हैं, और इसके बजाय डिफ़ॉल्ट इंटरफ़ेस को बांधता है; तो संभवतः यह 127.0.0.1 को बाध्यकारी था, और इस प्रकार संदेश प्राप्त नहीं कर रहा था। तो बजाय मैं आंतरिक IP उपयोग करने के लिए JGroups बताने के लिए उदाहरणों सेट:
run.sh -c default -b 0.0.0.0 -Djgroups.bind_addr=10.51.1.131
run.sh -c default -b 0.0.0.0 -Djgroups.bind_addr=10.51.1.141
(.131, मौजूदा सर्वर है .141 नए सर्वर है)।
नोड्स अब एक दूसरे को नोटिस करते हैं और क्लस्टर बनाते हैं - पहले। हालांकि, .ear को तैनात करने का प्रयास करते समय, सर्वर लॉग यह कहता है:
2010-08-07 22:26:39,321 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:46294 (own address=10.51.1.141:47629)
2010-08-07 22:26:45,412 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48733; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
2010-08-07 22:26:49,324 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:46294 (own address=10.51.1.141:47629)
2010-08-07 22:26:49,324 DEBUG [org.jgroups.protocols.FD] heartbeat missing from 10.51.1.131:46294 (number=0)
2010-08-07 22:26:49,529 DEBUG [org.jgroups.protocols.MERGE2] initial_mbrs=[[own_addr=10.51.1.141:60365, coord_addr=10.51.1.141:60365, is_server=true]]
2010-08-07 22:26:52,092 WARN [org.jboss.cache.TreeCache] replication failure with method_call optimisticPrepare; id:18; Args: (arg[0] = GlobalTransaction:<10.51.1.131:46294>:5421085 ...) exception org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/Yudu_ear,Yudu-ejb_jar,Yudu-ejbPU/com/yudu/ejb/entity, caller=GlobalTransaction:<10.51.1.131:46294>:5421085, lock=read owners=[GlobalTransaction:<10.51.1.131:46294>:5421081] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=0)
... और .ear तैनात करने में विफल रहता है।
यदि मैं ejb3-entity-cache-service.xml में CPLMode को REPL_SYNC से LOCAL में बदलता हूं, तो .ear सही ढंग से तैनात करता है, हालांकि निश्चित रूप से इकाई कैश प्रतिकृति नहीं होती है। हालांकि, लॉग अभी भी एक ही समस्या के दिलचस्प संकेत दिखाता है।
ऐसा लगता है कि:
- पहले नए नोड मौजूदा एक पाता है और एक क्लस्टर
- तो एफडी चेकों असफल निर्माण करता है, और विफलताओं की एक निर्धारित संख्या के बाद नए नोड क्लस्टर से विभाजन और एक
- का अपना क्लस्टर बनाता है, फिर इसे फिर से मिल जाता है, फिर से क्लस्टर और इस बार एफडी चेक काम करता है। लॉग फ़ाइल की
प्रासंगिक बिट्स:
2010-08-07 23:47:07,423 INFO [org.jgroups.protocols.UDP] socket information: local_addr=10.51.1.141:35666, mcast_addr=228.1.2.3:45566, bind_addr=/10.51.1.141, ttl=2 sock: bound to 10.51.1.141:35666, receive buffer size=131071, send buffer size=131071 mcast_recv_sock: bound to 0.0.0.0:45566, send buffer size=131071, receive buffer size=131071 mcast_send_sock: bound to 10.51.1.141:59196, send buffer size=131071, receive buffer size=131071
2010-08-07 23:47:07,431 DEBUG [org.jgroups.protocols.UDP] created unicast receiver thread
2010-08-07 23:47:09,445 DEBUG [org.jgroups.protocols.pbcast.GMS] initial_mbrs are [[own_addr=10.51.1.131:48888, coord_addr=10.51.1.131:48888, is_server=true]]
2010-08-07 23:47:09,446 DEBUG [org.jgroups.protocols.pbcast.GMS] election results: {10.51.1.131:48888=1}
2010-08-07 23:47:09,446 DEBUG [org.jgroups.protocols.pbcast.GMS] sending handleJoin(10.51.1.141:35666) to 10.51.1.131:48888
2010-08-07 23:47:09,751 DEBUG [org.jgroups.protocols.pbcast.GMS] [10.51.1.141:35666]: JoinRsp=[10.51.1.131:48888|61] [10.51.1.131:48888, 10.51.1.141:35666] [size=2]
2010-08-07 23:47:09,752 DEBUG [org.jgroups.protocols.pbcast.GMS] new_view=[10.51.1.131:48888|61] [10.51.1.131:48888, 10.51.1.141:35666]
...
2010-08-07 23:47:10,047 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Number of cluster members: 2
2010-08-07 23:47:10,047 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Other members: 1
...
2010-08-07 23:47:20,034 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666)
2010-08-07 23:47:30,037 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666)
2010-08-07 23:47:30,038 DEBUG [org.jgroups.protocols.FD] heartbeat missing from 10.51.1.131:48888 (number=0)
2010-08-07 23:47:40,040 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666)
2010-08-07 23:47:40,040 DEBUG [org.jgroups.protocols.FD] heartbeat missing from 10.51.1.131:48888 (number=1)
...
2010-08-07 23:48:19,758 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48888; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
2010-08-07 23:48:20,054 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666)
2010-08-07 23:48:20,055 DEBUG [org.jgroups.protocols.FD] [10.51.1.141:35666]: received no heartbeat ack from 10.51.1.131:48888 for 6 times (60000 milliseconds), suspecting it
2010-08-07 23:48:20,058 DEBUG [org.jgroups.protocols.FD] broadcasting SUSPECT message [suspected_mbrs=[10.51.1.131:48888]] to group
...
2010-08-07 23:48:21,691 DEBUG [org.jgroups.protocols.pbcast.NAKACK] removing 10.51.1.131:48888 from received_msgs (not member anymore)
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] I am (127.0.0.1:1099) received membershipChanged event:
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] Dead members: 0 ([])
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] New Members : 0 ([])
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] All Members : 1 ([127.0.0.1:1099])
...
2010-08-07 23:49:59,793 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48888; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
2010-08-07 23:50:09,796 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48888; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
2010-08-07 23:50:19,144 DEBUG [org.jgroups.protocols.FD] Recevied Ack. is invalid (was from: 10.51.1.131:48888),
2010-08-07 23:50:19,144 DEBUG [org.jgroups.protocols.FD] Recevied Ack. is invalid (was from: 10.51.1.131:48888),
...
2010-08-07 23:50:21,791 DEBUG [org.jgroups.protocols.pbcast.GMS] new=[10.51.1.131:48902], suspected=[], leaving=[], new view: [10.51.1.141:35666|63] [10.51.1.141:35666, 10.51.1.131:48902]
...
2010-08-07 23:50:21,792 DEBUG [org.jgroups.protocols.pbcast.GMS] view=[10.51.1.141:35666|63] [10.51.1.141:35666, 10.51.1.131:48902]
2010-08-07 23:50:21,792 DEBUG [org.jgroups.protocols.pbcast.GMS] [local_addr=10.51.1.141:35666] view is [10.51.1.141:35666|63] [10.51.1.141:35666, 10.51.1.131:48902]
2010-08-07 23:50:21,822 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.DefaultPartition] New cluster view for partition DefaultPartition (id: 63, delta: 1) : [127.0.0.1:1099, 127.0.0.1:1099]
2010-08-07 23:50:21,822 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] membership changed from 1 to 2
...
2010-08-07 23:50:31,825 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48902 (own address=10.51.1.141:35666)
2010-08-07 23:50:31,832 DEBUG [org.jgroups.protocols.FD] received ack from 10.51.1.131:48902
लेकिन मैं एक नुकसान में हूँ समझने के लिए क्यों एफडी चेकों पहली बार दौर असफल; और हालांकि यह अंततः दूसरे नोड के साथ क्लस्टर प्रतीत होता है, प्रारंभिक विफलता तैनाती को गड़बड़ करने के लिए पर्याप्त प्रतीत होती है जब यह इकाई स्थिति साझा करने का प्रयास करती है, और इस तरह इसे वास्तव में उपयोगी तरीके से काम करने से रोकती है।
यदि कोई इस पर प्रकाश डाल सकता है तो मैं बहुत आभारी रहूंगा!
यह सुनिश्चित करने के लिए एक परेशानीपूर्ण समस्या है। मुझे लगता है कि आप JBoss 4.2.2 और एक अनुकूलित सर्वर कॉन्फ़िगरेशन का उपयोग कर रहे हैं, लेकिन क्या आप इसे JBoss 4.2.3 (जिसमें कुछ jgroups परिवर्तन शामिल हैं) और/या "सभी" कॉन्फ़िगरेशन के साथ पुन: बना सकते हैं? – pra
कस्टमाइज़ किए गए कॉन्फ़िगरेशन का उद्देश्य उन बिट्स के बिना 'डिफ़ॉल्ट' और 'सभी' - यानी 'सब' के बीच एक समझौता होना है जिसका हम उपयोग नहीं कर रहे हैं। यह वैकल्पिक कॉन्फ़िगरेशन का प्रयास करने में सक्षम होने के लिए कुछ काम करेगा (क्योंकि मैं मौजूदा नोड के साथ स्वतंत्र रूप से गड़बड़ नहीं कर सकता, इसलिए तीसरे को जोड़ने की आवश्यकता होगी), लेकिन मैं देखूंगा कि मैं उनको कोशिश कर सकता हूं - धन्यवाद सुझाव। – minamikuni
मैं दृढ़ता से 'डिफ़ॉल्ट' कॉन्फ़िगरेशन में सामग्री जोड़ने के बजाय 'सभी' कॉन्फ़िगरेशन को काटने का सुझाव देता हूं। कुछ महत्वपूर्ण घटक को याद करना बहुत आसान है जो उपयोगी नहीं दिखते हैं। – skaffman