[JBoss JIRA] Created: (JGRP-553) Deadlock in FD protocol
by Bela Ban (JIRA)
Deadlock in FD protocol
-----------------------
Key: JGRP-553
URL: http://jira.jboss.com/jira/browse/JGRP-553
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4.1 SP4, 2.5
[submitted by Oleg Afanasiev (xbalanque at mail.ru)]
I found the following deadlock in protocol FD:
Found one Java-level deadlock:
=============================
"IncomingPacketHandler (channel=+slee_5servers)":
waiting to lock monitor 0x0000002b80fcd488 (object 0x0000002aa7788330, a java.lang.Object),
which is held by "Timer-4"
"Timer-4":
waiting to lock monitor 0x0000002b80fcd848 (object 0x0000002aa778adc8, a java.util.Vector),
which is held by "IncomingPacketHandler (channel=+slee_5servers)"
Java stack information for the threads listed above:
===================================================
"IncomingPacketHandler (channel=+slee_5servers)":
at org.jgroups.protocols.FD$Broadcaster.stopBroadcastTask (FD.java:602)
- waiting to lock <0x0000002aa7788330> (a java.lang.Object)
at org.jgroups.protocols.FD$Broadcaster.adjustSuspectedMembers (FD.java:649)
- locked <0x0000002aa778adc8> (a java.util.Vector)
at org.jgroups.protocols.FD.down(FD.java:318)
- locked <0x0000002aa7083c08> (a org.jgroups.protocols.FD)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499)
at org.jgroups.stack.Protocol.passDown(Protocol.java:533)
at org.jgroups.stack.Protocol.down(Protocol.java:559)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499)
at org.jgroups.stack.Protocol.passDown(Protocol.java:533)
at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:480)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499)
at org.jgroups.stack.Protocol.passDown(Protocol.java:533)
at org.jgroups.protocols.UNICAST.down(UNICAST.java:391)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499)
at org.jgroups.stack.Protocol.passDown(Protocol.java:533)
at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:287)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499)
at org.jgroups.stack.Protocol.passDown(Protocol.java:533)
at org.jgroups.protocols.VIEW_SYNC.down(VIEW_SYNC.java:166)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499)
at org.jgroups.stack.Protocol.passDown(Protocol.java:533)
at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:509)
- locked <0x0000002aa76ee7e0> (a org.jgroups.Membership)
at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422)
at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange (CoordGmsImpl.java:568)
...
"Timer-4":
at java.util.Vector.clone(Vector.java:638)
- waiting to lock <0x0000002aa778adc8> (a java.util.Vector)
at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask (FD.java:587)
- locked <0x0000002aa7788330> (a java.lang.Object)
at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember (FD.java:621)
at org.jgroups.protocols.FD$Monitor.run(FD.java:541)
at org.jgroups.util.TimeScheduler$TaskWrapper.run (TimeScheduler.java:204)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
The source of deadlock is the following piece of code:
If addSuspectedMember from own timer task and adjustSuspectedMembers
from GMS arrive simultaneously, we've got a deadlock on method clone().
protected final class Broadcaster {
final Vector suspected_mbrs=new Vector(7);
BroadcastTask task=null;
private final Object bcast_mutex=new Object();
Vector getSuspectedMembers() {
return suspected_mbrs;
}
/**
* Starts a new task, or - if already running - adds the
argument to the running task.
* @param suspect
*/
private void startBroadcastTask(Address suspect) {
synchronized(bcast_mutex) {
if(task == null || task.cancelled()) {
task=new BroadcastTask((Vector)
suspected_mbrs.clone()); /// this clone method is synchronized and
causes a deadlock
task.addSuspectedMember(suspect);
task.run(); // run immediately the first time
timer.add(task); // then every timeout
milliseconds, until cancelled
if(log.isTraceEnabled())
log.trace("BroadcastTask started");
}
else {
task.addSuspectedMember(suspect);
}
}
}
private void stopBroadcastTask() {
synchronized(bcast_mutex) {
if(task != null) {
task.stop();
task=null;
}
}
}
/** Adds a suspected member. Starts the task if not yet
running */
protected void addSuspectedMember(Address mbr) {
if(mbr == null) return;
if(!members.contains(mbr)) return;
boolean added=false;
synchronized(suspected_mbrs) {
if(!suspected_mbrs.contains(mbr)) {
suspected_mbrs.addElement(mbr);
added=true;
}
}
if(added)
startBroadcastTask(mbr);
}
void removeSuspectedMember(Address suspected_mbr) {
if(suspected_mbr == null) return;
if(log.isDebugEnabled()) log.debug("member is " +
suspected_mbr);
synchronized(suspected_mbrs) {
suspected_mbrs.removeElement(suspected_mbr);
if(suspected_mbrs.isEmpty())
stopBroadcastTask();
}
}
void removeAll() {
synchronized(suspected_mbrs) {
suspected_mbrs.removeAllElements();
stopBroadcastTask();
}
}
/** Removes all elements from suspected_mbrs that are
<em>not</em> in the new membership */
void adjustSuspectedMembers(List new_mbrship) {
if(new_mbrship == null || new_mbrship.isEmpty()) return;
StringBuffer sb=new StringBuffer();
synchronized(suspected_mbrs) {
sb.append("suspected_mbrs: ").append(suspected_mbrs);
suspected_mbrs.retainAll(new_mbrship);
if(suspected_mbrs.isEmpty())
stopBroadcastTask();
sb.append(", after adjustment: ").append
(suspected_mbrs);
log.debug(sb.toString());
}
}
}
The proposed solution is to move startBroadcastTask() back inside
synchronized(suspected_mbrs)
block in the addSuspectedMember method. So it'll look like:
/** Adds a suspected member. Starts the task if not yet
running */
protected void addSuspectedMember(Address mbr) {
if(mbr == null) return;
if(!members.contains(mbr)) return;
boolean added=false;
synchronized(suspected_mbrs) {
if(!suspected_mbrs.contains(mbr)) {
suspected_mbrs.addElement(mbr);
startBroadcastTask(mbr);
}
}
}
Or we may use a separate monitor for operations that use
suspected_mbrs to synchronize.
--
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
19 years
[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
19 years
[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
19 years
[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
19 years
[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
19 years
[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
19 years
[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
19 years