[JBoss JIRA] (WFLY-6779) Add WISE for Web console access
by R Searls (JIRA)
R Searls created WFLY-6779:
------------------------------
Summary: Add WISE for Web console access
Key: WFLY-6779
URL: https://issues.jboss.org/browse/WFLY-6779
Project: WildFly
Issue Type: Feature Request
Components: Web Console
Reporter: R Searls
Assignee: R Searls
Priority: Minor
Wise is a Java framework for easily invoking webservices, which can be used as base for zero-code webservice invocation applications. (see http://wise.jboss.org/)
Based upon Brian Stansberry's advise WISE is added to wfly using the "Mixed-Approach"
for adding a feature.
Once this is available in wfly. HAL can provide a link to it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6778) Each Undertow server should expose a unique instance-id
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6778?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-6778:
-----------------------------------
distinct name would be combination of instance-id & server name.
> Each Undertow server should expose a unique instance-id
> -------------------------------------------------------
>
> Key: WFLY-6778
> URL: https://issues.jboss.org/browse/WFLY-6778
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Currently, Undertow only exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct.
> Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6778) Each Undertow server should expose a unique instance-id
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-6778:
----------------------------------
Summary: Each Undertow server should expose a unique instance-id
Key: WFLY-6778
URL: https://issues.jboss.org/browse/WFLY-6778
Project: WildFly
Issue Type: Bug
Components: Clustering, Web (Undertow)
Affects Versions: 10.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Currently, Undertow only exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct.
Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (JBJCA-1325) Wrong condition when parsing ironjacamar.rollback_on_fatal_error property
by Martin Simka (JIRA)
Martin Simka created JBJCA-1325:
-----------------------------------
Summary: Wrong condition when parsing ironjacamar.rollback_on_fatal_error property
Key: JBJCA-1325
URL: https://issues.jboss.org/browse/JBJCA-1325
Project: IronJacamar
Issue Type: Bug
Affects Versions: WildFly/IronJacamar 1.3.4.Final
Reporter: Martin Simka
Assignee: Stefano Maestri
There is wrong condition in https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
{code:java}
value = SecurityActions.getSystemProperty("ironjacamar.rollback_on_fatal_error");
if (value != null && !value.trim().equals(""))
{
if ("true".equalsIgnoreCase(value) || "false".equalsIgnoreCase(value))
{
doSetRollbackOnly = Boolean.parseBoolean(value);
}
else
{
StringTokenizer st = new StringTokenizer(value, ",");
while (doDelistResource && st.hasMoreTokens()) // <-- should be while (doSetRollbackOnly ...
{
if (getPool().getName().equals(st.nextToken()))
doSetRollbackOnly = false;
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6777) Upgrade to OpenJPA impl compatible with JDK9
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-6777:
---------------------------------
Summary: Upgrade to OpenJPA impl compatible with JDK9
Key: WFLY-6777
URL: https://issues.jboss.org/browse/WFLY-6777
Project: WildFly
Issue Type: Sub-task
Components: JPA / Hibernate
Reporter: Tomaz Cerar
Assignee: Scott Marlow
Priority: Minor
OpenJPA tests currently hang our testsuite as serp bytecode enhancer that OpenJPA uses hangs the deployment.
For now test is not run on JDK9, but this should be re-enabled once there is release of openjpa that works fine with jdk9
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6762) Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6762?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6762:
------------------------------------
Is your JGroups traffic configured to use a loopback interface? This is the default. Disabling the "network" on your host won't actually disable this interface, as you are likely only disabling a non-loopback interface.
> Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6762
> URL: https://issues.jboss.org/browse/WFLY-6762
> Project: WildFly
> Issue Type: Quality Risk
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Blocker
>
> In your mail related to WFLY-6749 you has said the below :-
> **The default stack contains the following failure detection protocols:
> FD_SOCK
> FD_ALL
> These protocols are described here:
> http://www.jgroups.org/manual/index.html#FailureDetection
> I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
> e.g.
> <protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
> **************************************************************************************************
> Thanks for the quick response on WFLY-6749.
> Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
> The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
> However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
> Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
> Also we tried to test the same failover scenario by Shutting down/power off a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment.
> Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se...
> https://developer.jboss.org/thread/238135?tstart=0
> Thanks,
> Preeta
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (DROOLS-1186) Setting the planning variable nullable in nurserostering examples causes Drools NPE
by Jiri Locker (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1186?page=com.atlassian.jira.plugi... ]
Jiri Locker reopened DROOLS-1186:
---------------------------------
The NPE can be still reproduced, see PR#821.
> Setting the planning variable nullable in nurserostering examples causes Drools NPE
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1186
> URL: https://issues.jboss.org/browse/DROOLS-1186
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Environment: Windows 7 x 64, JDK 8u66, IDE netbeans 8.0.1.
> Reporter: Julio Bellon Aguilera
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 7.0.0.Beta1
>
> Attachments: PLANNER_488.patch
>
>
> If you set the planning variable to "nullable=true", firstable, causes a IllegalStateException.
> fixed that, causes the first NPE, and fixed that, causes other NPE unfixed:
> Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException:
> Caused by: java.lang.NullPointerException
> at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:778)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (DROOLS-1212) Input stream finalized or forced closed during server startup
by Fernando Machado (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1212?page=com.atlassian.jira.plugi... ]
Fernando Machado commented on DROOLS-1212:
------------------------------------------
Thank you [~psiroky] for your (super) fast response and fix. Please, feel free to close this issue if you want.
> Input stream finalized or forced closed during server startup
> -------------------------------------------------------------
>
> Key: DROOLS-1212
> URL: https://issues.jboss.org/browse/DROOLS-1212
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Glassfish 4.1.1
> Reporter: Fernando Machado
> Assignee: Petr Široký
> Fix For: 7.0.0.Beta1
>
>
> I'm getting some exceptions during GF4 startup related with _"Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace"_ and it seems similar to DROOLS-812.
> org.drools.template.parser.DefaultTemplateRuleBase.readKnowledgeBase(String)
> {code}
> private InternalKnowledgeBase readKnowledgeBase(String drl) {
> try {
> // logger.info(drl);
> // read in the source
> Reader source = new StringReader(drl);
> KnowledgeBuilderImpl builder = new KnowledgeBuilderImpl();
> builder.addPackageFromDrl(source);
> InternalKnowledgePackage pkg = builder.getPackage();
> // add the package to a rulebase (deploy the rule package).
> InternalKnowledgeBase kBase = (InternalKnowledgeBase) KnowledgeBaseFactory.newKnowledgeBase();
> kBase.addPackage(pkg);
> return kBase;
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Is related with:
> {noformat}
> [#|2016-06-15T13:51:07.671+0200|WARNING|glassfish 4.1|javax.enterprise.system.util|_ThreadID=74442;_ThreadName=RunLevelControllerThread-1465991462855;_TimeMillis=1465991467671;_LevelValue=900;_MessageID=NCLS-COMUTIL-00023;|Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace
> java.lang.Throwable
> at org.drools.template.parser.DefaultTemplateRuleBase.readKnowledgeBase(DefaultTemplateRuleBase.java:133)
> at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:56)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:50)
> at org.drools.template.ObjectDataCompiler.compile(ObjectDataCompiler.java:57)
> at com.mycompany.mypackage.MyClass.init(MyClass.java:xxx)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1035)
> at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
> at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
> at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
> at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
> at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
> at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
> at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
> at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:412)
> at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375)
> at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:2014)
> at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:468)
> at com.sun.ejb.containers.AbstractSingletonContainer.access$000(AbstractSingletonContainer.java:74)
> at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:647)
> at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:389)
> at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:219)
> at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:180)
> at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:158)
> ...
> {noformat}
> There is another class that is also throwing the same exception:
> {noformat}
> [#|2016-06-14T11:08:19.953+0200|WARNING|glassfish 4.1|javax.enterprise.system.util|_ThreadID=68093;_ThreadName=RunLevelControllerThread-1465895294550;_TimeMillis=1465895299953;_LevelValue=900;_MessageID=NCLS-COMUTIL-00023;|Input stream has been finalized or forced closed without being explicitly closed;
> stream instantiation reported in following stack trace
> java.lang.Throwable
> at com.sun.enterprise.loader.ASURLClassLoader$SentinelInputStream.<init>(ASURLClassLoader.java:1278)
> at com.sun.enterprise.loader.ASURLClassLoader$InternalJarURLConnection.getInputStream(ASURLClassLoader.java:1386)
> at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:238)
> at com.sun.enterprise.loader.ASURLClassLoader.getResourceAsStream(ASURLClassLoader.java:930)
> at java.lang.Class.getResourceAsStream(Class.java:2223)
> at org.eclipse.jdt.internal.compiler.parser.Parser.readReadableNameTable(Parser.java:719)
> at org.eclipse.jdt.internal.compiler.parser.Parser.initTables(Parser.java:615)
> at org.eclipse.jdt.internal.compiler.parser.Parser.<clinit>(Parser.java:124)
> at org.eclipse.jdt.internal.compiler.Compiler.initializeParser(Compiler.java:687)
> at org.eclipse.jdt.internal.compiler.Compiler.<init>(Compiler.java:285)
> at org.eclipse.jdt.internal.compiler.Compiler.<init>(Compiler.java:206)
> at org.drools.compiler.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:416)
> at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.compiler.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:417)
> at org.drools.compiler.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:61)
> at org.drools.compiler.compiler.PackageRegistry.compileAll(PackageRegistry.java:138)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAll(KnowledgeBuilderImpl.java:1314)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:953)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackage(KnowledgeBuilderImpl.java:944)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:363)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:339)
> at org.drools.template.parser.DefaultTemplateRuleBase.readKnowledgeBase(DefaultTemplateRuleBase.java:133)
> at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:56)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:50)
> at org.drools.template.ObjectDataCompiler.compile(ObjectDataCompiler.java:57)
> at com.mycompany.mypackage.MyClass.init(MyClass.java:xxx)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1035)
> at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
> at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
> at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
> at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
> at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
> at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
> at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
> at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:412)
> at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375)
> at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:2014)
> at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:468)
> at com.sun.ejb.containers.AbstractSingletonContainer.access$000(AbstractSingletonContainer.java:74)
> at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:647)
> at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:389)
> at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:219)
> at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:180)
> at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:158)
> at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:166)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6762) Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6762?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla updated WFLY-6762:
-----------------------------------
Summary: Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node). (was: Windows ennvironment: Wildfly failover test not working when network is disabled on a VM(Node) or by shutting down the VM (Node).)
> Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6762
> URL: https://issues.jboss.org/browse/WFLY-6762
> Project: WildFly
> Issue Type: Quality Risk
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Blocker
>
> In your mail related to WFLY-6749 you has said the below :-
> **The default stack contains the following failure detection protocols:
> FD_SOCK
> FD_ALL
> These protocols are described here:
> http://www.jgroups.org/manual/index.html#FailureDetection
> I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
> e.g.
> <protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
> **************************************************************************************************
> Thanks for the quick response on WFLY-6749.
> Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
> The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
> However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
> Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
> Also we tried to test the same failover scenario by Shutting down/power off a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment.
> Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se...
> https://developer.jboss.org/thread/238135?tstart=0
> Thanks,
> Preeta
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6762) Windows ennvironment: Wildfly failover test not working when network is disabled on a VM(Node) or by shutting down the VM (Node).
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6762?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla updated WFLY-6762:
-----------------------------------
Description:
In your mail related to WFLY-6749 you has said the below :-
**The default stack contains the following failure detection protocols:
FD_SOCK
FD_ALL
These protocols are described here:
http://www.jgroups.org/manual/index.html#FailureDetection
I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
e.g.
<protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
**************************************************************************************************
Thanks for the quick response on WFLY-6749.
Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
Also we tried to test the same failover scenario by Shutting down/power off a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment.
Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se...
https://developer.jboss.org/thread/238135?tstart=0
Thanks,
Preeta
was:
In your mail related to WFLY-6749 you has said the below :-
**The default stack contains the following failure detection protocols:
FD_SOCK
FD_ALL
These protocols are described here:
http://www.jgroups.org/manual/index.html#FailureDetection
I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
e.g.
<protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
**************************************************************************************************
Thanks for the quick response on WFLY-6749.
Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
Also we tried to test the same failover scenario by Shutting down a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment.
Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se...
https://developer.jboss.org/thread/238135?tstart=0
Thanks,
Preeta
> Windows ennvironment: Wildfly failover test not working when network is disabled on a VM(Node) or by shutting down the VM (Node).
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6762
> URL: https://issues.jboss.org/browse/WFLY-6762
> Project: WildFly
> Issue Type: Quality Risk
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Blocker
>
> In your mail related to WFLY-6749 you has said the below :-
> **The default stack contains the following failure detection protocols:
> FD_SOCK
> FD_ALL
> These protocols are described here:
> http://www.jgroups.org/manual/index.html#FailureDetection
> I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
> e.g.
> <protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
> **************************************************************************************************
> Thanks for the quick response on WFLY-6749.
> Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
> The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
> However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
> Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
> Also we tried to test the same failover scenario by Shutting down/power off a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment.
> Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se...
> https://developer.jboss.org/thread/238135?tstart=0
> Thanks,
> Preeta
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months