December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5824) Messaging outgoing interceptors are not set

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-5824: --------------------------------- Summary: Messaging outgoing interceptors are not set Key: WFLY-5824 URL: https://issues.jboss.org/browse/WFLY-5824 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.0.0.CR4 Reporter: Jeff Mesnil Assignee: Jeff Mesnil In org.wildfly.extension.messaging.activemq.ServerAdd#processOutgoingInterceptors, the interceptors are wrongly added to the incoming interceptors instead of the outgoing interceptors. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

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

by Ryan Emerson (JIRA)

Ryan Emerson created WFCORE-1200: ------------------------------------ Summary: CLI Lists in non-interactive mode are erroneously split into multiple commands Key: WFCORE-1200 URL: https://issues.jboss.org/browse/WFCORE-1200 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)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5823) Register callbacks for messaging paths

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5823?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-5823: ------------------------------ Priority: Minor (was: Major) > Register callbacks for messaging paths > -------------------------------------- > > Key: WFLY-5823 > URL: https://issues.jboss.org/browse/WFLY-5823 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR4 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5823) Register callbacks for messaging paths

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-5823: --------------------------------- Summary: Register callbacks for messaging paths Key: WFLY-5823 URL: https://issues.jboss.org/browse/WFLY-5823 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.0.0.CR4 Reporter: Jeff Mesnil Assignee: Jeff Mesnil -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[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)

8 years, 11 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)

8 years, 11 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)

8 years, 11 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)

8 years, 11 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)

8 years, 11 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)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2015