[JBoss JIRA] (WFLY-4865) org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4865?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-4865:
------------------------------------
This issue was addressed in Infinispan itself. You'll need to upgrade WildFly for a fix. I recommend 10.0.0.Final.
> org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology
> -------------------------------------------------------------------------------
>
> Key: WFLY-4865
> URL: https://issues.jboss.org/browse/WFLY-4865
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Ian Kent
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Final
>
>
> We have a 10 ode wildfly cluster. We recently started getting the following exceptions in one of our deployment environments. I checked wildfly docs, google, wildfly jira and wildfly forums and cannot find a resolution. We are using default configuration for jgroups and we are using a replicate async web cache.
> {noformat}
> 2015-07-02 14:31:16,628 ERROR org.infinispan.interceptors.InvocationContextInterceptor (clojure-agent-send-off-pool-10600) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 43
> 2015-07-02 14:31:24,613 ERROR io.undertow.request (default task-27) UT005023: Exception handling request to /fault/elements/Node%3ABGVLPAAMT1A-P-AL-0294-01/monitoring-state/history: java.lang.IllegalStateException: Address 10.70.19.243:10.70.19.243-0/web is no longer in the cluster
> {noformat}
> The fact that this only happens on one of our clusters leads me to believe that it is environmental (maybe network latency).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4865) org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology
by Rahul Jain (JIRA)
[ https://issues.jboss.org/browse/WFLY-4865?page=com.atlassian.jira.plugin.... ]
Rahul Jain commented on WFLY-4865:
----------------------------------
[~pferraro] Can you please let us know whether is there any workaround for this issue in wildlfy version 8.2 or do we need to upgrade to 9.0 up to get the fix for this issue?
> org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology
> -------------------------------------------------------------------------------
>
> Key: WFLY-4865
> URL: https://issues.jboss.org/browse/WFLY-4865
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Ian Kent
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Final
>
>
> We have a 10 ode wildfly cluster. We recently started getting the following exceptions in one of our deployment environments. I checked wildfly docs, google, wildfly jira and wildfly forums and cannot find a resolution. We are using default configuration for jgroups and we are using a replicate async web cache.
> {noformat}
> 2015-07-02 14:31:16,628 ERROR org.infinispan.interceptors.InvocationContextInterceptor (clojure-agent-send-off-pool-10600) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 43
> 2015-07-02 14:31:24,613 ERROR io.undertow.request (default task-27) UT005023: Exception handling request to /fault/elements/Node%3ABGVLPAAMT1A-P-AL-0294-01/monitoring-state/history: java.lang.IllegalStateException: Address 10.70.19.243:10.70.19.243-0/web is no longer in the cluster
> {noformat}
> The fact that this only happens on one of our clusters leads me to believe that it is environmental (maybe network latency).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance commented on WFLY-6554:
----------------------------------------
When using the "org.jboss.as.jpa.hibernate5.infinispan.InfinispanRegionFactory":
I'm getting a NPE on wrapper.getValue(), wrapper is null.
{code}
try {
// start a private cache for non-JPA use and return the started cache.
wrapper = Notification.startCache(Classification.INFINISPAN, cacheSettings);
return (EmbeddedCacheManager)wrapper.getValue();
} catch (Exception e) {
throw new CacheException(e);
}
{code}
I've not investigated yet what is happening in Notification.startCache(Classification.INFINISPAN, cacheSettings); but do you have any idea?
Should I raise another ticket?
Is there any official documentation around that?
> Cache configuration are not eagerly defined in Cache Container
> --------------------------------------------------------------
>
> Key: WFLY-6554
> URL: https://issues.jboss.org/browse/WFLY-6554
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration.
> In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc.
> This trick has only one bad side effect, which was the creation of unecessary caches.
> Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not.
> I do not know if this is a bug or this is by design but this seems wrong to me.
> If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there.
> I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started").
> Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6567) Mutable session variables do not replicate correctly using non-tx session cache
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-6567:
----------------------------------
Summary: Mutable session variables do not replicate correctly using non-tx session cache
Key: WFLY-6567
URL: https://issues.jboss.org/browse/WFLY-6567
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 10.1.0.Final
Currently, mutable session attributes require a transactional cache configuration in order to replicate properly. To support non-tx caches, we can record which mutable session attributes were accessed on a given session and re-set them at the end of the request.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1512) DelegatingBasicLogger could delegate to a Logger provider
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1512?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1512:
----------------------------------------------
I was thinking that performance would be impacted. So it seems that it is not a good idea... Feel free to close if you think that it is not relevant.
Thanks.
> DelegatingBasicLogger could delegate to a Logger provider
> ---------------------------------------------------------
>
> Key: WFCORE-1512
> URL: https://issues.jboss.org/browse/WFCORE-1512
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Jean-Francois Denise
> Assignee: James Perkins
>
> Today the DelegatingBasicLogger subclass generated from @MessageLogger annotation is bound to a Logger at construction time. It could be of interest (e.g: I ran by accident on WFCORE-1187) to have the logger to be resolved dynamically.
> I didn't evaluate the impact on the logging project/tools/performances of a solution like the following but it captures the idea of a logger provider.
> public class DelegatingBasicLogger {
> public interface LoggerProvider
> { public Logger getLogger(); }
> DelegatingBasicLogger(Logger logger) {
> { this(()->{return logger;})}
> DelegatingBasicLogger(LoggerProvider provider)
> { this.provider = provider; }
> ....
> }
> A subclass could use LogContext to retrieve the right Logger.
> class MyLogger extends DelegatingBasicLogger {
> MyLogger(String category)
> { super(()->LogContext.getLogContext().getLogger()); }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6566) SAR deployer uses wrong MBean class to resolve source Method for property injection
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/WFLY-6566?page=com.atlassian.jira.plugin.... ]
Bartosz Spyrko-Śmietanko moved JBEAP-4390 to WFLY-6566:
-------------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6566 (was: JBEAP-4390)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMX
Server
(was: JMX)
(was: Server)
Target Release: (was: 7.0.z.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.CR1)
> SAR deployer uses wrong MBean class to resolve source Method for property injection
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6566
> URL: https://issues.jboss.org/browse/WFLY-6566
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Server
> Affects Versions: 10.0.0.Final
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
>
> If using a <value-factory> or <inject> element with "parameter" attribute in jboss-service.xml to inject a value from one bean to another, a "java.lang.IllegalArgumentException: object is not an instance of declaring class" error is raised during deployment.
> jboss-service.xml
> {noformat}
> <server xmlns="urn:jboss:service:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:service:7.0 jboss-service_7_0.xsd">
> <mbean code="com.test.redhat.mbean.OtherValueFactory" name="test:type=OtherValueFactory">
> <attribute name="WelcomeString">Welcome</attribute>
> <attribute name="CustName">Other</attribute>
> </mbean>
> <mbean code="com.test.redhat.mbean.TestValueFactory" name="test:type=SarTestValueFactory">
> <depends>test:type=OtherValueFactory</depends>
> <attribute name="WelcomeString">Welcome</attribute>
> <attribute name="CustName">
> <value-factory bean="test:type=OtherValueFactory" method="getNameOfCustomer">
> <parameter class="java.lang.String">Alain Van Daele</parameter>
> </value-factory>
> </attribute>
> </mbean>
> </server>
> {noformat}
> Full error:
> {noformat}
> 16:54:36,505 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "test.sar" (runtime-name: "test.sar")
> 16:54:36,690 WARN [org.jboss.msc.inject] (MSC service thread 1-2) MSC000100: Unexpected failure to uninject public void com.test.redhat.mbean.TestValueFactory.setCustName(java.lang.String): java.lang.NullPointerException
> 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:497)
> at org.jboss.msc.value.MethodValue.getValue(MethodValue.java:62)
> at org.jboss.msc.value.CachedValue.getValue(CachedValue.java:54)
> at org.jboss.msc.value.Values.getValues(Values.java:68)
> at org.jboss.msc.value.Values.getValues(Values.java:82)
> at org.jboss.msc.inject.MethodInjector.uninject(MethodInjector.java:119)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1923)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876)
> 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)
> 16:54:36,691 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.mbean.service.test:type=SarTestValueFactory.create: org.jboss.msc.service.StartException in service jboss.mbean.service.test:type=SarTestValueFactory.create: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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)
> Caused by: org.jboss.msc.inject.InjectionException: Injection failed
> at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:102)
> at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1672)
> at org.jboss.msc.service.ServiceControllerImpl.access$2000(ServiceControllerImpl.java:51)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1917)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876)
> ... 3 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
> 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:497)
> at org.jboss.msc.value.MethodValue.getValue(MethodValue.java:62)
> at org.jboss.msc.value.CachedValue.getValue(CachedValue.java:54)
> at org.jboss.msc.value.Values.getValues(Values.java:68)
> at org.jboss.msc.value.Values.getValues(Values.java:82)
> at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:92)
> ... 7 more
> 16:54:36,697 INFO [com.test.redhat.mbean.OtherValueFactory] (ServerService Thread Pool -- 58) >> TestValuFactory.start() invoked
> 16:54:36,698 INFO [stdout] (ServerService Thread Pool -- 58) TestValuFactory.start() invoked
> 16:54:36,776 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.sar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.mbean.service.test:type=SarTestValueFactory.create" => "org.jboss.msc.service.StartException in service jboss.mbean.service.test:type=SarTestValueFactory.create: Failed to start service
> Caused by: org.jboss.msc.inject.InjectionException: Injection failed
> Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class"}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1512) DelegatingBasicLogger could delegate to a Logger provider
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1512?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-1512:
---------------------------------------
We'd have to add some kind of {{getDelegate()}} method to the {{DelegatingBasicLogger}} that would essentially have to something like {{LoggerProvider.getLogger()}} for every log invocation. That would hit performance fairly heavily I'd think. It would also essentially make a static logger not really static.
> DelegatingBasicLogger could delegate to a Logger provider
> ---------------------------------------------------------
>
> Key: WFCORE-1512
> URL: https://issues.jboss.org/browse/WFCORE-1512
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Jean-Francois Denise
> Assignee: James Perkins
>
> Today the DelegatingBasicLogger subclass generated from @MessageLogger annotation is bound to a Logger at construction time. It could be of interest (e.g: I ran by accident on WFCORE-1187) to have the logger to be resolved dynamically.
> I didn't evaluate the impact on the logging project/tools/performances of a solution like the following but it captures the idea of a logger provider.
> public class DelegatingBasicLogger {
> public interface LoggerProvider
> { public Logger getLogger(); }
> DelegatingBasicLogger(Logger logger) {
> { this(()->{return logger;})}
> DelegatingBasicLogger(LoggerProvider provider)
> { this.provider = provider; }
> ....
> }
> A subclass could use LogContext to retrieve the right Logger.
> class MyLogger extends DelegatingBasicLogger {
> MyLogger(String category)
> { super(()->LogContext.getLogContext().getLogger()); }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1512) DelegatingBasicLogger could delegate to a Logger provider
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1512?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1512:
----------------------------------------------
I see, perhaps the Logger.getMessageLogger could accept a LoggerProvider. Doing so the LogContext would be kept hidden. (NB: Just a proposal, I understand the static root cause).
> DelegatingBasicLogger could delegate to a Logger provider
> ---------------------------------------------------------
>
> Key: WFCORE-1512
> URL: https://issues.jboss.org/browse/WFCORE-1512
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Jean-Francois Denise
> Assignee: James Perkins
>
> Today the DelegatingBasicLogger subclass generated from @MessageLogger annotation is bound to a Logger at construction time. It could be of interest (e.g: I ran by accident on WFCORE-1187) to have the logger to be resolved dynamically.
> I didn't evaluate the impact on the logging project/tools/performances of a solution like the following but it captures the idea of a logger provider.
> public class DelegatingBasicLogger {
> public interface LoggerProvider
> { public Logger getLogger(); }
> DelegatingBasicLogger(Logger logger) {
> { this(()->{return logger;})}
> DelegatingBasicLogger(LoggerProvider provider)
> { this.provider = provider; }
> ....
> }
> A subclass could use LogContext to retrieve the right Logger.
> class MyLogger extends DelegatingBasicLogger {
> MyLogger(String category)
> { super(()->LogContext.getLogContext().getLogger()); }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years