[JBoss JIRA] (WFLY-11643) Update helloworld-mdb quickstarts expected console output in Readme
by Sultan Zhantemirov (Jira)
[ https://issues.jboss.org/browse/WFLY-11643?page=com.atlassian.jira.plugin... ]
Sultan Zhantemirov moved JBEAP-16290 to WFLY-11643:
---------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11643 (was: JBEAP-16290)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Quickstarts
(was: Quickstarts)
Affects Version/s: (was: 7.3.0.CD15)
> Update helloworld-mdb quickstarts expected console output in Readme
> -------------------------------------------------------------------
>
> Key: WFLY-11643
> URL: https://issues.jboss.org/browse/WFLY-11643
> Project: WildFly
> Issue Type: Task
> Components: Quickstarts
> Reporter: Sultan Zhantemirov
> Assignee: Eduardo Martins
> Priority: Major
>
> As it is written in helloworld-mdb and helloworld-mdb-propertysubstitution Readme, the following line is expected to appear in console output:
> {noformat}
> INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221003: trying to deploy queue jms.queue.HelloWorldMDBQueue
> {noformat}
> But in 7.3.0.CD15 build (and older builds) this kind of info message is not shown anymore whereas helloworld quickstarts functionality is not influenced at all - see more details at [logs|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-q...].
> I suggest updating the mentioned Readmes in case you don't have an another resolution.
--
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/24/19 5:52 AM:
---------------------------------------------------------------------
Just a note for future reference. There are five interceptors which get executed in this order:
TransactionInterceptor
NamingEJBClientInterceptor
DiscoveryEJBClientInterceptor
TransactionPostDiscoveryInterceptor
RemotingEJBClientInterceptor
Here is the way I look at these.
Naming and Discovery find and set destinations for invocations. Naming does it based on a list of URLs in PROVIDER_URLs in the JNDI InitialContext which is used to lookup the EJB client proxy. Discovery does it based on configured connections in the EJBClientContext as well as dynamically discovered connections from clusters. Naming is only activated if (strong affinity, weak affinity) = (NONE, NONE). Discovery works for all affinity combinations. If one finds a destination, the other will let that selection stand (i.e. they don't interfere with each other).
Transaction and TransactionPostDiscovery work together to ensure transaction stickiness. They do not discover destinations and leave that up to Naming and Discovery. Transaction holds an applications map which maps module names to destinations: if an invocation arrives for a module which Transaction has seen before, it sets the destination to the same node, using the applications map. This map is a resource on the transaction, so it dies when the transaction is committed. If Transaction does not recognize the invocation module, it attaches the map to the invocation context. Discovery is carried out by Naming or Discovery as usual. Then TransactionPostDiscovery takes the discovered destination and adds it to the applications map, which is obtains as an attachment to the invocation context. That destination will be used for an invocation on the same module the next time around. Additionally, Transaction also uses the application map to give hints to Discovery: when Transaction cannot set the destination, it attaches its current list of URIs from the applications map as PREFERRED_DESTINATIONS; Discovery will use this if it has to choose one URI from several available. This means in practice that Transaction will ask Discovery to choose nodes that Transaction has seen before.
Remoting just removes nodes from the discovered node registry (DNR) when a chosen destination returns a NoSuchEJBException.
was (Author: rachmato):
Just a note for future reference. There are five interceptors which get executed in this order:
TransactionInterceptor
NamingEJBClientInterceptor
DiscoveryEJBClientInterceptor
TransactionPostDiscoveryInterceptor
RemotingEJBClientInterceptor
Here is the way I look at these.
Naming and Discovery find and set destinations for invocations. Naming does it based on a list of URLs in PROVIDER_URLs in the JNDI InitialContext which is used to lookup the EJB client proxy. Discovery does it based on configured connections in the EJBClientContext as well as dynamically discovered connections from clusters. Naming is only activated if (strong affinity, weak affinity) = (NONE, NONE). Discovery works for all affinity combinations. If one finds a destination, the other will let that selection stand (i.e. they don't interfere with each other).
Transaction and TransactionPostDiscovery work together to ensure transaction stickiness. They do not discover destinations and leave that up to naming an Discovery. Transaction holds an applications map which maps module names to destinations: if an invocation arrives for a module which Transaction has seen before, it sends it to the same node using the applications map. This map is a resource on the transaction so it dies when the transaction is committed. If Transaction does not recognize the invocation module, it attaches the map to the invocation context. Discovery is carried out by naming or Discovery. Then TransactionPostDiscovery takes the discovered destination and adds it to the applications map, which is obtains as an attachment to the invocation context.
Remoting just removes nodes from the discovered node registry (DNR) when a chosen destination returns a NoSuchEJBException.
> 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:
--------------------------------------------
Just a note for future reference. There are five interceptors which get executed in this order:
TransactionInterceptor
NamingEJBClientInterceptor
DiscoveryEJBClientInterceptor
TransactionPostDiscoveryInterceptor
RemotingEJBClientInterceptor
Here is the way I look at these.
Naming and Discovery find and set destinations for invocations. Naming does it based on a list of URLs in PROVIDER_URLs in the JNDI InitialContext which is used to lookup the EJB client proxy. Discovery does it based on configured connections in the EJBClientContext as well as dynamically discovered connections from clusters. Naming is only activated if (strong affinity, weak affinity) = (NONE, NONE). Discovery works for all affinity combinations. If one finds a destination, the other will let that selection stand (i.e. they don't interfere with each other).
Transaction and TransactionPostDiscovery work together to ensure transaction stickiness. They do not discover destinations and leave that up to naming an Discovery. Transaction holds an applications map which maps module names to destinations: if an invocation arrives for a module which Transaction has seen before, it sends it to the same node using the applications map. This map is a resource on the transaction so it dies when the transaction is committed. If Transaction does not recognize the invocation module, it attaches the map to the invocation context. Discovery is carried out by naming or Discovery. Then TransactionPostDiscovery takes the discovered destination and adds it to the applications map, which is obtains as an attachment to the invocation context.
Remoting just removes nodes from the discovered node registry (DNR) when a chosen destination returns a NoSuchEJBException.
> 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] (WFCORE-3049) JBoss CLI - CJK Character Issue
by Jean-Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFCORE-3049?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise closed WFCORE-3049.
----------------------------------------
Resolution: Incomplete Description
Using the command pasted from the description into a file I can't reproduce the problem. The characters are properly stored in standalone.xml.
I suspect an invalid encoding of the cli script file.
I am closing the issue, feel free to re-open if you still encounter the problem with file encoded in UTF-8. For example, copy-paste your command in the file I attached, run CLI.
If failures persist, re-open and attach the file you used.
Thanks.
> JBoss CLI - CJK Character Issue
> -------------------------------
>
> Key: WFCORE-3049
> URL: https://issues.jboss.org/browse/WFCORE-3049
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: J Prasanna Venkatesan
> Assignee: Jean-Francois Denise
> Priority: Major
> Labels: cjk, login-module
> Attachments: cjk2.cli
>
>
> Dear All,
>
> Environment:
>
> CentOS Linux release 7.1.1503 (Core)
> /usr/java/jdk1.8.0_45/
> WildFly 8.2.0
> I am executing few LoginModule commands using file. My file name is command.cli
> Its content is
>
> {color:red}[root@cu490 temp]# cat command.cli
> /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapExtLoginModule3:add(code=org.jboss.security.auth.spi.LdapExtLoginModule, flag=sufficient, module-options={ "java.naming.provider.url" => "ldap://a.com:389/", "java.naming.referral" => "follow", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "java.naming.security.authentication" => "simple", "bindDN" => "cn=in00655,OU=비임직원,OU=SK이노베이션,DC=test,DC=net", "bindCredential" => "xxxxxx", "baseCtxDN" => "ou=SK이노베이션,DC=test,DC=net", "baseFilter" => "(sAMAccountName={0})", "roleAttributeID" => "memberOf", "roleAttributeIsDN" => "true", "rolesCtxDN" => "DC=test,DC=net", "roleFilter" => "(member={1})", "roleRecursion" => "1", "searchTimeLimit" => "5000", "searchScope" => "SUBTREE_SCOPE", "allowEmptyPasswords" => "false", "throwValidateError" => "true" }){allow-resource-service-restart=true}
>
> [root@cu490 temp]# /opt/collabnet/teamforge/runtime/jboss/bin/jboss-cli.sh --connect --file=command.cli
> {
> "outcome" => "success",
> "response-headers" => {"process-state" => "reload-required"}
> }
> [root@cu490 temp]# vim /opt/collabnet/teamforge//runtime/jboss/standalone/configuration/standalone-full.xml{color}
>
> Content inside standalone-full.xml is
>
> {color:red}<login-module name="org.jboss.security.auth.spi.LdapExtLoginModule3" code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="sufficient">
> <module-option name="java.naming.provider.url" value="ldap://a.com:389/"/>
> <module-option name="java.naming.referral" value="follow"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> <module-option name="bindDN" value="cn=in00655,OU=????,OU=SK?????,DC=test,DC=net"/>
> <module-option name="bindCredential" value="xxxxxx"/>
> <module-option name="baseCtxDN" value="ou=SK?????,DC=test,DC=net"/>
> <module-option name="baseFilter" value="(sAMAccountName={0})"/>
> <module-option name="roleAttributeID" value="memberOf"/>
> <module-option name="roleAttributeIsDN" value="true"/>
> <module-option name="rolesCtxDN" value="DC=test,DC=net"/>
> <module-option name="roleFilter" value="(member={1})"/>
> <module-option name="roleRecursion" value="1"/>
> <module-option name="searchTimeLimit" value="5000"/>
> <module-option name="searchScope" value="SUBTREE_SCOPE"/>
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="throwValidateError" value="true"/>
> </login-module>{color}
>
> You can see instead of CJK characters we are seeing ??? in standalone-full.xml
>
> Please throw some light on this.
>
> Thanks & Regards,
> J Prasanna Venkatesan
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2297) Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2297?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2297:
--------------------------------
This requires a change from pull-style to push-style for the key exchange, see [1] for details.
[1] https://github.com/belaban/JGroups/blob/master/doc/design/ASYM_ENCRYPT.txt
> Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
> --------------------------------------------------------------------
>
> Key: JGRP-2297
> URL: https://issues.jboss.org/browse/JGRP-2297
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.14
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.0.17
>
>
> The {{ASYM_ENCRYPT_LeaveTest}} is designed to test graceful leaving coordinator(s) with ASYM_ENCRYPT in the stack. However, the test currently passes due to presence of MERGE3 in the stack. While the intention of the test seems to be testing graceful leaving of coordinator(s), the cluster ends up with inconsistent views later resolved by MERGE3.
> Here is a run of the test with a modification of the test with a *single* coordinator leaving:
> https://gist.github.com/rhusar/89172882fae60a1f29327c33f2d124db
> The problem seems to be with coordinating of key exchange. In this run, roughly:
> 1. node 1 is leaving
> 2. node 2 becomes coordinator and key server
> {noformat}
> 10:55:18.286 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: installing view [2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10]
> ...
> 10:55:18.299 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: I'm the new key server
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> ...
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> {noformat}
> 3. node 9 receives {{FETCH_SECRET_KEY}} however receives stale key? looks like it still contacts the leaving coordinator node 1?
> {noformat}
> 10:55:18.319 [SSL_KEY_EXCHANGE-runner-12,ASYM_ENCRYPT_LeaveTest,1] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 1: accepted SSL connection from /127.0.0.1:51812; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> ...
> 10:55:18.319 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2157); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AF7916A9394F49B085D4F35C4F5A0A3E)
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: ignoring secret key received from key exchange protocol (version: AF7916A9394F49B085D4F35C4F5A0A3E), as it has already been installed
> {noformat}
> 4. new coordinator fails to collect all acks (since it cannot decipher stale key?)
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] WARN org.jgroups.protocols.pbcast.GMS - 2: failed to collect all ACKs (expected=8) for view [2|10] after 2000ms, missing 1 ACKs from (1) 9
> {noformat}
> 5. node 9 eventually obtains the key but since it has stale view and still thinks node 1 is coordinator? and fails to contact it
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: asking key exchange protocol to get secret key from 2
> 10:55:20.322 [SSL_KEY_EXCHANGE-runner-26,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 2: accepted SSL connection from /127.0.0.1:51829; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2158); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: installing secret key received from key exchange protocol (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:23.341 [TQ-Bundler-10,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.TCP - JGRP000034: 9: failure sending message to 1: java.net.ConnectException: Connection refused (Connection refused)
> {noformat}
> 6. cluster is later healed with MERGE3
> {noformat}
> 10:55:27.103 [jgroups-27,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: I will be the merge leader. Starting the merge task. Views: {2=[2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10], 9=[1|9] (10) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]}
> {noformat}
> Another run with MERGE3 omitted from the stack is here:
> https://gist.github.com/rhusar/b51aeee03485a607041f9669bbc6e707
> Further investigation is ongoing, but this might be related to graceful leaving of coordinator JGRP-2293 exacerbating the problem with key exchange in ASYM_ENCRYPT.
> Scaling down is typical cloud workflow, especially with encryption since {{ASYM_ENCRYPT}} is the recommended setup making this problem critical.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3546) DMN fix FEEL context entry when key is a string literal
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-3546?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-3546:
----------------------------------------
> I am approving this PR because I see in the FEEL grammar it supports string literals as keys, but I think this is a mistake in the spec.
Before I will close this JIRA, I want to verify what is actually implied by "mistake in the spec".
DMNv1.1:
!screenshot-1.png|thumbnail!
and specific chapter:
!screenshot-2.png|thumbnail!
DMNv1.2:
!screenshot-3.png|thumbnail!
and the specific chapter:
!screenshot-4.png|thumbnail!
So I believe it not only the FEEL grammar that specify this, but it is also backed by the specific Context chapter on the matter.
Personally, although I still would need to triple check it, I believe the spec included this "feature" to enable the FEEL-only equivalent of this:
!screenshot-5.png|thumbnail!
as I believe the horse-emoji would be a valid FEEL name by intentions, but the unicode is not compatible with grammar rule "30. name start char"
What do you think [~tirelli] ?
> DMN fix FEEL context entry when key is a string literal
> -------------------------------------------------------
>
> Key: DROOLS-3546
> URL: https://issues.jboss.org/browse/DROOLS-3546
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png, screenshot-5.png
>
>
> Ref FEEL grammar rule 61
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFCORE-3639) Elytron error message less comprehensive in jdk9 compared to jdk8
by Jean-Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFCORE-3639?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3639:
----------------------------------------------
In order to progress on this issue, it would really help to have the precise steps to reproduce the issue. It seems to imply a custom security configuration.
> Elytron error message less comprehensive in jdk9 compared to jdk8
> -----------------------------------------------------------------
>
> Key: WFCORE-3639
> URL: https://issues.jboss.org/browse/WFCORE-3639
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Beta1
> Reporter: Martin Choma
> Assignee: Jean-Francois Denise
> Priority: Major
>
> I like jdk8 error message where there is obvious GS2-KRB5 has been attempted but failed for some reason, PLAIN has been attempted, but failed for some reason.
> {code:title=jdk8}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Authentication failed: all available authentication mechanisms failed:
> GS2-KRB5: javax.security.sasl.SaslException: GS2-KRB5: Server rejected authentication
> PLAIN: javax.security.sasl.SaslException: ELY05053: Callback handler failed for unknown reason [Caused by java.io.IOException: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.]
> {code}
> Whereas in jdk9 error message hides the fact GS2-KRB5 was attempted and just prints error for PLAIN mechanism, but does not mention explicitely it is PLAIN mechanism
> {code:title=jdk9}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Cannot get password: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.
> {code}
> This is general question, but I have hit this with this specific use case:
> 1. server is configured to use GS2-KRB5 and PLAIN
> 2. server is configured with TLS
> 3. client is configured to use GS2-KRB5
> 4. expectation is authentication should be not successful because channel binding GS2-KRB5-PLUS should be used.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months