February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not clearing the crashed members

by Sibin Karnavar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.... ] Sibin Karnavar commented on JGRP-2245: -------------------------------------- I have tested it in AWS. Looks good when instances gets terminated. I am not able able to now see the TQ bundler timeout errors. Thanks for fixing it. > JGroup JDBC_PING is not clearing the crashed members > ---------------------------------------------------- > > Key: JGRP-2245 > URL: https://issues.jboss.org/browse/JGRP-2245 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.8 > Reporter: Sibin Karnavar > Assignee: Bela Ban > Fix For: 4.0.10 > > > 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated. > 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes. > 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable. > I think the issue is > handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table. > {code:java} > // remove all files which are not from the current members > protected void handleView(View new_view, View old_view, boolean coord_changed) { > if(is_coord) { > if(coord_changed) { > if(remove_all_data_on_view_change) > removeAll(cluster_name); > else if(remove_old_coords_on_view_change) { > Address old_coord=old_view != null? old_view.getCreator() : null; > if(old_coord != null) > remove(cluster_name, old_coord); > } > } > if(coord_changed || View.diff(old_view, new_view)[1].length > 0) { > writeAll(); > if(remove_all_data_on_view_change || remove_old_coords_on_view_change) > startInfoWriter(); > } > } > else if(coord_changed) // I'm no longer the coordinator > remove(cluster_name, local_addr); > } > {code} > 4) Because of the crashed members (non existing ip address), we are getting lot of socket timeouts > sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AG-51) Do't wrap null Statement / ResultSet

by Luis Barreiro (JIRA)

Luis Barreiro created AG-51: ------------------------------- Summary: Do't wrap null Statement / ResultSet Key: AG-51 URL: https://issues.jboss.org/browse/AG-51 Project: Agroal Issue Type: Bug Components: pool Affects Versions: 0.3 Reporter: Luis Barreiro Assignee: Luis Barreiro Fix For: 0.4 Do not create and return a wrapper for null Statement / ResultSet -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AG-50) Configure automatic deployment of snapshots on travis

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/AG-50?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-50. ----------------------------- Resolution: Done > Configure automatic deployment of snapshots on travis > ----------------------------------------------------- > > Key: AG-50 > URL: https://issues.jboss.org/browse/AG-50 > Project: Agroal > Issue Type: Task > Components: build > Affects Versions: 0.3 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Fix For: 0.4 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AG-50) Configure automatic deployment of snapshots on travis

by Luis Barreiro (JIRA)

Luis Barreiro created AG-50: ------------------------------- Summary: Configure automatic deployment of snapshots on travis Key: AG-50 URL: https://issues.jboss.org/browse/AG-50 Project: Agroal Issue Type: Task Components: build Affects Versions: 0.3 Reporter: Luis Barreiro Assignee: Luis Barreiro Fix For: 0.4 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9727) WildFly Randomly Terminates after 5-10 minutes

by Daniel Wiseman (JIRA)

