[JBoss JIRA] Created: (JGRP-587) Lightweight FLUSH for state transfer
by Vladimir Blagojevic (JIRA)
Lightweight FLUSH for state transfer
------------------------------------
Key: JGRP-587
URL: http://jira.jboss.com/jira/browse/JGRP-587
Project: JGroups
Issue Type: Feature Request
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
Fix For: 2.7
We should investigate introduction of lightweight FLUSH in Multiplexer. Lightweight FLUSH would introduce stop-the-world model to only specific mux application leaving other mux applications unaffected. For example, if there are three mux applications A,B, and C and we need to FLUSH only application C, lightweight FLUSH would block all message sending for C only while applications A and B are unaffected.
--
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, 7 months
[JBoss JIRA] Resolved: (JGRP-180) Harden stack to prevent loss of intra-stack events
by Bela Ban (JIRA)
[ https://jira.jboss.org/jira/browse/JGRP-180?page=com.atlassian.jira.plugi... ]
Bela Ban resolved JGRP-180.
---------------------------
Resolution: Done
With the concurrent stack, we introduced return values for down() and up(), so now every sender of an event can decide for itself whether to resend the event or not.
> Harden stack to prevent loss of intra-stack events
> --------------------------------------------------
>
> Key: JGRP-180
> URL: https://jira.jboss.org/jira/browse/JGRP-180
> Project: JGroups
> Issue Type: Task
> Affects Versions: 2.2.8, 2.2.9, 2.2.9.1
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 2.x
>
>
> When an *intra-stack* event is lost, this can be serious (*inter-stack* message are simply retransmitted, so that is not critical).
> Losses are mainly caused by runtime exceptions, e.g. OutOfMemory exception (OOM), or resource problems, and to a lesser extent by program bugs.
> For example, when a user sends a message using Channel.send(), and there is an exception, then the user will simply send the message again, possibly after fixing the cause of the exception.
> However, for events such as VIEW_CHANGE that are multicast by the GMS protocol, a loss can be serious: in this case, the view would never be received !
> The same applies to the up direction: when NAKACK has successfully delivered a message, if that message is lost travelling between NAKACK and the Channel, then is serious (essentially loss of that message).
> So while these error situations don't occur very often, if they do occur, they have serious consequences.
> SOLUTION:
> - Do nothing for user messages: Channel.send() throws an exception, user has to resend message. Note that in http://jira.jboss.com/jira/browse/JGRP-179, we made retransmission handling atomic, e.g. if there is an exception, there will *not* be a gap in the seqnos for NAKACK and UNICAST
> - Provide either a pass{Up/Down}Reliably() method or an Event with a RELIABLE field, such that this event needs to be acked. The sender (e.g. GMS on a VIEW_CHANGE) sends down the message and waits until it gets an ACK, which could be sent by the NAKACK or UNICAST protocols, or as last resort by the transport (TP). If the ACK is not received within M ms, the event is resent.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Created: (JGRP-520) OOM with RpcDispatcher
by Bela Ban (JIRA)
OOM with RpcDispatcher
----------------------
Key: JGRP-520
URL: http://jira.jboss.com/jira/browse/JGRP-520
Project: JGroups
Issue Type: Bug
Environment: 1.5.0_10-b03;Sun Microsystems Inc.;mixed mode, sharing;Windows;32 bit JVM
Windows Server 2003 Standard x64
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Critical
Fix For: 2.5
Attachments: SimpleClusterManager.java
[from Patrick Eger]
Attempting to isolate the problem, I ran into a (probably unrelated)
other OutOfMemoryError problem with JGroups 1.5b2. Got an
OutOfMemoryError after ~3 minutes of running the attached
TestJGroups.java, 3 instances in parallel. Also attached is the stack
config and a couple YJP views of the HPROF dump as generated by
-XX:+HeapDumpOnOutOfMemoryError.
The test is looping single-threaded, calling a remote method via
RpcDispatcher every 100 ms which returns a few KB String. Looks like all
the memory is retained instances of org.jgroups.stack.IpAddress
(~1,000,000 for a ~3 minute run (seems like a lot?)), held by
pbcast.NAKACK.sent_msgs. I have the HPROF dump if you need, its about 15
megs zipped so I assumed would not make it through the mail filters.
Is this a real OOME or is it a stack configuration/tuning thing? I have
used the default UDP config, but with increased thread_pool and
oob_thread_pool sizes.
Options
-----------------------------------------
-agentlib:yjpagent
-server
-Xmx64m
-XX:+HeapDumpOnOutOfMemoryError
-Dcom.sun.management.jmxremote
-Dpeer_cluster_manager.XXXTestClusterXXX.jgroups_config=C:\tmp\testcfg.x
ml
--
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, 7 months
[JBoss JIRA] Created: (JGRP-875) XMP parsing: variable substitution should be the same as in JBoss
by Bela Ban (JIRA)
XMP parsing: variable substitution should be the same as in JBoss
-----------------------------------------------------------------
Key: JGRP-875
URL: https://jira.jboss.org/jira/browse/JGRP-875
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.6.8, 2.7
In JBoss' XML, we can say
value="${var1,var2,var3:8900}", which means that the value is that of system property var1 if set, else that of var2 if set, else that of var3 if set, or else 8900.
JGroups doesn't support a list of variables, it supports only one variable. Change this to make it parse the format supported by JBoss, too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Created: (JBAS-6312) NullPointerException in org.jboss.varia.scheduler.XMLScheduleProvider and org.jboss.varia.scheduler.DBScheduleProvider when calling stopProviding
by Adam Bonkowski (JIRA)
NullPointerException in org.jboss.varia.scheduler.XMLScheduleProvider and org.jboss.varia.scheduler.DBScheduleProvider when calling stopProviding
-------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-6312
URL: https://jira.jboss.org/jira/browse/JBAS-6312
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Adam Bonkowski
Priority: Minor
When calling stopProviding more than once in these classes (for example deploying MBean, stopProviding(), startProviding(), undeploying MBean) a NullPointerException occurs.
Example stack trace:
javax.management.RuntimeMBeanException
at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:176)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163)
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.varia.scheduler.AbstractScheduleProvider.stopScheduleProviderService(AbstractScheduleProvider.java:227)
at org.jboss.varia.scheduler.AbstractScheduleProvider.stopService(AbstractScheduleProvider.java:202)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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.stop(Unknown Source)
at org.jboss.system.ServiceController.stop(ServiceController.java:508)
at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.stop(Unknown Source)
at org.jboss.deployment.SARDeployer.stop(SARDeployer.java:336)
at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667)
at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638)
at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:632)
at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:615)
at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy9.undeploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.undeploy(URLDeploymentScanner.java:450)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:570)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
Caused by: javax.management.RuntimeMBeanException
at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:176)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163)
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.varia.scheduler.ScheduleManager.unregisterProvider(ScheduleManager.java:242)
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:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
... 52 more
Caused by: javax.management.RuntimeMBeanException
at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:176)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163)
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.varia.scheduler.AbstractScheduleProvider.removeSchedule(AbstractScheduleProvider.java:163)
at org.jboss.varia.scheduler.XMLScheduleProvider.stopProviding(XMLScheduleProvider.java:239)
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:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
... 62 more
Caused by: java.lang.NullPointerException
at org.jboss.varia.scheduler.ScheduleManager.removeSchedule(ScheduleManager.java:332)
at sun.reflect.GeneratedMethodAccessor153.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
... 73 more
Looking at the implementation:
/**
* Stops the Provider from providing causing
* the provider to remove the Schedule
*
* @jmx:managed-operation
*/
public void stopProviding() {
Iterator i = mIDList.iterator();
while( i.hasNext() ) {
Integer lID = (Integer) i.next();
try {
removeSchedule( lID.intValue() );
}
catch( JMException jme ) {
log.error( "Could not remove Schedule in stop providing", jme );
}
}
}
it seems to lack i.remove() while iterating. During next stopProviding() call a non-existing schedule is being removed and NullPointerException is thrown. As a result no further schedules are removed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Created: (JGRP-739) check all bind_address against NetworkInterface.getByInetAddress() to see if it exists on the machine
by Michael Newcomb (JIRA)
check all bind_address against NetworkInterface.getByInetAddress() to see if it exists on the machine
-----------------------------------------------------------------------------------------------------
Key: JGRP-739
URL: http://jira.jboss.com/jira/browse/JGRP-739
Project: JGroups
Issue Type: Feature Request
Reporter: Michael Newcomb
Assigned To: Bela Ban
Priority: Minor
Could you add a check in Util.getBindAddress() that checks the bind_addr against NetworkInterface.getByInetAddress() and throws some sort of exception if no NetworkInterface is returned?
I set my bind_addr via a database parameter and if the user mistakenly assigns the wrong bind address, it doesn't show up until UDP.createEphemeralDatagramSocket() when the localPort goes over 65535 because each attempt to create a DatagramSocket with the inet address that is not a local address throws a SocketException (actually a BindException) which is caught but ignored. When localPort finally goes over 65535 it throws an IllegalArgumentException.
So, a check in Util.getBindAddress() to see if the bind_addr is even available on the machine would lead to a failure in the configuration stage (setProperties).
As a side question, doesn't creating a DatagramSocket with port=0 guarantee an ephemeral port? Is it necessary to 'scan' for one? Perhaps a failure from the initial attempt with port=0 would wait a few ms and then try again with port=0?
--
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, 7 months
