聚类不起作用 [英] Clustering doesn't work
问题描述
我使用前面的 apache 和 mod_jk 作为连接器为两个 tomcat 配置集群.我尝试了一个测试应用程序来检查配置，它工作正常.正在成功复制会话并且成功检测到故障转移.但是当我为我的实际应用尝试这个时，它不起作用.我在 httpd.conf 中进行了相应且非常仔细的修改.没有例外，日志中没有错误.我无法跟踪问题.最初我为特定的类获取 NotSerializableException 并且我使它们可序列化.现在也不例外，但如果托管 tomcat 关闭，即使集群的其他 tomcat 成员还活着，我仍然无法加载应用程序.你们能帮我吗.我可以理解，当您不确定问题时，很难提出解决方案.
I config clustering for two tomcat using apache at front and mod_jk as connector. I tried a test application to check the configuration and it works fine. Session are being successfully replicated and failover is detected successfully. But when i tried this for my actual application, it does not work. I made the modification in httpd.conf accordingly and very carefully. There is no exception,no error in the logs. I am unable to track the problem. Initially i was getting NotSerializableException for a particular classes and i made them serializable. Now there is no exception but still i am unable to load the application if the hosting tomcat is shutted down even when the other tomcat member of the cluster are alive. Can you guys please help me. I can understand it is quite tough to produce the solution when you are not sure of the problem.
推荐答案
所以您有 2 个服务，以相同的方式配置，除了一个正确故障转移而另一个没有?
So you have 2 services, configured the same way, except that one fails over correctly and the other doesn't?
当您看到看起来不可能的事情时，有一个通用的经验法则.这条规则是你没有看到你认为你看到的东西.通常是因为被戏称为 PEBKAC(键盘和椅子之间存在问题).真正令人沮丧的是，无论它多么明显，你可以盯着它看 100 次，它不会很明显，因为你看到的是你知道"的东西，而不是那里的东西.
There is a general rule of thumb when you're seeing something that looks impossible. And that rule is that you're not seeing what you think you are seeing. Frequently because of what is jokingly referred to as PEBKAC (Problem Exists Between Keyboard And Chair). The really frustrating thing is that, no matter how obvious it is, you can stare at it 100 times and it won't be obvious because you see what you "know" is there rather than what is there.
根据我的经验，有两种很好的方法可以解决此类问题.
In my experience there are two good ways to solve this kind of problem.
- 把它带给其他人，让他们找出你在做什么的不同之处.鉴于他们看到的是那里的东西，而不是你知道"的东西，他们经常会看到你看不到的东西.(在整个过程中，您也许有一天可以回报您的恩惠.)
- 从工作配置和非工作配置开始，然后开始平分"它们之间的路径，直到您得到一个最小差异，表明工作和非工作之间的区别.缩小这种差异，你要么知道要修复什么，要么就有一个测试用例给其他人.
很可能您需要遵循第二种方法.你可能不想 - 我从来没有 - 但它通常没有你想象的那么痛苦.您首先在测试系统上复制完整的应用程序，并证明您遇到了相同的故障.(如果没有，那么您开始仔细寻找生产和测试之间的差异.特别是查看操作系统版本、库版本等.)
Odds are that you'll need to follow the second approach. You probably don't want to - I never do - but it usually is less painful than you imagine. You start by replicating the full application on a test system, and demonstrating that you have the same failure. (If you don't, then you start looking, carefully, for differences between production and test. In particular look at things like operating system version, library versions, and the like.)
假设您有一个测试系统，请保存该配置.然后开始删除您认为与配置问题无关的大量实际应用程序，定期测试您是否走在正确的道路上.(并且每次都保存.)一旦你有了一个最小的应用程序，就开始尝试将它推向工作的测试应用程序.在某个地方，您会发现有所不同的变化.它可以在任何地方.一旦找到它，您通常就会确切地知道如何修复您的生产系统.或者，如果您不这样做，您就会清楚地了解您的问题.
Assuming that you have a test system, save that configuration. Then start ripping out large chunks of your actual application that you imagine have nothing to do with your configuration problems, testing periodically that you are on the right path. (And saving every time that you are.) Once you have a minimal application, start trying to walk it over towards the working test application. Somewhere you'll find a change that makes a difference. It could be anywhere. Once you have found it, you'll usually know exactly how to fix your production system. Or if you don't, you'll know your problem fairly clearly.
有时您会发现一个奇怪的错误.如果是这样，那么您应该开始尝试尽可能地简化所有内容，直到您有一个不错的错误报告要发送.
Sometimes you'll have found a weird bug. If so, then you should then start trying to simplify everything as much as possible until you have a nice bug report to send in.
这篇关于聚类不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