[ https://issues.jboss.org/browse/WFLY-9727?page=com.atlassian.jira.plugin.... ] Daniel Wiseman commented on WFLY-9727: -------------------------------------- [~ctomc] Java version "1.8.0_131" > WildFly Randomly Terminates after 5-10 minutes > ---------------------------------------------- > > Key: WFLY-9727 > URL: https://issues.jboss.org/browse/WFLY-9727 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 10.0.0.Final > Environment: Running WildFly 10.x from within Eclipse Oxygen (4.7.2) on 2015 MacBook Pro running OS X El Capitan (10.11.6) > Reporter: Daniel Wiseman > Assignee: Jason Greene > Priority: Blocker > Original Estimate: 1 week > Remaining Estimate: 1 week > > I've been experiencing an odd intermittent issue on my WildFly server that has been running on my local system. Every other day or so my server will shutdown, without warning, after running for five to ten minutes from launch. The WildFly server logs contain no errors but the Eclipse logs output these two stack identical stack traces every time: > {{Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating > at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588) > at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354) > at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233) > at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291) > at org.xnio.FutureResult.setCancelled(FutureResult.java:98) > at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:492) > Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating > at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588) > at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354) > at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233) > at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291) > at org.xnio.FutureResult.setCancelled(FutureResult.java:98) > at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)}} > This issue will occur on every server start for an entire day and then the next day it won't happen at all. However, when it happens it makes debugging the software I write that runs of the server near impossible. Does anyone have any ideas what could be causing this issue? Let me know if you need more details, thanks! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1468) IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1468?page=com.atlassian.jira.plugin.s... ] Martin Choma commented on ELY-1468: ----------------------------------- After fix JBEAP-12868 this is valid only for NONE scope. Other scopes for IBM java are OK. But same issue pops up for Oracle JDK and OpenJDK. > IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported > --------------------------------------------------------------------------- > > Key: ELY-1468 > URL: https://issues.jboss.org/browse/ELY-1468 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.2.0.Beta10 > Reporter: Martin Choma > Priority: Minor > > When more mechanismTypes is provided but the Kerberos mechanism is not listed as the supported one then authentication should fail. And 401 should be returned, but 403 is on IBM java. > This issue was hidden by ELY-1340. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9750) java.lang.classnotfoundexception: org/apache/cxf/jaxws/jaxwsFactoryBean

by Santiago Simbaña (JIRA)

Santiago Simbaña created WFLY-9750: -------------------------------------- Summary: java.lang.classnotfoundexception: org/apache/cxf/jaxws/jaxwsFactoryBean Key: WFLY-9750 URL: https://issues.jboss.org/browse/WFLY-9750 Project: WildFly Issue Type: Bug Components: JAXR Reporter: Santiago Simbaña Assignee: Kurt Stam Priority: Critical Fix For: No Release Caused by: java.lang.IllegalStateException: WFLYEE0042: No logró construir la instancia del componente at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:48) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) ... 136 more Caused by: javax.ejb.EJBException: WFLYEJB0442: Error inesperado at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:185) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:349) at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:74) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) ... 142 more Caused by: java.lang.NoClassDefFoundError: org/apache/cxf/jaxws/JaxWsProxyFactoryBean at ec.gob.digercic.revit.wsrevit.wsinit.WSInitsImpl.createPortWSIntegracion(WSInitsImpl.java:52) at ec.gob.digercic.revit.wsrevit.wsinit.WSInitsImpl.init(WSInitsImpl.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unk -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AG-49) Reset transaction check callback when returning connection to the pool

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/AG-49?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-49. ----------------------------- Resolution: Done > Reset transaction check callback when returning connection to the pool > ---------------------------------------------------------------------- > > Key: AG-49 > URL: https://issues.jboss.org/browse/AG-49 > Project: Agroal > Issue Type: Bug > Components: pool > Affects Versions: 0.3 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Minor > Fix For: 0.4 > > > The callback that prevents lazy enlistment, once set, is never reset. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AG-49) Reset transaction check callback when returning connection to the pool

by Luis Barreiro (JIRA)

Luis Barreiro created AG-49: ------------------------------- Summary: Reset transaction check callback when returning connection to the pool Key: AG-49 URL: https://issues.jboss.org/browse/AG-49 Project: Agroal Issue Type: Bug Components: pool Affects Versions: 0.3 Reporter: Luis Barreiro Assignee: Luis Barreiro Priority: Minor Fix For: 0.4 The callback that prevents lazy enlistment, once set, is never reset. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AG-48) Remove autocommit stash from WrappedConnection

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/AG-48?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-48. ----------------------------- Resolution: Done > Remove autocommit stash from WrappedConnection > ---------------------------------------------- > > Key: AG-48 > URL: https://issues.jboss.org/browse/AG-48 > Project: Agroal > Issue Type: Bug > Components: pool > Affects Versions: 0.3 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Minor > Fix For: 0.4 > > > This logic is not needed anymore, as it's provided by AG-34 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2018