[JBoss JIRA] Created: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
8:52 a.m.
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Manik Surtani
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:54 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Jacek Gerbszt updated ISPN-1182:
--------------------------------
Forum Reference: http://community.jboss.org/message/609574
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Manik Surtani
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:56 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Jacek Gerbszt updated ISPN-1182:
--------------------------------
Attachment: hotrodexception.txt
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Manik Surtani
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:32 a.m.
New subject: [JBoss JIRA] Assigned: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Manik Surtani reassigned ISPN-1182:
-----------------------------------
Assignee: Galder Zamarreño (was: Manik Surtani)
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR6
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:32 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Manik Surtani updated ISPN-1182:
--------------------------------
Fix Version/s: 5.0.0.CR6
Forum Reference: http://community.jboss.org/message/609574 (was:
http://community.jboss.org/message/609574)
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR6
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:09 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1182:
-----------------------------------
Fix Version/s: 5.0.0.CR7
(was: 5.0.0.CR6)
Forum Reference: http://community.jboss.org/message/609574 (was:
http://community.jboss.org/message/609574)
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR7
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:09 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1182:
----------------------------------------
Thanks Jacek! Apart from your suggestion, I think it might be a good time to implement
ISPN-448 which precisely avoids concurrent topology view update issues by delegating the
update to the coordinator.
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR7
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:22 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Jacek Gerbszt commented on ISPN-1182:
-------------------------------------
Yes, it would be lovely to see the solution for ISPN-448 in version 5.0.0.Final
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR7
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:24 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1182:
----------------------------------------
It shouldn't be hard to do cos I'm already doing something along the lines for
dealing with crashed members.
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR7
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:13 a.m.
New subject: [JBoss JIRA] Work started: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Work on ISPN-1182 started by Galder Zamarreño.
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR7
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:15 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1182:
----------------------------------------
@Jacek, I've done a further investigation about ISPN-448 and it's not as
straightforward to implement and so I think it's a bit too late in the dev cycle of
5.0.0 to develop it. So, the scope of this JIRA will be limited to fixing the issue
you're reporting.
By the way, remember that you can control the topology cache replication timeout and lock
timeout via infinispan.server.topology.repl_timeout and
infinispan.server.topology.lock_timeout properties respectively, and so you can maybe
tweak them if you expect concurrent startups.
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR7
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:43 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1182:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/395
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR7
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:01 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1182:
-----------------------------------
Fix Version/s: 5.0.0.CR6
(was: 5.0.0.CR7)
Git Pull Request: https://github.com/infinispan/infinispan/pull/395 (was:
https://github.com/infinispan/infinispan/pull/395)
Forum Reference: http://community.jboss.org/message/609574 (was:
http://community.jboss.org/message/609574)
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR6
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:24 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Jacek Gerbszt commented on ISPN-1182:
-------------------------------------
I've played with repl_timeout, but without good results - the exeption appears sooner,
but the node stops working as earlier. To overcome this issue, I've made a dirty patch
from the description above, and problem has gone (for now).
Thanks Galder for your work on the issue, I'm waiting for a release:)
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR6
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:49 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server
[
https://issues.jboss.org/browse/ISPN-1182?page=com.atlassian.jira.plugin....
]
Dan Berindei updated ISPN-1182:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
* Suspect and timeout exceptions are now handled when trying to update the topology
view on startup so that it can be retried.
* The amount of time to wait for topology to be updated is now configurable.
* Removing self from topology on stoppage is done with 0 lock timeout and silent
failure, to avoid blocking stop procedure. Crashed member detection listener can deal with
nodes having issues at stop time.
* Tests have been enhanced so that if a failure is received, the error message is
printed in the failure message, giving more clues about the error.
Failure after TimeoutException during the restart of HotRod Server
------------------------------------------------------------------
Key: ISPN-1182
URL: https://issues.jboss.org/browse/ISPN-1182
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.CR4
Reporter: Jacek Gerbszt
Assignee: Galder Zamarreño
Fix For: 5.0.0.CR6
Attachments: hotrodexception.txt
Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive
replication timeout exception, after which the node is unusable.
The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3
nodes try to replace the same element in cache at the same time, it's not a big
surprise, that they fall into some kind of deadlock, which is properly recognized and
broken after the timeout. But unfortunately the breaking exception is not handled and
stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView
like this:
var updated = false
try {
updated = topologyCache.replace("view", currentView, newView)
} catch {
case e: TimeoutException => logUnableToReplaceView
}
This time the exception will not be thrown from the containing closure and
updateTopologyView method will have the chance to replace the view again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5194
days inactive
5197
days old
infinispan-issues@lists.jboss.org
14 comments
4 participants
participants (4)
-
Dan Berindei (JIRA) -
Galder Zamarreño (JIRA)
-
Jacek Gerbszt (JIRA)
-
Manik Surtani (JIRA)