December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5705) Cluster is not created using TCPGOSSIP

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-5705?page=com.atlassian.jira.plugin.... ] Richard Janík commented on WFLY-5705: ------------------------------------- Hey Paul, the way I understand the description, the gossip router is bound to localhost:12011 - that means it listens on this address. When the servers are bound to a different address (a different interface too - not loopback) they too listen on that different address for requests, but should still try to talk to gossip router on localhost:12011 because that's in the initial_hosts property. They don't have to be _bound_ to the same address as the gossip router. Now, if the server and gossip router were on a different machine, that wouldn't work. But the issue here is that it doesn't work on a single machine either. > Cluster is not created using TCPGOSSIP > -------------------------------------- > > Key: WFLY-5705 > URL: https://issues.jboss.org/browse/WFLY-5705 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR3 > Reporter: Ivan Straka > Assignee: Paul Ferraro > Priority: Minor > > If gossip router is bound to localhost and nodes are not, they won't make cluster. But if nodes are bound to localhost and only port offset is used, they will make cluster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-388) On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-388?page=com.atlassian.jira.plugin.sy... ] Martin Choma updated ELY-388: ----------------------------- Attachment: server_debug.log > On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string > ----------------------------------------------------------------------------------------- > > Key: ELY-388 > URL: https://issues.jboss.org/browse/ELY-388 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.0.2.Final > Environment: IBM java 1.8 SR1 FP10 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Attachments: server_debug.log > > > On ibm java 1.8 I can't establish HTTPS connection using TLSv1 cipher string. On EAP 6.4 it is possible. > Handshake ends with message > javax.net.ssl.SSLHandshakeException: No appropriate protocol, may be no appropriate cipher suite specified or protocols are deactivated > Note, issue apply to enabled-cipher-suites="TLSv1", not enabled-protocols="TLSv1" - that works OK. > According to OpenSSL documentation [1], cipher suites corresponding with TLSv1 cipher string should be available for handshake. > According to Elytron documentation [2], cipher suites corresponding with TLSv1 cipher string should be available for handshake. > [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-STRINGS > [2] http://wildfly-security.github.io/wildfly-elytron/org/wildfly/security/ss... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-388) On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-388?page=com.atlassian.jira.plugin.sy... ] Martin Choma commented on ELY-388: ---------------------------------- No it doesn't . I attach server_debug.log with server output with -Djavax.net.debug=all. > On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string > ----------------------------------------------------------------------------------------- > > Key: ELY-388 > URL: https://issues.jboss.org/browse/ELY-388 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.0.2.Final > Environment: IBM java 1.8 SR1 FP10 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Attachments: server_debug.log > > > On ibm java 1.8 I can't establish HTTPS connection using TLSv1 cipher string. On EAP 6.4 it is possible. > Handshake ends with message > javax.net.ssl.SSLHandshakeException: No appropriate protocol, may be no appropriate cipher suite specified or protocols are deactivated > Note, issue apply to enabled-cipher-suites="TLSv1", not enabled-protocols="TLSv1" - that works OK. > According to OpenSSL documentation [1], cipher suites corresponding with TLSv1 cipher string should be available for handshake. > According to Elytron documentation [2], cipher suites corresponding with TLSv1 cipher string should be available for handshake. > [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-STRINGS > [2] http://wildfly-security.github.io/wildfly-elytron/org/wildfly/security/ss... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1172) SimpleResourceDefinition.Parameters should support setting access constraints

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1172?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet reassigned WFCORE-1172: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Tomaz Cerar) > SimpleResourceDefinition.Parameters should support setting access constraints > ----------------------------------------------------------------------------- > > Key: WFCORE-1172 > URL: https://issues.jboss.org/browse/WFCORE-1172 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Beta1 > > > There are a lot of SimpleResourceDefinition impls that are overriding getAccessConstraints. We should support passing in the constraints via the Parameters object passed to the constructor. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario

by Michal Vinkler (JIRA)

[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ] Michal Vinkler updated WFLY-5822: --------------------------------- Affects Version/s: 10.0.0.CR5 > Clustering performance regression in ejbremote-dist-sync scenario > ------------------------------------------------------------------ > > Key: WFLY-5822 > URL: https://issues.jboss.org/browse/WFLY-5822 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR5 > Reporter: Michal Vinkler > Assignee: Paul Ferraro > > Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why? > Compare these results: > stress-ejbremote-dist-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] > --------------------------------------- > Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand: > stress-ejbremote-repl-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario

by Michal Vinkler (JIRA)

