[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2237:
--------------------------------
The {{VERIFY_SUSPECT}} timeout of 10s sometimes prevented a member from getting removed from the view *before* the other member was restarted. The other issue was that your {{port_range}} is 0, which means not all members will be probed for, ie. discovered sometimes.
I attached the correct config, run a diff to your config to see the differences.
> The single node in the cluster not become a coordinator after coordinator leave.
> --------------------------------------------------------------------------------
>
> Key: JGRP-2237
> URL: https://issues.jboss.org/browse/JGRP-2237
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.2, 4.0.8
> Reporter: kfir avraham
> Assignee: Bela Ban
> Priority: Minor
> Attachments: test.xml
>
>
> I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator.
> When the first one is rejoin, he could not determine coordinator and select new one from the nodes list.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.
by kfir avraham (JIRA)
[ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.... ]
kfir avraham updated JGRP-2237:
-------------------------------
Description:
I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator.
When the first one is rejoin, he could not determine coordinator and select new one from the nodes list.
was:
I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second on is not become a coordinator.
when the first one is rejoin, he could not determine coordinator and select new one from the nodes list.
> The single node in the cluster not become a coordinator after coordinator leave.
> --------------------------------------------------------------------------------
>
> Key: JGRP-2237
> URL: https://issues.jboss.org/browse/JGRP-2237
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.2, 4.0.8
> Reporter: kfir avraham
> Assignee: Bela Ban
> Priority: Minor
>
> I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator.
> When the first one is rejoin, he could not determine coordinator and select new one from the nodes list.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.
by kfir avraham (JIRA)
[ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.... ]
kfir avraham commented on JGRP-2237:
------------------------------------
*+Configuration:+*
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups-3.6.xsd">
<TCP
bind_addr="${jgroups.tcp.address: [node FQDN]}"
bind_port="${jgroups.tcp.port:[node port]}"
port_range="0"
recv_buf_size="20m"
send_buf_size="640k"
max_bundle_size="31k"
enable_diagnostics="false"
thread_naming_pattern="pl"
thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="30"
thread_pool.keep_alive_time="60000"
/>
<!-- In the following, modify the initial_hosts attribute with hostnames & port (if default is modified) of master & standby servers -->
<!-- Ergonomics, new in JGroups 2.11, are disabled by default in TCPPING until JGRP-1253 is resolved -->
<TCPPING initial_hosts="[current node FQDN and port], [second node FQDN and port]"
port_range="0"
ergonomics="false"
/>
<FD_SOCK/>
<FD_ALL interval="3000" timeout="10000"/>
<MERGE3 />
<VERIFY_SUSPECT timeout="10000"/>
<pbcast.NAKACK2 use_mcast_xmit="false"
xmit_interval="1000"
xmit_table_num_rows="100"
xmit_table_msgs_per_row="10000"
xmit_table_max_compaction_time="10000"/>
<UNICAST3 xmit_interval="500"
xmit_table_num_rows="20"
xmit_table_msgs_per_row="10000"
xmit_table_max_compaction_time="10000"
conn_expiry_timeout="0"/>
<pbcast.STABLE stability_delay="500" desired_avg_gossip="5000" max_bytes="1m"/>
<pbcast.GMS print_local_addr="true" print_physical_addrs="true" join_timeout="3000" view_bundling="true"/>
<tom.TOA/> <!-- the TOA is only needed for total order transactions-->
<MFC max_credits="2m" min_threshold="0.40"/>
<FRAG2 frag_size="30k"/>
<RSVP timeout="60000" resend_interval="500" ack_on_delivery="false" />
<CENTRAL_LOCK/>
</config>
> The single node in the cluster not become a coordinator after coordinator leave.
> --------------------------------------------------------------------------------
>
> Key: JGRP-2237
> URL: https://issues.jboss.org/browse/JGRP-2237
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.2, 4.0.8
> Reporter: kfir avraham
> Assignee: Bela Ban
> Priority: Minor
>
> I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second on is not become a coordinator.
> when the first one is rejoin, he could not determine coordinator and select new one from the nodes list.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.
by kfir avraham (JIRA)
kfir avraham created JGRP-2237:
----------------------------------
Summary: The single node in the cluster not become a coordinator after coordinator leave.
Key: JGRP-2237
URL: https://issues.jboss.org/browse/JGRP-2237
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.8, 4.0.2
Reporter: kfir avraham
Assignee: Bela Ban
Priority: Minor
I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second on is not become a coordinator.
when the first one is rejoin, he could not determine coordinator and select new one from the nodes list.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9175) IJ000311: Throwable from unregister connection
by charles ghislain (JIRA)
[ https://issues.jboss.org/browse/WFLY-9175?page=com.atlassian.jira.plugin.... ]
charles ghislain commented on WFLY-9175:
----------------------------------------
FYI, https://access.redhat.com/solutions/1446673 suggests the root cause may be that the application code attempt to close a connection already closed, or one that is no longer owned by the application.
They suggest to enable TRACE logging for the com.arjuna, org.jboss.jca, and org.jboss.as.connector in order to diagnose the problematic call.
They suggest to ensure that application code does not cache any connection handles, nor share them between multiple threads.
> IJ000311: Throwable from unregister connection
> ----------------------------------------------
>
> Key: WFLY-9175
> URL: https://issues.jboss.org/browse/WFLY-9175
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: junot dutra lira
> Assignee: Flavia Rainone
>
> I have a java web project with jsf + primefaces running in wildfly, noticed some error messages in the log, I did not find any solution to this, it follows a part of the log:
> 2017-08-03 10:55:56,747 INFO [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (default task-56) IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@4d230e4e
> at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.unregisterConnection(CachedConnectionManagerImpl.java:408)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.connectionClosed(TxConnectionListener.java:645)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:596)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256)
> at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.closeConnection(DatasourceConnectionProviderImpl.java:127)
> at org.hibernate.internal.NonContextualJdbcConnectionAccess.releaseConnection(NonContextualJdbcConnectionAccess.java:46)
> at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:189)
> at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:155)
> at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:282)
> at org.hibernate.internal.SessionImpl.afterOperation(SessionImpl.java:534)
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1455)
> at org.hibernate.query.internal.AbstractProducedQuery.doList(AbstractProducedQuery.java:1402)
> at org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1374)
> at org.hibernate.query.internal.AbstractProducedQuery.getSingleResult(AbstractProducedQuery.java:1420)
> at org.hibernate.query.criteria.internal.compile.CriteriaQueryTypeQueryAdapter.getSingleResult(CriteriaQueryTypeQueryAdapter.java:59)
> at br.gov.ms.drap.dao.armamento.ArmaDao.buscaArmaById(ArmaDao.java:58)
> at br.gov.ms.drap.bean.armamento.ArmaManagedBean.consultar(ArmaManagedBean.java:119)
> 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 javax.el.ELUtil.invokeMethod(ELUtil.java:300)
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:415)
> at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
> at com.sun.el.parser.AstValue.invoke(AstValue.java:285)
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
> at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:147)
> at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
> at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:814)
> at javax.faces.component.UICommand.broadcast(UICommand.java:300)
> at javax.faces.component.UIData.broadcast(UIData.java:1108)
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:78)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at br.gov.ms.drap.filter.FiltroLogin.doFilter(FiltroLogin.java:128)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3434) ERROR in logs while using vault in system properties
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3434?page=com.atlassian.jira.plugi... ]
Chao Wang commented on WFCORE-3434:
-----------------------------------
The false error is logged in [RuntimeVaultReader.java|https://github.com/wildfly/wildfly-core/pull/2087...]. This happens because previous fix for WFCORE-2182 decides to log a message instead of throwing an exception in [ServerLogger.java|https://github.com/wildfly/wildfly-core/pull/2087/files...]
When there is system properties needs vault resolution, this kind resolution exception needs to be caught in SystemPropertyAddHandler which gives a second chance to resolve system property later in SystemPropertyDeferredProcessor after vault is being created. Looking at comments before log the error, it's supposed to help user to understand reason for next NoSuchItemException, However this causes confusion error to terminal when someone uses VALUT value in system properties as they're actually resolved by SystemPropertyDeferredProcessor.
I think we can remove the error and let SystemPropertyAddHandler handles failures as before, or update log level to DEBUG, in that case, people should still be aware of the possible debug message before applying SystemPropertyDeferredProcessor.
> ERROR in logs while using vault in system properties
> ----------------------------------------------------
>
> Key: WFCORE-3434
> URL: https://issues.jboss.org/browse/WFCORE-3434
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 4.0.0.Alpha3
> Environment: JBoss EAP 7.1 Beta
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> Getting below ERROR message in server.log when *Picketbox Vault expressions* used in *system properties*.:
> {code:java}
> ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0230: Vault is not initialized; resolution of vault expressions is not possible
> {code}
> Below expressions are resolving fine but due to race condition this ERROR message got printed in the logs.
> {code:java}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/home/jboss-eap-7.1/vault/vault.keystore"/>
> <property name="javax.net.ssl.trustStorePassword" value="${VAULT::datasource::password::1}"/>
> </system-properties>
> <vault>
> <vault-option name="KEYSTORE_URL" value="/home/jboss-eap-7.1/vault/vault.keystore"/>
> <vault-option name="KEYSTORE_PASSWORD" value="MASK-2GAtdnlXL8H"/>
> <vault-option name="KEYSTORE_ALIAS" value="vault"/>
> <vault-option name="SALT" value="12345678"/>
> <vault-option name="ITERATION_COUNT" value="44"/>
> <vault-option name="ENC_FILE_DIR" value="/home/jboss-eap-7.1/vault/"/>
> </vault>
> {code}
> Expression is actually resolving to the correct value and that can be check using below CLI command :
> {code:java}
> /core-service=platform-mbean/type=runtime:read-attribute(name=system-properties).
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (JGRP-2236) UNICAST max_xmit_req_size doesn't work
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2236?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2236.
----------------------------
Resolution: Done
> UNICAST max_xmit_req_size doesn't work
> --------------------------------------
>
> Key: JGRP-2236
> URL: https://issues.jboss.org/browse/JGRP-2236
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Fix For: 3.6.15, 4.0.9
>
>
> UNICAST3 sets max_xmit_req_size to avoid requesting too many messages to fit into the maximum message size.
> But the check is implemented incorrectly, so it is not effective.
> JGRP000029: node1: failed sending message to node2 (120314 bytes): java.io.IOException: Message too long, headers: UNICAST3: XMIT_REQ, seqno=0, TP: [cluster_name=cluster]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months