November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3435) Expose capability/requirements to deployments

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3435?page=com.atlassian.jira.plugi... ] Tomaz Cerar moved WFLY-9578 to WFCORE-3435: ------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-3435 (was: WFLY-9578) Affects Version/s: 3.0.9.Final (was: 11.0.0.Final) > Expose capability/requirements to deployments > --------------------------------------------- > > Key: WFCORE-3435 > URL: https://issues.jboss.org/browse/WFCORE-3435 > Project: WildFly Core > Issue Type: Enhancement > Affects Versions: 3.0.9.Final > Reporter: Bob McWhirter > Assignee: Jason Greene > > For WildFly Swarm, we use a fair amount of ServiceActivators in deployments. > Moving to WF11, we have seen some of our dependencies on Service<T>, such as NamingService.SERVICE_NAME result in deprecation warnings suggesting we move to using CAPABILITY_NAME. From within a ServiceActivator, within a deployment, this appears to not be a possibility. > Filed per [~ctomc] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9578) Expose capability/requirements to deployments

by Bob McWhirter (JIRA)

Bob McWhirter created WFLY-9578: ----------------------------------- Summary: Expose capability/requirements to deployments Key: WFLY-9578 URL: https://issues.jboss.org/browse/WFLY-9578 Project: WildFly Issue Type: Enhancement Affects Versions: 11.0.0.Final Reporter: Bob McWhirter Assignee: Jason Greene For WildFly Swarm, we use a fair amount of ServiceActivators in deployments. Moving to WF11, we have seen some of our dependencies on Service<T>, such as NamingService.SERVICE_NAME result in deprecation warnings suggesting we move to using CAPABILITY_NAME. From within a ServiceActivator, within a deployment, this appears to not be a possibility. Filed per [~ctomc] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1360) Dumping leak connections in WildFly with IronJacamar not Working

by Evandro Pomatti (JIRA)

