January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-369) HostControllerConnectionService connection timeout is not configurable

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFCORE-369?page=com.atlassian.jira.plugin... ] Bartosz Baranowski resolved WFCORE-369. --------------------------------------- Resolution: Out of Date > HostControllerConnectionService connection timeout is not configurable > ---------------------------------------------------------------------- > > Key: WFCORE-369 > URL: https://issues.jboss.org/browse/WFCORE-369 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Dominik Pospisil > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Beta1 > > > I am seeing intermittent failures when starting AS7 in domain mode. It seems that this is due to HostControllerConnectionService has hardcoded 15s timeout when trying to connect to DC. I think that this value should be configurable. > HostControllerConnectionService.java: > ... > ProtocolChannelClient.Configuration configuration = new ProtocolChannelClient.Configuration(); > configuration.setEndpoint(endpointInjector.getValue()); > configuration.setConnectionTimeout(15000); > configuration.setUri(new URI("remote://" + hcAddressInjector.getValue().getHostName() + ":" + hcAddressInjector.getValue().getPort())); > client = ProtocolChannelClient.create(configuration); > ... > Exception I am getting: > [Server:server-two] 13:52:54,766 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.host.controller.channel: org.jboss.msc.service.StartException in service jboss.host.controller.channel: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost.localdomain:9999. The connection timed out > [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:103) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT] > [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] > [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] > [Server:server-two] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22] > [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22] > [Server:server-two] at java.lang.Thread.run(Thread.java:679) [:1.6.0_22] > [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost.localdomain:9999. The connection timed out > [Server:server-two] at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:166) [jboss-as-protocol-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT] -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-438) The CLI freezes in phase of requesting username/password

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-438?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-438: ------------------------------------------------ Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1169300|https://bugzilla.redhat.com/show_bug.cgi?id=1169300] from ON_QA to VERIFIED > The CLI freezes in phase of requesting username/password > -------------------------------------------------------- > > Key: WFCORE-438 > URL: https://issues.jboss.org/browse/WFCORE-438 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha13 > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Fix For: 1.0.0.Alpha15 > > > CLI doesn't terminate -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-499) System properties are broken in domain mode

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-499: ------------------------------------- Summary: System properties are broken in domain mode Key: WFCORE-499 URL: https://issues.jboss.org/browse/WFCORE-499 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha15 Reporter: Stuart Douglas Assignee: Brian Stansberry There seems to be some weirdness in how system properties are being propagated to domain mode servers, and in many cases they are not being applied. This appears to be an issue with the boot time handling of system properties. The only way I could get the property to be applied was to start the server first, then add the property using boot-time=false, although even in this case the property will disappear if the domain is restarted or the server is reloaded. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3688) datasources subsystem: datasource and xa-datasource properties do not support the use of multiple values for one property

by Jeff Zhang (JIRA)

