[JBoss JIRA] Created: (JGRP-552) TCP_NIO gives ClassCastException in cluster-service.xml
by Ramil Israfilov (JIRA)
TCP_NIO gives ClassCastException in cluster-service.xml
-------------------------------------------------------
Key: JGRP-552
URL: http://jira.jboss.com/jira/browse/JGRP-552
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1 SP3
Reporter: Ramil Israfilov
Assigned To: Bela Ban
I'm trying to replace UDP protocol in cluster-service.xml in jboss4.2.1GA version.
I commented out <UDP> and <PING> elements and put there:
<TCP_NIO bind_addr="${jboss.bind.address}" recv_buf_size="20000000" send_buf_size="640000" loopback="false"
discard_incompatible_packets="true" max_bundle_size="64000" max_bundle_timeout="30"
use_incoming_packet_handler="true" use_outgoing_packet_handler="false" down_thread="false"
up_thread="false" enable_bundling="true" start_port="7800" use_send_queues="false" sock_conn_timeout="300"
skip_suspected_members="true" reader_threads="8" writer_threads="8" processor_threads="8"
processor_minThreads="8" processor_maxThreads="8" processor_queueSize="100"/>
<MPING timeout="2000" bind_addr="${jboss.bind.address}" mcast_addr="${jboss.partition.udpGroup:228.1.2.3}"
mcast_port="${jboss.hapartition.mcast_port:45566}" ip_ttl="${jgroups.udp.ip_ttl:2}" num_initial_members="1"/>
During startup jboss gives exception:
2007-07-10 11:55:39,026 ERROR [org.jgroups.jmx.JmxConfigurator] failed creating a JMX wrapper instance for TCP_NIO(local address
: null)
java.lang.ClassCastException: org.jgroups.protocols.TCP_NIO
at org.jgroups.jmx.protocols.TCP.attachProtocol(TCP.java:22)
at org.jgroups.jmx.protocols.TCP_NIO.attachProtocol(TCP_NIO.java:19)
at org.jgroups.jmx.JmxConfigurator.findProtocol(JmxConfigurator.java:152)
at org.jgroups.jmx.JmxConfigurator.registerProtocols(JmxConfigurator.java:96)
at org.jboss.ha.framework.server.ClusterPartition.registerChannelInJmx(ClusterPartition.java:553)
at org.jboss.ha.framework.server.ClusterPartition.createService(ClusterPartition.java:341)
at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:243)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.create(Unknown Source)
at org.jboss.system.ServiceController.create(ServiceController.java:330)
at org.jboss.system.ServiceController.create(ServiceController.java:273)
...
It could be workarouned by usage of <TCP>, but as I saw in wiki TCP is not recommended and will not be supported in future.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 3 months
[JBoss JIRA] Created: (JBAS-4458) NoClassDefFoundError: org/jboss/jmx/adaptor/control/OpResultInfo when trying to stop jboss:service=TransactionManager
by Peter Gymoese (JIRA)
NoClassDefFoundError: org/jboss/jmx/adaptor/control/OpResultInfo when trying to stop jboss:service=TransactionManager
---------------------------------------------------------------------------------------------------------------------
Key: JBAS-4458
URL: http://jira.jboss.com/jira/browse/JBAS-4458
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transaction Manager
Affects Versions: JBossAS-4.2.0.GA
Environment: JBoss [Trinity] 4.2.0.GA (build: SVNTag=JBoss_4_2_0_GA date=200705111440)
Java HotSpot(TM) Server VM 1.5.0_11-b03,Sun Microsystems Inc.
Windows XP Prof.
Reporter: Peter Gymoese
Assigned To: Adrian Brock
This problem is easily reproduced. Install a complete clean JBoss 4.2 GA, start it and open the web-console - then try to stop the TransactionManager service, the following exception is raised, saying that the class org/jboss/jmx/adaptor/control/OpResultInfo is missing:
16:49:43,733 INFO [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED shutting down.
16:49:43,733 INFO [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED paused.
16:49:43,733 INFO [SimpleThreadPool] There are still 28 worker threads active. See javadoc runInThread(Runnable) for a possible explanation
16:49:43,733 INFO [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED shutdown complete.
16:49:43,733 INFO [WebappClassLoader] Illegal access: this web application instance has been stopped already. Could not load org.jboss.jmx.adaptor.control.OpResultInfo. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1244)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:259)
at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
16:49:43,749 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
java.lang.NoClassDefFoundError: org/jboss/jmx/adaptor/control/OpResultInfo
at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:259)
at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
I actually found the problem trying to change the transaction timeout runtime from an application. This worked in 3.2.8 SP1 but not in 4.2 GA, the same goes for RunInVMRecoveryManager - the following exception is raised trying to do it!
16:55:34,923 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
javax.management.RuntimeMBeanException
at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:176)
at org.jboss.mx.interceptor.AttributeDispatcher.invoke(AttributeDispatcher.java:140)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:103)
at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:76)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:461)
at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:608)
at org.jboss.jmx.adaptor.control.Server.setAttributes(Server.java:206)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.updateAttributes(HtmlAdaptorServlet.java:236)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:98)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalStateException: Cannot set transaction timeout once MBean has started
at com.arjuna.ats.jbossatx.jta.TransactionManagerService.setTransactionTimeout(TransactionManagerService.java:318)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.AttributeDispatcher.invoke(AttributeDispatcher.java:136)
... 31 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 3 months
[JBoss JIRA] Closed: (JBAS-2813) UIL2 does not close client sockets when the service is shutdown
by Adrian Brock (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2813?page=all ]
Adrian Brock closed JBAS-2813.
------------------------------
Fix Version/s: JBossAS-4.2.0.CR2
Resolution: Done
Updated to record which version of 4.2.x this was fixed in.
> UIL2 does not close client sockets when the service is shutdown
> ---------------------------------------------------------------
>
> Key: JBAS-2813
> URL: http://jira.jboss.com/jira/browse/JBAS-2813
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMS service
> Affects Versions: JBossAS-4.0.4RC1, JBossAS-3.2.8 Final
> Reporter: Adrian Brock
> Assigned To: Adrian Brock
> Fix For: JBossAS-4.2.0.CR2, JBossAS-5.0.0.Beta1, JBossAS-4.0.4.CR2, JBossAS-3.2.8.SP1
>
>
> The UIL2 service does not close sockets when the service is stopped.
> Normally this is not a problem because the JBoss process ends which does close the sockets.
> There are two parts to this fix:
> 1) JMSDestinationManager.stopServer()
> needs to iterate over connected clients and invoke the client IL's close method
> 2) UIL2 needs to implement close()
> The other ILs also need checking to make sure they implement close properly when the
> server (through stopping service) unilaterally ends the client's connection.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 3 months
[JBoss JIRA] Reopened: (JBAS-2813) UIL2 does not close client sockets when the service is shutdown
by Adrian Brock (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2813?page=all ]
Adrian Brock reopened JBAS-2813:
--------------------------------
> UIL2 does not close client sockets when the service is shutdown
> ---------------------------------------------------------------
>
> Key: JBAS-2813
> URL: http://jira.jboss.com/jira/browse/JBAS-2813
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMS service
> Affects Versions: JBossAS-4.0.4RC1, JBossAS-3.2.8 Final
> Reporter: Adrian Brock
> Assigned To: Adrian Brock
> Fix For: JBossAS-3.2.8.SP1, JBossAS-4.0.4.CR2, JBossAS-5.0.0.Beta1
>
>
> The UIL2 service does not close sockets when the service is stopped.
> Normally this is not a problem because the JBoss process ends which does close the sockets.
> There are two parts to this fix:
> 1) JMSDestinationManager.stopServer()
> needs to iterate over connected clients and invoke the client IL's close method
> 2) UIL2 needs to implement close()
> The other ILs also need checking to make sure they implement close properly when the
> server (through stopping service) unilaterally ends the client's connection.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 3 months
[JBoss JIRA] Created: (JBPORTAL-1559) HibernateMembershipModuleImpl assignUsers method : wrong error message
by Antoine Herzog (JIRA)
HibernateMembershipModuleImpl assignUsers method : wrong error message
----------------------------------------------------------------------
Key: JBPORTAL-1559
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1559
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Identity
Affects Versions: 2.6 Final
Environment: JBP2.6.0
Reporter: Antoine Herzog
Priority: Minor
Fix For: 2.6.1 Final
In HibernateMembershipModuleImpl
In method : public void assignUsers(Role role, Set users) throws IdentityException
the exception messages have been copied from the assignRole, and are confusing (user/role inversion) :
"User is not a HibernateRoleImpl user"
should be : "Role is not a HibernateRoleImpl role"
and
"Only HibernateUserImpl roles can be accepted"
should be : "Only HibernateUserImpl users can be accepted"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 3 months
[JBoss JIRA] Created: (JGRP-550) When a new member joins a group and requests the cache from the coordinator, it always fails first time
by Dipak Kothari (JIRA)
When a new member joins a group and requests the cache from the coordinator, it always fails first time
-------------------------------------------------------------------------------------------------------
Key: JGRP-550
URL: http://jira.jboss.com/jira/browse/JGRP-550
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5
Environment: Example code was run on Windows
Reporter: Dipak Kothari
Assigned To: Bela Ban
Attachments: example.zip
Service A starts - becomes coordinator. After it has started properly, Service B is started. As part of the Join, it
1) Gets the members using TCPPING
2) Determines the coordinator
3) Joins
4) Applies view change via the installView. This re-adjusts the members and closes any connections that are no longer members (so the connection to service A is removed).
5) Requests the cache from the coordinator. Service A on response to this tries to send the cache but fails as peer connection has been closed. It tries twice and removes connection. Service B timeout and tries again and this time it is successful. This happens each time. I don't think this should happen - it should return the cache as it knowns where it needs to be sent to.
I have added additional trace statements (these start with APM:) to show the flow for my understanding. I have deliberately set the get_cache_timeout to a high number to highlight this. I have also provided source and protocol properties in the zip for convenience. There are 2 logs from the run I carried out: cord.log is the coordinator log and cord1.log is second services' log.
Please let me know if there is a work around or a fix I can apply. If I have mis-configured the properties then please advise how to rectify it.
To run the example, run the bat script passing in the service name. Note, the service name needs to be unique as the log name is based on this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 3 months
[JBoss JIRA] Created: (JBPORTAL-1545) HibernateUserModuleImpl.removeUser potential unwanted NPE
by Antoine Herzog (JIRA)
HibernateUserModuleImpl.removeUser potential unwanted NPE
---------------------------------------------------------
Key: JBPORTAL-1545
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1545
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Identity
Affects Versions: 2.6 Final
Environment: 2.6.0GA
Reporter: Antoine Herzog
Priority: Minor
Fix For: 2.6.1 Final
In HibernateUserModuleImpl
In the removeUser method
code is :
String userName = user.getUserName();
if (user == null)
{
throw new NoSuchUserException("No such user " + id);
}
session.delete(user);
session.flush();
//fire events
fireUserDestroyedEvent(id, userName);
This first line will throw a NPE, and the null test is done after.
The code should be :
if (user == null)
{
throw new NoSuchUserException("No such user " + id);
}
String userName = user.getUserName();
session.delete(user);
session.flush();
//fire events
fireUserDestroyedEvent(id, userName);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 3 months
[JBoss JIRA] Created: (JGRP-551) FD does not restart monitor task after unsuspect event
by Rodrigo Faria (JIRA)
FD does not restart monitor task after unsuspect event
------------------------------------------------------
Key: JGRP-551
URL: http://jira.jboss.com/jira/browse/JGRP-551
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1 SP3, 2.5
Environment: Found in JGroups 2.4.1SP3 and 2.5RC1. Used Windows XP but seems to be plataform independent.
Reporter: Rodrigo Faria
Assigned To: Bela Ban
I reproduced this with 3 members, but may be possible with only 2. FD and VERIFY_SUSPECT must be present in the configuration. The steps to reproduce are the following:
- jgroups with 3 members online
- disconnect a member (not the coord)
- wait until the member disconnected suspects the other two (FD will generate the suspect event for both), but before it changes its view (before VERIFY_SUSPECT confirms the suspection), and reconnect it.
When both suspection occured, FD will have stopped its monitor task (since it had no pingable members). When the unsuspect event is generated, the FD will not restart its monitor task. As a consequence of this, if the other members removed this member from their view, this member will not be shunned (assuming shun=true in FD), since FD is not sending heartbeat request . This member's FD also will not be able to identify any failure, since its monitor task is stopped (I think it will be restarted only if something triggers a VIEW_CHANGE).
I tried to change the unsuspect method in FD to update the pingable_members and ping_dest and restart the monitor task (something like the implementation for processing a VIEW_CHANGE event) and it seemed to correct this problem.
I also noticed ping_dest is not being sychronized in the monitor task. Instead of using a synchronized block (to prevent a bottleneck), I think it should be copied to a local variable so it is thread_safe (would prevent checking one member and suspecting another because the ping_dest changed). I did not reproduced this, I just noticed it looking at the source code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 3 months