[JBoss JIRA] (WFLY-7036) Add MQTT protocol support for JMS
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-7036?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet closed WFLY-7036.
-----------------------------------
Resolution: Won't Fix
WildFly is an application server not a messaging hub. Maybe you should use a 'pure' broker like Apache Artemis for this and WildFly as a client for this remote broker.
> Add MQTT protocol support for JMS
> ---------------------------------
>
> Key: WFLY-7036
> URL: https://issues.jboss.org/browse/WFLY-7036
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Juraj Veverka
> Assignee: ehsavoie Hugonnet
> Priority: Major
>
> It would be great if MQTT protocol is supported by JMS subsystem in WildFly AS. As of WildFly 10, ActiveMQ is used as JMS implementation in WildFly AS. ActiveMQ supports MQTT protocol, but if I try to add remote-acceptor in <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
> <remote-acceptor name="netty-acceptor-mqtt" socket-binding="messaging-mqtt">
> <param name="protocols" value="MQTT,CORE"/>
> </remote-acceptor>
> When WildFly is started, I can see following log statement:
> 22:55:48,487 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 64) AMQ221020: Started Acceptor at 127.0.0.1:7998 for protocols [CORE,AMQP,HORNETQ,STOMP]
> which means that MQTT protocol is not supportred, instead CORE,AMQP,HORNETQ,STOMP are activated.
> MQTT is used by IoT devices, it would be nice if WildFly 10.2.0 AS has out-of-the-box support.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11489 at 1/22/19 11:21 AM:
----------------------------------------------------------------------
I should also note that the changes I made to the EJB client caused a failure in the LearningTestCase. Fixing this error deepened by understanding of how this client works. I might as well explain it here; or at least i'll explain my understanding of it.
Learning is a feature related to proxies created from the same initial context. When we create a proxy for a SFSB, it has something called a baseAffinity, a strong affinity which restricts which nodes can be used for the initial invocation which creates the session. If learning is enabled, if we lookup a SFSB using an initial context, and it ends up having strong affinity tied to a cluster, then any proxies generated later by lookups on SFSBs from the same initial context will automatically inherit the same baseAffinity; in other words, they will be automatically tied to the same cluster. This feature can be disabled by including the property jboss.disable-affinity-learning = true in the InitialContext environment. The default value for baseAffinity is Affinity.NONE, which means the initial session creation invocation could be directed to any node. If we wish to specify the default baseAffinity (which must be of type ClusterAffinity), we can use the InitialContext property jboss.cluster-affinity = <cluster name>.
The problem in LearningTestCase was that proxies for SFSBs were being created (which includes the session being created on the chosen server node) and returning with strong affinity = NONE, which is not what is supposed to happen: SFSBs should have strong affinity either to the node (if the chosen target for the initial session creation pointed to a standalone node) or a cluster(if the chosen target for the initial session creation pointed to a cluster node).
I adjusted the expected affinity from Affinity.NONE to URIAffinity(new URI("remote://localhost:6999)) which is the affinity that will result when passing through the NamingEJBClientInterceptor when a PROVIDER_URL is in the InitialContext environment.
was (Author: rachmato):
I should also note that the changes I made to the EJB client caused a failure in the LearningTestCase. Fixing this error deepened by understanding of how this client works. I might as well explain it here; or at least i'll explain my understanding of it.
Learning is a feature related to proxies created from the same initial context. When we create a proxy for a SFSB, it has something called a baseAffinity, a strong affinity which restricts which nodes can be used for the initial invocation which creates the session. If learning is enabled, if we lookup a SFSB using an initial context, and it ends up having strong affinity tied to a cluster, then any proxies generated later by lookups on SFSBs from the same initial context will automatically inherit the same baseAffinity; in other words, they will be automatically tied to the same cluster. This feature can be disabled by including the property jboss.disable-affinity-learning = true in the InitialContext environment. The default value for baseAffinity is Affinity.NONE. If we wish to specify the default baseAffinity (which must be of type ClusterAffinity), we can use the InitialContext property jboss.cluster-affinity = <cluster name>.
The problem in LearningTestCase was that proxies for SFSBs were being created (which includes the session being created on the chosen server node) and returning with strong affinity = NONE, which is not what is supposed to happen: SFSBs should have strong affinity either to the node (if the chosen target for the initial session creation pointed to a standalone node) or a cluster(if the chosen target for the initial session creation pointed to a cluster node).
I adjusted the expected affinity from Affinity.NONE to URIAffinity(new URI("remote://localhost:6999)) which is the affinity that will result when passing through the NamingEJBClientInterceptor when a PROVIDER_URL is in the InitialContext environment.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> 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.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 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.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-11489:
--------------------------------------------
I should also note that the changes I made to the EJB client caused a failure in the LearningTestCase. Fixing this error deepened by understanding of how this client works. I might as well explain it here; or at least i'll explain my understanding of it.
Learning is a feature related to proxies created from the same initial context. When we create a proxy for a SFSB, it has something called a baseAffinity, a strong affinity which restricts which nodes can be used for the initial invocation which creates the session. If learning is enabled, if we lookup a SFSB using an initial context, and it ends up having strong affinity tied to a cluster, then any proxies generated later by lookups on SFSBs from the same initial context will automatically inherit the same baseAffinity; in other words, they will be automatically tied to the same cluster. This feature can be disabled by including the property jboss.disable-affinity-learning = true in the InitialContext environment. The default value for baseAffinity is Affinity.NONE. If we wish to specify the default baseAffinity (which must be of type ClusterAffinity), we can use the InitialContext property jboss.cluster-affinity = <cluster name>.
The problem in LearningTestCase was that proxies for SFSBs were being created (which includes the session being created on the chosen server node) and returning with strong affinity = NONE, which is not what is supposed to happen: SFSBs should have strong affinity either to the node (if the chosen target for the initial session creation pointed to a standalone node) or a cluster(if the chosen target for the initial session creation pointed to a cluster node).
I adjusted the expected affinity from Affinity.NONE to URIAffinity(new URI("remote://localhost:6999)) which is the affinity that will result when passing through the NamingEJBClientInterceptor when a PROVIDER_URL is in the InitialContext environment.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> 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.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 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.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ELYWEB-36) ElytronHttpExchange.getRequestParameters() is prematurely readying the request.
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/ELYWEB-36?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on ELYWEB-36:
----------------------------------
[~dlofthouse] That makes sense since we can create the branch from the last tag when needed as you mentioned.
I'm going to remove the 1.2.4.CR1 and 1.3.1.CR1 fix versions from the this issue and mark it as resolved. Once the downstream PR is merged, I'll add back the 1.2.4.CR1 fix version.
> ElytronHttpExchange.getRequestParameters() is prematurely readying the request.
> -------------------------------------------------------------------------------
>
> Key: ELYWEB-36
> URL: https://issues.jboss.org/browse/ELYWEB-36
> Project: Elytron Web
> Issue Type: Bug
> Components: Undertow Servlet
> Affects Versions: 1.2.3.Final, 1.3.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.4.0.CR1
>
>
> When running within Undertow as a Servlet container the method ElytronHttpExchange.getRequestParameters() is prematurely reading the FormData making it unavailable to the HttpServletRequest.
> If instead of handling them manually the request parameters were read from the HttpServletRequest this would not be an issue as the request can re-use it's own prior FormData parsing.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ELYWEB-36) ElytronHttpExchange.getRequestParameters() is prematurely readying the request.
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/ELYWEB-36?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELYWEB-36:
-----------------------------
Fix Version/s: (was: 1.2.4.CR1)
(was: 1.3.1.CR1)
> ElytronHttpExchange.getRequestParameters() is prematurely readying the request.
> -------------------------------------------------------------------------------
>
> Key: ELYWEB-36
> URL: https://issues.jboss.org/browse/ELYWEB-36
> Project: Elytron Web
> Issue Type: Bug
> Components: Undertow Servlet
> Affects Versions: 1.2.3.Final, 1.3.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.4.0.CR1
>
>
> When running within Undertow as a Servlet container the method ElytronHttpExchange.getRequestParameters() is prematurely reading the FormData making it unavailable to the HttpServletRequest.
> If instead of handling them manually the request parameters were read from the HttpServletRequest this would not be an issue as the request can re-use it's own prior FormData parsing.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11408) Upgrade HAL to 3.1.1.Final
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11408?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFLY-11408:
-----------------------------------
[~msvehla][~spriadka] We really need to get this in for WildFly 16 to get community feedback on this. As the console is not supported in CD releases, we have time up to the 7.3.0 release. I am not 100% sure how to handle this from a process POV, but I think it means cloning all the current EAP7 unchecked EAP7 issues to 'Test xxxx' EAP7 RFEs (or perhaps we could use Tasks for these).
> Upgrade HAL to 3.1.1.Final
> --------------------------
>
> Key: WFLY-11408
> URL: https://issues.jboss.org/browse/WFLY-11408
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Web Console
> Reporter: Harald Pehl
> Assignee: Harald Pehl
> Priority: Blocker
> Fix For: 16.0.0.Beta1
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months