[JBoss JIRA] (WFLY-13024) Integrate MP Fault Tolerance 2.1
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13024?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13024:
----------------------------------
Description:
The gist here being:
* SR FT 4.1.1
* Eclipse MP FT 2.1
* remove hystrix, hdrhistogram, commons-configuration, rxjava
* update documentation
Changes in 2.1:
https://download.eclipse.org/microprofile/microprofile-fault-tolerance-2....
was:
The gist here being:
* SR FT 4.1.1
* Eclipse MP FT 2.1
* remove hystrix, hdrhistogram, commons-configuration, rxjava
* update docs
Changes in 2.1:
https://download.eclipse.org/microprofile/microprofile-fault-tolerance-2....
> Integrate MP Fault Tolerance 2.1
> --------------------------------
>
> Key: WFLY-13024
> URL: https://issues.redhat.com/browse/WFLY-13024
> Project: WildFly
> Issue Type: Feature Request
> Components: MP Fault Tolerance
> Affects Versions: 19.0.0.Beta1, 19.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 19.0.0.Beta3, 20.0.0.Beta1
>
>
> The gist here being:
> * SR FT 4.1.1
> * Eclipse MP FT 2.1
> * remove hystrix, hdrhistogram, commons-configuration, rxjava
> * update documentation
> Changes in 2.1:
> https://download.eclipse.org/microprofile/microprofile-fault-tolerance-2....
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13024) Integrate MP Fault Tolerance 2.1
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13024?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13024:
----------------------------------
Description:
The gist here being:
* SR FT 4.1.1
* Eclipse MP FT 2.1
* remove hystrix, hdrhistogram, commons-configuration, rxjava
* update docs
Changes in 2.1:
https://download.eclipse.org/microprofile/microprofile-fault-tolerance-2....
was:
The gist here being:
* SR FT 4.1.x
* Eclipse MP FT 2.1
* remove hystrix, hdr, commons-config, rxjava (v1)
* update docs
Changes in 2.1:
https://download.eclipse.org/microprofile/microprofile-fault-tolerance-2....
> Integrate MP Fault Tolerance 2.1
> --------------------------------
>
> Key: WFLY-13024
> URL: https://issues.redhat.com/browse/WFLY-13024
> Project: WildFly
> Issue Type: Feature Request
> Components: MP Fault Tolerance
> Affects Versions: 19.0.0.Beta1, 19.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 19.0.0.Beta3, 20.0.0.Beta1
>
>
> The gist here being:
> * SR FT 4.1.1
> * Eclipse MP FT 2.1
> * remove hystrix, hdrhistogram, commons-configuration, rxjava
> * update docs
> Changes in 2.1:
> https://download.eclipse.org/microprofile/microprofile-fault-tolerance-2....
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13185) Rest-client can't be used without opentracing subsystem present in config
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFLY-13185?page=com.atlassian.jira.plugi... ]
Jean Francois Denise commented on WFLY-13185:
---------------------------------------------
Attached proper README file.
> Rest-client can't be used without opentracing subsystem present in config
> -------------------------------------------------------------------------
>
> Key: WFLY-13185
> URL: https://issues.redhat.com/browse/WFLY-13185
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client
> Reporter: Jean Francois Denise
> Assignee: Alessio Soldano
> Priority: Critical
> Attachments: README, rest-reproducer.zip
>
>
> Trying to provision the following set of galleon layers:
> jaxrs ==> for jaxrs and rest-client
> microprofile-config
> I am getting an NPE. If open-tracing is provisioned along with jaxrs, no NPE and client injection works fine.
> java.lang.NullPointerException
> at org.jboss.resteasy.microprofile.client.RestClientExtension.extractBaseUri(RestClientExtension.java:40)
> at org.jboss.resteasy.microprofile.client.RestClientExtension.registerRestClient(RestClientExtension.java:29)
> 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 org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
> at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:168)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:207)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:176)
> at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:166)
> at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:219)
> at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:421)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:79)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13185) Rest-client can't be used without opentracing subsystem present in config
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFLY-13185?page=com.atlassian.jira.plugi... ]
Jean Francois Denise updated WFLY-13185:
----------------------------------------
Attachment: README
> Rest-client can't be used without opentracing subsystem present in config
> -------------------------------------------------------------------------
>
> Key: WFLY-13185
> URL: https://issues.redhat.com/browse/WFLY-13185
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client
> Reporter: Jean Francois Denise
> Assignee: Alessio Soldano
> Priority: Critical
> Attachments: README, rest-reproducer.zip
>
>
> Trying to provision the following set of galleon layers:
> jaxrs ==> for jaxrs and rest-client
> microprofile-config
> I am getting an NPE. If open-tracing is provisioned along with jaxrs, no NPE and client injection works fine.
> java.lang.NullPointerException
> at org.jboss.resteasy.microprofile.client.RestClientExtension.extractBaseUri(RestClientExtension.java:40)
> at org.jboss.resteasy.microprofile.client.RestClientExtension.registerRestClient(RestClientExtension.java:29)
> 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 org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
> at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:168)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:207)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:176)
> at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:166)
> at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:219)
> at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:421)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:79)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2451) FD_ALL3: improvements over FD_ALL
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2451?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2451 at 3/4/20 1:32 AM:
--------------------------------------------------------
Further improvements:
* Dont' send heartbeat to self
* Skip setting timestamp on reception of a heartbeat message from self
* Skip checking heartbeat from self
was (Author: belaban):
Further improvements:
* Dont' send heartbeat to self
* Skip setting timestamp on reception of a heartbeat message from self
* Skip checking heartbeat from self
* Re-introduce {{timeout_check_interval}}?
** If we have a timeout of 60s, and a member sends a heartbeat just after the 60s-period started, we won't suspect it until roughly 120s later
** Perhaps document this behavior and reduce the default to {{30s}}. Suspicions would happen in the range {{[30..60]}}
> FD_ALL3: improvements over FD_ALL
> ---------------------------------
>
> Key: JGRP-2451
> URL: https://issues.redhat.com/browse/JGRP-2451
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.1
>
>
> Improvements to {{FD_ALL}}.
> * Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed).
> * When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
> It is crucial that setting the in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time.
> The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
> We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
> However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2451) FD_ALL3: improvements over FD_ALL
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2451?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2451:
---------------------------
Description:
Improvements to {{FD_ALL}}.
* Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed).
* When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
It is crucial that setting the in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time.
The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available.
was:
Improvements to {{FD_ALL2}}.
* Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated).
* When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
* There's a map associating members with booleans. True means a heartbeat was received since the last check, false means it wasn't. On a check, the booleans are all set to false.
It is crucial that setting the in the map is quick (not like in {{FD_ALL}}, where we fetch the current time from the time service), especially since this is done on every message.
The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available.
> FD_ALL3: improvements over FD_ALL
> ---------------------------------
>
> Key: JGRP-2451
> URL: https://issues.redhat.com/browse/JGRP-2451
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.1
>
>
> Improvements to {{FD_ALL}}.
> * Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed).
> * When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
> It is crucial that setting the in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time.
> The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
> We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
> However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months