Evandro Pomatti created JBJCA-1360: -------------------------------------- Summary: Dumping leak connections in WildFly with IronJacamar not Working Key: JBJCA-1360 URL: https://issues.jboss.org/browse/JBJCA-1360 Project: IronJacamar Issue Type: Bug Reporter: Evandro Pomatti I am trying to dump leaked connections managed by a MySQL Data Source in WildFly 10.1, but I am not able to find the leak file or the leak dump. Why is the leaks.txt file not being generated? And also, where should I look for the file? I found nowhere in the documentation where the leak file is to be found. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1355) set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1355?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1355: ------------------------------------------------ Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1497591|https://bugzilla.redhat.com/show_bug.cgi?id=1497591] from NEW to MODIFIED > set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second > ---------------------------------------------------------------------------------------------------- > > Key: JBJCA-1355 > URL: https://issues.jboss.org/browse/JBJCA-1355 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Reporter: Masafumi Miura > Assignee: Stefano Maestri > > {{set-tx-query-timeout}} setting does not work when the remaining transaction timeout is shorter than one second (between 0-999 millis) due to incorrect round-up in IronJacamar {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}}. > --- > {{WrappedConnection#checkConfiguredQueryTimeout()}} checks the returned value from {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} and set the value to query timeout if it's larger than 0. If it's not larger than 0, the configured query timeout ({{query-timeout}} in datasource setting) is used. This behavior itself is ok. > However, {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} incorrectly rounds up the returned value from transaction manager's {{TransactionTimeoutConfiguration#getTimeLeftBeforeTransactionTimeout()}}. And it results in returning 0 when the remaining transaction timeout is between 0-999 millis. This causes the issue. > Here's the related code from 1.3.7.Final (It's same in the latest 1.3 branch and 1.4 branch): > - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... > {code} > 2022 /** > 2023 * Check configured query timeout > 2024 * @param ws The statement > 2025 * @param explicitTimeout An explicit timeout value set > 2026 * @exception SQLException Thrown if an error occurs > 2027 */ > 2028 void checkConfiguredQueryTimeout(WrappedStatement ws, int explicitTimeout) throws SQLException > 2029 { > 2030 if (mc == null || dataSource == null) > 2031 return; > 2032 > 2033 int timeout = 0; > 2034 > 2035 // Use the transaction timeout > 2036 if (mc.isTransactionQueryTimeout()) > 2037 { > 2038 timeout = dataSource.getTimeLeftBeforeTransactionTimeout(); > 2039 if (timeout > 0 && explicitTimeout > 0 && timeout > explicitTimeout) > 2040 timeout = explicitTimeout; > 2041 } > 2042 > 2043 // Look for a configured value > 2044 if (timeout <= 0 && explicitTimeout <= 0) > 2045 timeout = mc.getQueryTimeout(); > 2046 > 2047 if (timeout > 0) > 2048 ws.setQueryTimeout(timeout); > 2049 } > {code} > - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... > {code} > 190 /** > 191 * Get the time left before a transaction timeout > 192 * @return The amount in seconds; <code>-1</code> if no timeout > 193 * @exception SQLException Thrown if an error occurs > 194 */ > 195 protected int getTimeLeftBeforeTransactionTimeout() throws SQLException > 196 { > 197 try > 198 { > 199 if (cm instanceof TransactionTimeoutConfiguration) > 200 { > 201 long timeout = ((TransactionTimeoutConfiguration) cm).getTimeLeftBeforeTransactionTimeout(true); > 202 // No timeout > 203 if (timeout == -1) > 204 return -1; > 205 // Round up to the nearest second > 206 long result = timeout / 1000; > 207 if ((result % 1000) != 0) > 208 ++result; > 209 return (int) result; > 210 } > 211 else > 212 return -1; > 213 } > 214 catch (RollbackException e) > 215 { > 216 throw new SQLException(e); > 217 } > 218 } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2153) DMN compiler throws NPE when underlying compilation fails and returns null

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-2153: ------------------------------------- Summary: DMN compiler throws NPE when underlying compilation fails and returns null Key: DROOLS-2153 URL: https://issues.jboss.org/browse/DROOLS-2153 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.4.1.Final Reporter: Tibor Zimányi Assignee: Tibor Zimányi Fix For: 7.5.0.Final When an underlying compilation fails and returns null, the compiler throws NPE. See the code here [1]. I will provide a PR with a fix and a reproducer. [1] https://github.com/baldimir/drools/blob/7a6db1342925872a898dee3f1d03f835b... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-457) SASL SAML Authentication Mechanism

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-457?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-457: ------------------------------ Assignee: Jan Kalina > SASL SAML Authentication Mechanism > ---------------------------------- > > Key: ELY-457 > URL: https://issues.jboss.org/browse/ELY-457 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SASL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 2.0.0.Alpha1 > > > https://tools.ietf.org/html/rfc6595 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.

by kfir avraham (JIRA)

[ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.... ] kfir avraham commented on JGRP-2237: ------------------------------------ i changed 'VERIFY_SUSPECT' timeout to 500 (as in your configuration), and i got the same issue (see log below). when i changed 'port_range', they not discovered each other from the first time. *it is happened also after shutdown for a few minutes, and not just for restart. 2017-11-28 01:33:47:0975 + 1 Nov-28-2017 01:33:47 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [INFO] - clm-tlv-spih62-654: no members discovered after 30021 ms: creating cluster as first member 2017-11-28 01:33:47:0975 + 2 Nov-28-2017 01:33:47 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [INFO] - clm-tlv-spih62-654: installing view [clm-tlv-spih62-654|0] (1) [clm-tlv-spih62-654] 2017-11-28 01:33:47:0975 + 4 Nov-28-2017 01:33:47 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [INFO] - clm-tlv-spih62-654: created cluster (first member). My view is [clm-tlv-spih62-654|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl 2017-11-28 01:33:58:0747 + 57 Nov-28-2017 01:33:58 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [ViewHandler-11,clm-tlv-spih62-654] [INFO] - clm-tlv-spih62-654: joiners=[clm-tlv-spk9g4-11729], suspected=[], leaving=[], new view: [clm-tlv-spih62-654|1] (2) [clm-tlv-spih62-654, clm-tlv-spk9g4-11729] 2017-11-28 01:33:58:0747 + 58 Nov-28-2017 01:33:58 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [ViewHandler-11,clm-tlv-spih62-654] [INFO] - clm-tlv-spih62-654: mcasting view [clm-tlv-spih62-654|1] (2) [clm-tlv-spih62-654, clm-tlv-spk9g4-11729] 2017-11-28 01:33:58:0747 + 59 Nov-28-2017 01:33:58 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [ViewHandler-11,clm-tlv-spih62-654] [INFO] - clm-tlv-spih62-654: installing view [clm-tlv-spih62-654|1] (2) [clm-tlv-spih62-654, clm-tlv-spk9g4-11729] 2017-11-28 01:33:58:0747 + 61 Nov-28-2017 01:33:58 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [ViewHandler-11,clm-tlv-spih62-654] [INFO] - clm-tlv-spih62-654: sending join-rsp to clm-tlv-spk9g4-11729: view=[clm-tlv-spih62-654|1] (2) [clm-tlv-spih62-654, clm-tlv-spk9g4-11729] (2 mbrs) 2017-11-28 01:34:00:0294 + 62 Nov-28-2017 01:33:59 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [ViewHandler-11,clm-tlv-spih62-654] [INFO] - clm-tlv-spih62-654: got all ACKs (1) for view [clm-tlv-spih62-654|1] in 1331 ms 2017-11-28 01:34:57:0822 + 66 Nov-28-2017 01:34:57 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [ViewHandler-14,clm-tlv-spih62-654] [INFO] - clm-tlv-spih62-654: joiners=[], suspected=[], leaving=[clm-tlv-spih62-654], new view: [clm-tlv-spk9g4-11729|2] (1) [clm-tlv-spk9g4-11729] 2017-11-28 01:34:57:0822 + 67 Nov-28-2017 01:34:57 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [ViewHandler-14,clm-tlv-spih62-654] [INFO] - clm-tlv-spih62-654: sending LEAVE response to clm-tlv-spih62-654 2017-11-28 01:34:57:0822 + 68 Nov-28-2017 01:34:57 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [ViewHandler-14,clm-tlv-spih62-654] [INFO] - clm-tlv-spih62-654: mcasting view [clm-tlv-spk9g4-11729|2] (1) [clm-tlv-spk9g4-11729] 2017-11-28 01:34:57:0822 + 69 Nov-28-2017 01:34:57 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [ViewHandler-14,clm-tlv-spih62-654] [INFO] - clm-tlv-spih62-654: got all ACKs (1) for view [clm-tlv-spk9g4-11729|2] in 16 ms 2017-11-28 01:36:26:0919 + 86 Nov-28-2017 01:36:26 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [INFO] - clm-tlv-spih62-28153: discovery took 30023 ms, members: 1 rsps (0 coords) [done] 2017-11-28 01:36:26:0919 + 87 Nov-28-2017 01:36:26 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [INFO] - clm-tlv-spih62-28153: could not determine coordinator from rsps 1 rsps (0 coords) [done] 2017-11-28 01:36:26:0919 + 88 Nov-28-2017 01:36:26 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [INFO] - clm-tlv-spih62-28153: nodes to choose new coord from are: [clm-tlv-spih62-28153, clm-tlv-spk9g4-11729] 2017-11-28 01:36:26:0919 + 89 Nov-28-2017 01:36:26 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [INFO] - clm-tlv-spih62-28153: I (clm-tlv-spih62-28153) am the first of the nodes, will become coordinator 2017-11-28 01:36:26:0919 + 90 Nov-28-2017 01:36:26 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [INFO] - clm-tlv-spih62-28153: installing view [clm-tlv-spih62-28153|0] (1) [clm-tlv-spih62-28153] 2017-11-28 01:36:26:0919 + 92 Nov-28-2017 01:36:26 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [INFO] - clm-tlv-spih62-28153: created cluster (first member). My view is [clm-tlv-spih62-28153|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > The single node in the cluster not become a coordinator after coordinator leave. > -------------------------------------------------------------------------------- > > Key: JGRP-2237 > URL: https://issues.jboss.org/browse/JGRP-2237 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.2, 4.0.8 > Reporter: kfir avraham > Assignee: Bela Ban > Priority: Minor > Attachments: test.xml > > > I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator. > When the first one is rejoin, he could not determine coordinator and select new one from the nodes list. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2238) KUBE_PING should read old env variables and should warn

by Galder Zamarreño (JIRA)

Galder Zamarreño created JGRP-2238: -------------------------------------- Summary: KUBE_PING should read old env variables and should warn Key: JGRP-2238 URL: https://issues.jboss.org/browse/JGRP-2238 Project: JGroups Issue Type: Enhancement Reporter: Galder Zamarreño Assignee: Bela Ban While I was upgrading Infinispan cluster on docker, I realised I was using old environment properties. These were neither read nor was any WARN messages being reported. The code should read the current properties and if not present should try to read the old ones and assign them. Then, we should check if both new and old properties are in use and we should also check if only old ones in use. Both scenarios should warn the user. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2238) KUBE_PING should read old env variables and should warn

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/JGRP-2238?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned JGRP-2238: -------------------------------------- Assignee: Galder Zamarreño (was: Bela Ban) > KUBE_PING should read old env variables and should warn > ------------------------------------------------------- > > Key: JGRP-2238 > URL: https://issues.jboss.org/browse/JGRP-2238 > Project: JGroups > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > While I was upgrading Infinispan cluster on docker, I realised I was using old environment properties. These were neither read nor was any WARN messages being reported. > The code should read the current properties and if not present should try to read the old ones and assign them. Then, we should check if both new and old properties are in use and we should also check if only old ones in use. Both scenarios should warn the user. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2673) HTTP redirect if both http and https socket-binding is configured for http-interface

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2673?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Śmietanko reassigned WFCORE-2673: ------------------------------------------------ Assignee: Bartosz Spyrko-Śmietanko > HTTP redirect if both http and https socket-binding is configured for http-interface > ------------------------------------------------------------------------------------ > > Key: WFCORE-2673 > URL: https://issues.jboss.org/browse/WFCORE-2673 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ondrej Lukas > Assignee: Bartosz Spyrko-Śmietanko > > In case when both http and https socket-binding is configured for management http-interface and http port is accessed then server tries to redirect automatically to https port. Access http is not possible. > It causes that it is impossible to connect to http-interface with clients which do not supports https (even if http port is provided by application server), i.e. following ModelControllerClient is not able to connect to http-interface when both http and https socket-binding is configured: > {code} > ModelControllerClient client = ModelControllerClient.Factory > .create(new ModelControllerClientConfiguration.Builder() > .setProtocol("remote+http") > .setPort(9990) > .setHostName("localhost") > .setConnectionTimeout(10000).build()) > {code} > See: > {code} > curl -v -H 'Upgrade: jboss-remoting' http://localhost:9990 > * Rebuilt URL to: http://localhost:9990/ > * Hostname was NOT found in DNS cache > * Trying 127.0.0.1... > * Connected to localhost (127.0.0.1) port 9990 (#0) > > GET / HTTP/1.1 > > User-Agent: curl/7.38.0 > > Host: localhost:9990 > > Accept: */* > > Upgrade: jboss-remoting > > > < HTTP/1.1 302 Found > < Connection: keep-alive > < Location: https://localhost:9993/ > < Content-Length: 0 > < Date: Thu, 13 Apr 2017 11:59:56 GMT > < > * Connection #0 to host localhost left intact > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 November 2017