Michal Vinkler created WFLY-5822: ------------------------------------ Summary: Clustering performance regression in ejbremote-dist-sync scenario Key: WFLY-5822 URL: https://issues.jboss.org/browse/WFLY-5822 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Michal Vinkler Assignee: Paul Ferraro Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why? Compare these results: stress-ejbremote-dist-sync 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] --------------------------------------- Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand: stress-ejbremote-repl-sync 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1199) CLI Lists in non-interactive mode are erroneously split into multiple commands

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1199?page=com.atlassian.jira.plugi... ] Ryan Emerson commented on WFCORE-1199: -------------------------------------- My proposed solution requires that lists containing > 1 value must be contained within [] brackets. This prevents the list from being perceived as multiple commands and allows the list to be passed to the appropriate handler where the [] brackets can be removed and the list processed as expected. So for example the valid command to add a module would become: ./bin/jboss-cli.sh -c --controller=localhost --commands="module add --name=test --resources=test.jar --dependencies=[dep1,dep2] and the resulting module.xml dependencies would be: <dependencies> <module name="dep1"/> <module name="dep2"/> </dependencies> > CLI Lists in non-interactive mode are erroneously split into multiple commands > ------------------------------------------------------------------------------ > > Key: WFCORE-1199 > URL: https://issues.jboss.org/browse/WFCORE-1199 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Modules, Patching > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > The problem arises because commands entered in non-interactive mode are split by the "," character. Therefore, in the case of: > "./bin/jboss-cli.sh -c --controller=localhost --commands="module add --name=test --resources=test.jar --dependencies=dep1,dep2" > the cli is incorrectly splitting the request into two distinct commands: > 1. module add --name=test --resources=test.jar --dependencies=dep1 > 2. dep2 > The reason this behaviour is not observed in interactive mode is because multiple commands can not be specified. However, in non-interactive mode --commands=ls,pwd is valid and should result in the execution of ls followed by pwd. > This problem is not restricted to the module command, as it affects all commands entered in non-interactive mode that require a comma-separated list as an argument. So far this appears to be PatchHanlder.java, ASModuleHandler.java and DeploymentOverlayHandler.java. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1199) CLI Lists in non-interactive mode are erroneously split into multiple commands

by Ryan Emerson (JIRA)

Ryan Emerson created WFCORE-1199: ------------------------------------ Summary: CLI Lists in non-interactive mode are erroneously split into multiple commands Key: WFCORE-1199 URL: https://issues.jboss.org/browse/WFCORE-1199 Project: WildFly Core Issue Type: Bug Components: CLI, Modules, Patching Reporter: Ryan Emerson Assignee: Ryan Emerson The problem arises because commands entered in non-interactive mode are split by the "," character. Therefore, in the case of: "./bin/jboss-cli.sh -c --controller=localhost --commands="module add --name=test --resources=test.jar --dependencies=dep1,dep2" the cli is incorrectly splitting the request into two distinct commands: 1. module add --name=test --resources=test.jar --dependencies=dep1 2. dep2 The reason this behaviour is not observed in interactive mode is because multiple commands can not be specified. However, in non-interactive mode --commands=ls,pwd is valid and should result in the execution of ls followed by pwd. This problem is not restricted to the module command, as it affects all commands entered in non-interactive mode that require a comma-separated list as an argument. So far this appears to be PatchHanlder.java, ASModuleHandler.java and DeploymentOverlayHandler.java. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5821) Data source connection-properties is defined as an attribute and a sub-resource

by Stefano Maestri (JIRA)

Stefano Maestri created WFLY-5821: ------------------------------------- Summary: Data source connection-properties is defined as an attribute and a sub-resource Key: WFLY-5821 URL: https://issues.jboss.org/browse/WFLY-5821 Project: WildFly Issue Type: Bug Components: JCA Reporter: Stefano Maestri Assignee: Stefano Maestri Priority: Critical The {{subsystem=datasource/data-source=*}} resource has a {{connection-properties}} attribute and a {{connection-properties}} sub-resource. Since DMR is a tree structure each child must have a unique key. Since the parent resource has a {{connection-properties}} attribute and sub-resource with a {{read-resource}} operation you will only get one of the values. Also writing to the {{connection-properties}} attribute fails to marshal the XML since marshaller expects the value to look something like {code} { "key" => { "value" => "real-value" } } {code} But the resource definition expects {code} { "key" => "real-value" } {code} The attribute does not appear to be in EAP 6.4. It is however in WildFly 8.x and 9.x. Some further research should be done, but the attribute could likely be removed. Not having the attribute would also be more consistent with XA data sources. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5351) querying TimerService information from CLI fails for canceled timer

by Matthieu Brouillard (JIRA)

[ https://issues.jboss.org/browse/WFLY-5351?page=com.atlassian.jira.plugin.... ] Matthieu Brouillard updated WFLY-5351: -------------------------------------- Affects Version/s: 10.0.0.CR4 10.0.0.CR5 > querying TimerService information from CLI fails for canceled timer > ------------------------------------------------------------------- > > Key: WFLY-5351 > URL: https://issues.jboss.org/browse/WFLY-5351 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.1.Final, 10.0.0.CR2, 10.0.0.CR4, 10.0.0.CR5 > Environment: probably not relevant but here is my environment > {{Java Version : 1.8.0_60 > Java Vendor : Oracle Corporation > OS Hostname : PAMWX125 > OS Architecture : amd64 > OS Name : Windows 7 > }} > Reporter: Matthieu Brouillard > Attachments: patch1.diff, timer-cli-failure.zip, WFLY-5351diff > > > When (at least) a persistent calendar timer is created then cancelled, querying TimerService information via CLI (script or library) fails when retrieving also runtime information. > We discovered the issue because our arquillian tests are failing due to some code in arquillian that fires the equivalent of the provided CLI command below when remotes tests are executed. > Attached is a proposed patch and a demo project to reproduce in a simple way. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2015