[JBoss JIRA] (WFLY-13185) Rest-client can't be used without opentracing subsystem present in config
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-13185?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-13185:
--------------------------------------
Not sure I can see how creation of {{BackedAnnotatedConstructor}} relates to this - the constructor itself doesn't have the annotation, it's declared on the class. Plus you are actually inspecting the whole type (from within the extension's PAT method), not just constructor.
Quickly looking at the code, I think the annotations should come from the {{ReflectionCache}} used during creation of that annotated type.
> 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] (JBWEB-317) WsWebSocketContainer#connectToServer throws BufferOverflowException
by Juho Tykkälä (Jira)
Juho Tykkälä created JBWEB-317:
----------------------------------
Summary: WsWebSocketContainer#connectToServer throws BufferOverflowException
Key: JBWEB-317
URL: https://issues.redhat.com/browse/JBWEB-317
Project: JBoss Web
Issue Type: Bug
Components: Tomcat
Affects Versions: JBossWeb-7.5.0.GA
Reporter: Juho Tykkälä
Assignee: Remy Maucherat
WsWebSocketContainer#connectToServer throws BufferOverflowException when headers supplied by ClientEndpointConfig.Configurator#beforeRequest are too large.
{code:java}
Exception in thread "main" java.nio.BufferOverflowException
at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:189)
at java.nio.ByteBuffer.put(ByteBuffer.java:859)
at org.apache.tomcat.websocket.WsWebSocketContainer.addHeader(WsWebSocketContainer.java:755)
at org.apache.tomcat.websocket.WsWebSocketContainer.createRequest(WsWebSocketContainer.java:736)
at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServerRecursive(WsWebSocketContainer.java:275)
at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:195)
{code}
In our application, we are forwarding an Authorization header/token of close to 4000 bytes, which when combined with other headers results in a request larger than the 4096 allocated to the ByteBuffer in WsWebSocketContainer#createRequest.
Original bug at Apache BugZilla https://bz.apache.org/bugzilla/show_bug.cgi?id=62596
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JBWEB-317) WsWebSocketContainer#connectToServer throws BufferOverflowException
by Juho Tykkälä (Jira)
[ https://issues.redhat.com/browse/JBWEB-317?page=com.atlassian.jira.plugin... ]
Juho Tykkälä commented on JBWEB-317:
------------------------------------
Original bug fixed at 2018-08-08 06:34:22 UTC
Fixed in:
- trunk for 9.0.11 onwards
- 8.5.x for 8.5.33 onwards
- 7.0.x for 7.0.91 onwards
> WsWebSocketContainer#connectToServer throws BufferOverflowException
> -------------------------------------------------------------------
>
> Key: JBWEB-317
> URL: https://issues.redhat.com/browse/JBWEB-317
> Project: JBoss Web
> Issue Type: Bug
> Components: Tomcat
> Affects Versions: JBossWeb-7.5.0.GA
> Reporter: Juho Tykkälä
> Assignee: Remy Maucherat
> Priority: Major
> Labels: WebSocket, jbossweb, tomcat, websocket, websockets
>
> WsWebSocketContainer#connectToServer throws BufferOverflowException when headers supplied by ClientEndpointConfig.Configurator#beforeRequest are too large.
> {code:java}
> Exception in thread "main" java.nio.BufferOverflowException
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:189)
> at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> at org.apache.tomcat.websocket.WsWebSocketContainer.addHeader(WsWebSocketContainer.java:755)
> at org.apache.tomcat.websocket.WsWebSocketContainer.createRequest(WsWebSocketContainer.java:736)
> at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServerRecursive(WsWebSocketContainer.java:275)
> at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:195)
> {code}
> In our application, we are forwarding an Authorization header/token of close to 4000 bytes, which when combined with other headers results in a request larger than the 4096 allocated to the ByteBuffer in WsWebSocketContainer#createRequest.
> Original bug at Apache BugZilla https://bz.apache.org/bugzilla/show_bug.cgi?id=62596
--
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/5/20 5:59 AM:
--------------------------------------------------------
This sound like a good solution, but I guess you meant timeout=60s in your example, didn't you? I changed that in your algorithm above
was (Author: belaban):
[~dan.berindei]This sound like a good solution, but I guess you meant timeout=60s in your example, didn't you? I changed that in your algorithm above
> 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 timestamp 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 edited comment on JGRP-2451 at 3/5/20 5:59 AM:
--------------------------------------------------------
This sounds like a good solution, but I guess you meant timeout=60s in your example, didn't you? I changed that in your algorithm above
was (Author: belaban):
This sound like a good solution, but I guess you meant timeout=60s in your example, didn't you? I changed that in your algorithm above
> 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 timestamp 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] (WFLY-13202) Docs: cleanup mod_cluster section
by Radoslav Husar (Jira)
Radoslav Husar created WFLY-13202:
-------------------------------------
Summary: Docs: cleanup mod_cluster section
Key: WFLY-13202
URL: https://issues.redhat.com/browse/WFLY-13202
Project: WildFly
Issue Type: Task
Components: Documentation, mod_cluster
Reporter: Radoslav Husar
Assignee: Radoslav Husar
The doc needs a bit of an update, e.g. custom operations should operate on the proxy rather than at the subsystem level (although that still works with a single proxy configuration).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13200) Upgrade Smallrye Opentracing to 1.3.4
by Ingo Weiss (Jira)
Ingo Weiss created WFLY-13200:
---------------------------------
Summary: Upgrade Smallrye Opentracing to 1.3.4
Key: WFLY-13200
URL: https://issues.redhat.com/browse/WFLY-13200
Project: WildFly
Issue Type: Component Upgrade
Components: MP OpenTracing
Affects Versions: 19.0.0.Beta2
Reporter: Ingo Weiss
Assignee: Emmanuel Hugonnet
Fix For: 19.0.0.Beta3, 20.0.0.Beta1
Upgrade smallrye opentracing to 1.3.4 to have dependencies versions in sync with MP 3.3
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months