[ https://issues.jboss.org/browse/WFLY-3688?page=com.atlassian.jira.plugin.... ] Jeff Zhang commented on WFLY-3688: ---------------------------------- Hi Tom, The datasource extension is supporting multiple values split by charactor ',' https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or... And I think we can input properties information as a string like: [standalone@localhost:9999 /] /system-property=foo5:add(value="name=org.foo.bar,version=1.2") {"outcome" => "success"} [standalone@localhost:9999 /] /system-property=foo5/:read-resource { "outcome" => "success", "result" => {"value" => "name=org.foo.bar,version=1.2"} } * change system-property to datasource property * Could you try it and see if it meet your need? Or please give more information (db connection param, config file) that I can reproduce this locally and find a fix. Thanks > datasources subsystem: datasource and xa-datasource properties do not support the use of multiple values for one property > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3688 > URL: https://issues.jboss.org/browse/WFLY-3688 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.1.0.Final > Reporter: Tom Fonteyne > Assignee: Jeff Zhang > > The oracle JDBC driver had a method: > setConnectionProperties(java.util.Properties value) > which is needed to set several connection properties for datasources. > Most (all?) of these connection properties do not have individual setters. > WildFly does not support setting a "Properties" value for "datasource-property" -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2900) Performance issue with Xalan transformer and very large text nodes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2900?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2900: ----------------------------------------------- David Walluck <dwalluck(a)redhat.com> changed the Status of [bug 1175982|https://bugzilla.redhat.com/show_bug.cgi?id=1175982] from NEW to ASSIGNED > Performance issue with Xalan transformer and very large text nodes > ------------------------------------------------------------------ > > Key: WFLY-2900 > URL: https://issues.jboss.org/browse/WFLY-2900 > Project: WildFly > Issue Type: Bug > Components: XML Frameworks > Reporter: Kyle Lape > Assignee: Jason Greene > Priority: Blocker > Fix For: 9.0.0.Beta1 > > > It has been observed that when using the {{Transfomer}} to convert a {{StreamSource}} to {{DOMResult}}, the performance of Transform gets worse as the size of the > character data increases. If you have a 50MB text blob in XML, this will take a very long time to finish. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2900) Performance issue with Xalan transformer and very large text nodes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2900?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2900: ----------------------------------------------- Kyle Lape <klape(a)redhat.com> changed the Status of [bug 1065128|https://bugzilla.redhat.com/show_bug.cgi?id=1065128] from ASSIGNED to POST > Performance issue with Xalan transformer and very large text nodes > ------------------------------------------------------------------ > > Key: WFLY-2900 > URL: https://issues.jboss.org/browse/WFLY-2900 > Project: WildFly > Issue Type: Bug > Components: XML Frameworks > Reporter: Kyle Lape > Assignee: Jason Greene > Priority: Blocker > Fix For: 9.0.0.Beta1 > > > It has been observed that when using the {{Transfomer}} to convert a {{StreamSource}} to {{DOMResult}}, the performance of Transform gets worse as the size of the > character data increases. If you have a 50MB text blob in XML, this will take a very long time to finish. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4211) MBean implementation lifecycle methods in MSC threads

by Luke Meyers (JIRA)

[ https://issues.jboss.org/browse/WFLY-4211?page=com.atlassian.jira.plugin.... ] Luke Meyers commented on WFLY-4211: ----------------------------------- Forgive me if I'm misunderstanding this project's workflow, but since there's a Git Pull Request that fixes this issue, shouldn't it be in "Pull Request Sent" state rather than "Open"? > MBean implementation lifecycle methods in MSC threads > ----------------------------------------------------- > > Key: WFLY-4211 > URL: https://issues.jboss.org/browse/WFLY-4211 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > MBean lifecycle methods should not be invoked from MSC threads, the implementation of these may block the thread, for instance due to a JNDI bind. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2900) Performance issue with Xalan transformer and very large text nodes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2900?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2900: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1065128, https://bugzilla.redhat.com/show_bug.cgi?id=1175982, https://bugzilla.redhat.com/show_bug.cgi?id=1181337 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1065128, https://bugzilla.redhat.com/show_bug.cgi?id=1175982) > Performance issue with Xalan transformer and very large text nodes > ------------------------------------------------------------------ > > Key: WFLY-2900 > URL: https://issues.jboss.org/browse/WFLY-2900 > Project: WildFly > Issue Type: Bug > Components: XML Frameworks > Reporter: Kyle Lape > Assignee: Jason Greene > Priority: Blocker > Fix For: 9.0.0.Beta1 > > > It has been observed that when using the {{Transfomer}} to convert a {{StreamSource}} to {{DOMResult}}, the performance of Transform gets worse as the size of the > character data increases. If you have a 50MB text blob in XML, this will take a very long time to finish. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3532) RemoteFailoverTestCase still fails intermittently

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-3532: ------------------------------------------- I'll try and explain a little better: When we make an invocation, we start out with an EJBClientInvocationContext representing the invocation client and the invocation parameters. We then choose an EJBReceiver which can handle the invocation and create an EJBReceiverInvocationContext to represent it. The EJBReceiverInvocationContext refers to the EJBReceiver and also Channel used. When we successfully send out an invocation on a channel, we store the fact that we need to wai for a response, and store this fact in a map (ChannelAssociation.waitingMethodInvocations) specifying the invocationId and the EJBReceiverInvocationContext. If the response does not return, or returns with an EJBUnavailableException, we retry the invocation, ultimately using a new EJBReceiverInvocationContext (and so a new Channel). What was causing the exception was that, before retrying, we were not removing the the stored fact that we were waiting on an old EJBReceiverInvocationContext and Channel. When that Channel closed as a result of the server shutting down, it triggered the exception that we were seeing, despite the fact that a new EJBReceiver was being chosen and the retry of the invocation was failing over correctly. > RemoteFailoverTestCase still fails intermittently > -------------------------------------------------- > > Key: WFLY-3532 > URL: https://issues.jboss.org/browse/WFLY-3532 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > Fail rate is at 1.5% atm. > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI... > (making affected version alpha, but indeed its master) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4244) Naming alias to datasource in deployment

by Frank Denninger (JIRA)

Frank Denninger created WFLY-4244: ------------------------------------- Summary: Naming alias to datasource in deployment Key: WFLY-4244 URL: https://issues.jboss.org/browse/WFLY-4244 Project: WildFly Issue Type: Bug Components: Naming Affects Versions: 8.2.0.Final Reporter: Frank Denninger Assignee: David Lloyd Priority: Minor Using a name alias to a datasource that is defined in the deployment (with a *-ds.xml in the .war) causes a npe when jpa tries to resolve that datasource with the alias. <lookup name="java:/de/datasource/sub" lookup="java:/de/datasource/main"/> When both the datasource and name-alias are defined in the standalone.xml it works as expected. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 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 January 2015