[JBoss JIRA] (DROOLS-2431) [DMN Designer] Navigator has not same header height in full screen mode
by Guilherme Carreiro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2431?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro updated DROOLS-2431:
---------------------------------------
Attachment: macos-chrome.png
macos-firefox.png
macos-safari.png
> [DMN Designer] Navigator has not same header height in full screen mode
> -----------------------------------------------------------------------
>
> Key: DROOLS-2431
> URL: https://issues.jboss.org/browse/DROOLS-2431
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Priority: Trivial
> Attachments: Screenshot from 2018-03-28 08-26-22.png, fedora-chrome.png, fedora-firefox.png, macos-chrome.png, macos-firefox.png, macos-safari.png
>
>
> If DMN Designer enters full screen mode, its header has has different height as navigator, see the attachment. Compare header height in *Decision Navigator* part and *New DMN diagram* part.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2431) [DMN Designer] Navigator has not same header height in full screen mode
by Guilherme Carreiro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2431?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro commented on DROOLS-2431:
--------------------------------------------
[~jomarko] I could not reproduce this issue. See:
I tried to reproduce it using Firefox and Chrome on Fedora:
!fedora-chrome.png|thumbnail! !fedora-firefox.png|thumbnail!
...and I tried it on macOS using Firefox, Chrome and Safari:
!macos-chrome.png|thumbnail! !macos-firefox.png|thumbnail! !macos-safari.png|thumbnail!
Am I missing something?
Thanks.
> [DMN Designer] Navigator has not same header height in full screen mode
> -----------------------------------------------------------------------
>
> Key: DROOLS-2431
> URL: https://issues.jboss.org/browse/DROOLS-2431
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Priority: Trivial
> Attachments: Screenshot from 2018-03-28 08-26-22.png, fedora-chrome.png, fedora-firefox.png, macos-chrome.png, macos-firefox.png, macos-safari.png
>
>
> If DMN Designer enters full screen mode, its header has has different height as navigator, see the attachment. Compare header height in *Decision Navigator* part and *New DMN diagram* part.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10463) Weak affinity set up by EJB client 4 is not followed with invocations running against stateful bean deploment on WildFly 13
by Michal Jurc (JIRA)
[ https://issues.jboss.org/browse/WFLY-10463?page=com.atlassian.jira.plugin... ]
Michal Jurc commented on WFLY-10463:
------------------------------------
[~pferraro], [~kabirkhan]: The issue is fixed with https://github.com/wildfly/wildfly/pull/11295 with no regressions. Thanks!
> Weak affinity set up by EJB client 4 is not followed with invocations running against stateful bean deploment on WildFly 13
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10463
> URL: https://issues.jboss.org/browse/WFLY-10463
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 13.0.0.Beta1
> Environment: WildFly 13 beta runtimes. EJB client version does not matter (tested with {{org.wildfly:wildfly-ejb-client-bom:12.0.0.Final}}).
> Reporter: Michal Jurc
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 13.0.0.CR1
>
> Attachments: repro.zip
>
>
> Remote EJB client with {{InitialContext}} setting up weak affinity will not hold up the affinity, resulting in a behaviour that's different to previous releases of WildFly. In previous versions of WildFly, {{java.naming.provider.url}} property of {{InitialContext}} was enough to enforce weak affinity to a node in remote EJB client.
> This is a regression compared to WildFly 12. The client version does not change the behaviour, which leads me to believe the issue is server-side.
> Update: The issue affects only stateful bean invocations.
> {code}
> while (true) {
> try {
> final Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName());
> props.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
> final InitialContext ejbCtx = new InitialContext(props);
> final HelloBeanRemote bean = (HelloBeanRemote) ejbCtx
> .lookup("ejb:/server/HelloBean!" + HelloBeanRemote.class.getName() + "?stateful");
> for (int i = 0; i < 10; i++) {
> System.out.println(bean.hello());
> }
> } catch(Exception e) {
> System.out.println("Call failed!!!!");
> e.printStackTrace();
> }
> final Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName());
> props.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
> {code}
> {code}11:56:02,452 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 0
> 11:56:02,460 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 1
> 11:56:02,465 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 2
> 11:56:02,472 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 3
> 11:56:02,477 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 4
> 11:56:02,488 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 5
> 11:56:02,496 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 6
> 11:56:02,502 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 7
> 11:56:02,507 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 8
> 11:56:02,515 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 9
> 11:56:03,535 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 0
> 11:56:03,544 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 1
> 11:56:03,555 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 2
> 11:56:03,561 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 3
> 11:56:03,568 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 4
> 11:56:03,586 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 5
> 11:56:03,595 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 6
> 11:56:03,602 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 7
> 11:56:03,616 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 8
> 11:56:03,628 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 9
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Sande Gilda (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Sande Gilda commented on WFLY-9892:
-----------------------------------
[~pcraveiro] or [~olukas]:
I know this JIRA is closed, but I am trying to confirm that the _picketlink-sts_ quickstart does not exhibit any problems as a result of this upgrade. I tested it against the latest WildFly without any problems. This is what I did:
# I built the current WildFly server from source.
# I configured the server using the quickstart CLI file.
# I built and deployed the quickstart.
# I then successfully ran "mvn exec:java" with the following results:
{code}
sgilda@unknownC85B76AAB5B8 ~/GitRepos/eap-quickstarts/picketlink-sts (7.x) $ mvn exec:java
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building JBoss EAP Quickstart: picketlink-sts 7.2.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ picketlink-sts ---
Invoking token service to get SAML assertion for user:UserA with password:PassA
SAML assertion for user:UserA successfully obtained!
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="ID_c9267231-5143-40e7-b769-37e686137ba3" IssueInstant="2018-05-29T18:42:35.466Z" Version="2.0"><saml:Issuer>PicketLinkSTS</saml:Issuer><dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"/><dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><dsig:Reference URI="#ID_c9267231-5143-40e7-b769-37e686137ba3"><dsig:Transforms><dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><dsig:DigestValue>G9S6p//+EK0jSYQWcMKDFTLyUsQ=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>KprO97kq7aeoGNzbcuAj3qMrfSDWRRUak3dYV8G66Gbaq8upQfsYCTLnrOnJCH69AU6mcEUuWx69
DbtyI9ojnL193oDKZwGlV6pdPtNx+oTQrnXEXzncFqzlaLRdvqaIGokoOU2JD808NSEYuMC9EFpM
xdJ9bm6WLWKNGgIusFU=</dsig:SignatureValue><dsig:KeyInfo><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>suGIyhVTbFvDwZdx8Av62zmP+aGOlsBN8WUE3eEEcDtOIZgO78SImMQGwB2C0eIVMhiLRzVPqoW1
dCPAveTm653zHOmubaps1fY0lLJDSZbTbhjeYhoQmmaBro/tDpVw5lKJns2qVnMuRK19ju2dxpKw
lYGGtrP5VQv00dfNPbs=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue></dsig:KeyInfo></dsig:Signature><saml:Subject><saml:NameID NameQualifier="urn:picketlink:identity-federation">UserA</saml:NameID><saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/></saml:Subject><saml:Conditions NotBefore="2018-05-29T18:42:35.466Z" NotOnOrAfter="2018-05-29T20:42:39.466Z"/><saml:AuthnStatement AuthnInstant="2018-05-29T18:42:35.466Z"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:cm:bearer</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement></saml:Assertion>
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.607 s
[INFO] Finished at: 2018-05-29T14:42:37-04:00
[INFO] Final Memory: 16M/619M
[INFO] ------------------------------------------------------------------------
{code}
Can you confirm that there is no quickstart issue?
cc: [~emmartins]
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1587) X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3]
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1587?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1587:
---------------------------------
PR successfully checked against attached certificate too - thanks!
> X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3]
> -----------------------------------------------------------------------------
>
> Key: ELY-1587
> URL: https://issues.jboss.org/browse/ELY-1587
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Certificate Authority, X.500
> Affects Versions: 1.3.2.Final
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 1.4.0.CR1
>
> Attachments: client.asn1, client.cer
>
>
> Debugging revealed certificate use {{utf8String}} representation whereas Elytron is expecting {{printableString}}
> In rfc 5280 [1] chapter 4.1.2.4. Issuer there is specified value of subject/issuer can be of 5 types
> {code}
> DirectoryString ::= CHOICE {
> teletexString TeletexString (SIZE (1..MAX)),
> printableString PrintableString (SIZE (1..MAX)),
> universalString UniversalString (SIZE (1..MAX)),
> utf8String UTF8String (SIZE (1..MAX)),
> bmpString BMPString (SIZE (1..MAX)) }
> {code}
> However Elytron X500 principal decoder [2] can handle only 2 of them PRINTABLE_STRING_TYPE and IA5_STRING_TYPE (not sure which type of rfc does that match) [2]
> Definitely missing {{utf8String}} (my case). Also revise for backward compatibility {{teletexString}}, {{bmpString}} and {{universalString}}
> [1] https://www.ietf.org/rfc/rfc5280.txt
> [2] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1587) X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3]
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1587?page=com.atlassian.jira.plugin.s... ]
Jan Kalina edited comment on ELY-1587 at 5/29/18 2:00 PM:
----------------------------------------------------------
PR successfully checked against attached certificate too - thanks!
Automatic unit test use builder as suggested by David above.
was (Author: honza889):
PR successfully checked against attached certificate too - thanks!
> X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3]
> -----------------------------------------------------------------------------
>
> Key: ELY-1587
> URL: https://issues.jboss.org/browse/ELY-1587
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Certificate Authority, X.500
> Affects Versions: 1.3.2.Final
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 1.4.0.CR1
>
> Attachments: client.asn1, client.cer
>
>
> Debugging revealed certificate use {{utf8String}} representation whereas Elytron is expecting {{printableString}}
> In rfc 5280 [1] chapter 4.1.2.4. Issuer there is specified value of subject/issuer can be of 5 types
> {code}
> DirectoryString ::= CHOICE {
> teletexString TeletexString (SIZE (1..MAX)),
> printableString PrintableString (SIZE (1..MAX)),
> universalString UniversalString (SIZE (1..MAX)),
> utf8String UTF8String (SIZE (1..MAX)),
> bmpString BMPString (SIZE (1..MAX)) }
> {code}
> However Elytron X500 principal decoder [2] can handle only 2 of them PRINTABLE_STRING_TYPE and IA5_STRING_TYPE (not sure which type of rfc does that match) [2]
> Definitely missing {{utf8String}} (my case). Also revise for backward compatibility {{teletexString}}, {{bmpString}} and {{universalString}}
> [1] https://www.ietf.org/rfc/rfc5280.txt
> [2] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10479) mod_cluster "proxies" attribute is missing capability reference
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-10479:
-------------------------------------
Summary: mod_cluster "proxies" attribute is missing capability reference
Key: WFLY-10479
URL: https://issues.jboss.org/browse/WFLY-10479
Project: WildFly
Issue Type: Bug
Components: mod_cluster
Affects Versions: 13.0.0.Beta1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
This makes operations like {{/subsystem=modcluster/proxy=default:write-attribute(name=proxies,value=[x])}} accept any value and then fail on boot.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10463) Weak affinity set up by EJB client 4 is not followed with invocations running against stateful bean deploment on WildFly 13
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-10463?page=com.atlassian.jira.plugin... ]
Wolf-Dieter Fink commented on WFLY-10463:
-----------------------------------------
If I look to the client there are two loops,
Outer loop do a lookup for a SFSB, inner loop call this SFSB 10 times.
The SFSB proxy will stick to one node with the 10 invocations. The bean is not removed (which end in passivation forever BTW)
After that a new proxy is created from the InitialContext, as we don't have a way to suppress cluster (no annotation needed) the context received the cluster view, so if the nodes get clustered correct, the client will see both after the first invocation.
Because of that each lookup will randomly pick one of both nodes here, so the invocation jumps.
The only way to prevent is to use TX stickyness, in this case the client need to lookup a Tx and surround all invocations with that.
But this is not recommended as it will keep resources and locks for the complete transaction time and the client might not cleanup the transaction which cause issues.
Finally I think the behaviour is expected and spec compliant.
> Weak affinity set up by EJB client 4 is not followed with invocations running against stateful bean deploment on WildFly 13
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10463
> URL: https://issues.jboss.org/browse/WFLY-10463
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 13.0.0.Beta1
> Environment: WildFly 13 beta runtimes. EJB client version does not matter (tested with {{org.wildfly:wildfly-ejb-client-bom:12.0.0.Final}}).
> Reporter: Michal Jurc
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 13.0.0.CR1
>
> Attachments: repro.zip
>
>
> Remote EJB client with {{InitialContext}} setting up weak affinity will not hold up the affinity, resulting in a behaviour that's different to previous releases of WildFly. In previous versions of WildFly, {{java.naming.provider.url}} property of {{InitialContext}} was enough to enforce weak affinity to a node in remote EJB client.
> This is a regression compared to WildFly 12. The client version does not change the behaviour, which leads me to believe the issue is server-side.
> Update: The issue affects only stateful bean invocations.
> {code}
> while (true) {
> try {
> final Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName());
> props.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
> final InitialContext ejbCtx = new InitialContext(props);
> final HelloBeanRemote bean = (HelloBeanRemote) ejbCtx
> .lookup("ejb:/server/HelloBean!" + HelloBeanRemote.class.getName() + "?stateful");
> for (int i = 0; i < 10; i++) {
> System.out.println(bean.hello());
> }
> } catch(Exception e) {
> System.out.println("Call failed!!!!");
> e.printStackTrace();
> }
> final Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName());
> props.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
> {code}
> {code}11:56:02,452 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 0
> 11:56:02,460 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 1
> 11:56:02,465 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 2
> 11:56:02,472 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 3
> 11:56:02,477 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 4
> 11:56:02,488 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 5
> 11:56:02,496 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 6
> 11:56:02,502 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 7
> 11:56:02,507 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 8
> 11:56:02,515 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 9
> 11:56:03,535 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 0
> 11:56:03,544 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 1
> 11:56:03,555 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 2
> 11:56:03,561 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 3
> 11:56:03,568 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 4
> 11:56:03,586 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 5
> 11:56:03,595 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 6
> 11:56:03,602 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 7
> 11:56:03,616 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 8
> 11:56:03,628 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 9
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months