July 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-25) Windows PowerShell scripts in bin

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-25?page=com.atlassian.jira.plugin.... ] Brian Stansberry moved WFLY-676 to WFCORE-25: --------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-25 (was: WFLY-676) Component/s: Scripts (was: Scripts) Fix Version/s: 1.0.0.Alpha4 (was: 9.0.0.CR1) > Windows PowerShell scripts in bin > --------------------------------- > > Key: WFCORE-25 > URL: https://issues.jboss.org/browse/WFCORE-25 > Project: WildFly Core > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Scripts > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha4 > > > Add .psh scripts that match the functionality of our .sh scripts. Leave the .bat scripts in their current limited-functionality form for people still on XP, but use PowerShell as the recommended Windows scripting language. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3201) Channel end notification received, closing channel ... should be logged at debug

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3201?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-3201: ---------------------------------------- Brad, please resolve this when WildFly includes the version of remote-naming with this fix. The pull requests have been merged into remote-naming. > Channel end notification received, closing channel ... should be logged at debug > -------------------------------------------------------------------------------- > > Key: WFLY-3201 > URL: https://issues.jboss.org/browse/WFLY-3201 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > Remote naming is logging this at ERROR, though it seems normal and no adverse effects are apparent, we should log it at debug instead of error. > ERROR Channel end notification received, closing channel Channel ID b8e969d6 (outbound) of Remoting connection 4970f4db to ... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3673) EAR deployment overlay did not work if there is no related resource included in the ear

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/WFLY-3673?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink updated WFLY-3673: ----------------------------------- Attachment: reproducer.zip > EAR deployment overlay did not work if there is no related resource included in the ear > --------------------------------------------------------------------------------------- > > Key: WFLY-3673 > URL: https://issues.jboss.org/browse/WFLY-3673 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > Attachments: reproducer.zip > > > It is possible to overlay WEB-inf/lib/xy.jar without having xy.jar included in the war file. > If an EAR file is used a module in the lib directory can not be added in the same way. But overlay is working if the lib/xy.jar is available. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-24) JARs Made Invalid By Patch Installation Should Be Renamed to Indicate Their Status

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-24?page=com.atlassian.jira.plugin.... ] Brian Stansberry moved WFLY-3406 to WFCORE-24: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-24 (was: WFLY-3406) Affects Version/s: (was: 8.1.0.CR2) Component/s: Patching (was: Patching) > JARs Made Invalid By Patch Installation Should Be Renamed to Indicate Their Status > ---------------------------------------------------------------------------------- > > Key: WFCORE-24 > URL: https://issues.jboss.org/browse/WFCORE-24 > Project: WildFly Core > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Patching > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3406) JARs Made Invalid By Patch Installation Should Be Renamed to Indicate Their Status

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3406?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3406: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/40 (was: https://github.com/wildfly/wildfly/pull/6325) > JARs Made Invalid By Patch Installation Should Be Renamed to Indicate Their Status > ---------------------------------------------------------------------------------- > > Key: WFLY-3406 > URL: https://issues.jboss.org/browse/WFLY-3406 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Patching > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3673) EAR deployment overlay did not work if there is no related resource included in the ear

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-3673: -------------------------------------- Summary: EAR deployment overlay did not work if there is no related resource included in the ear Key: WFLY-3673 URL: https://issues.jboss.org/browse/WFLY-3673 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Wolf-Dieter Fink Assignee: David Lloyd It is possible to overlay WEB-inf/lib/xy.jar without having xy.jar included in the war file. If an EAR file is used a module in the lib directory can not be added in the same way. But overlay is working if the lib/xy.jar is available. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1199) Guard against ISE in TransactionSynchronizer

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1199: -------------------------------------- Summary: Guard against ISE in TransactionSynchronizer Key: JBJCA-1199 URL: https://issues.jboss.org/browse/JBJCA-1199 Project: IronJacamar Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Affects Versions: 1.2.0.Beta3, 1.1.6.Final, 1.0.26.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Priority: Critical Fix For: 1.0.27.Final, 1.1.7.Final, 1.2.0.Beta4 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3358) Mixed domain testing must use vanilla distributions

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3358?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3358: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6288 (was: https://github.com/wildfly/wildfly/pull/6272) > Mixed domain testing must use vanilla distributions > --------------------------------------------------- > > Key: WFLY-3358 > URL: https://issues.jboss.org/browse/WFLY-3358 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > Priority: Critical > > With a vanilla distribution zip mixed domain testing fails with: > java.lang.IllegalStateException: Could not find /home/jboss/hudson_workspace/jobs/eap6-testsuite/workspace/testsuite/mixed-domain/target/old-versions/jboss-eap-6.2.0 > It must be possible to use vanilla distributions. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3368) Reverse proxy configuration should use outbound-socket-binding

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3368?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-3368: ----------------------------------- @matt Would something like this cover your scenarios: {code:xml} <reverse-proxy name="reverse-proxy" connections-per-thread="30"> <host name="localhost" scheme="ajp" outbound-socket-binding-ref="ajp-remote" instance-id="myRoute"/> </reverse-proxy> {code} and later in config you have {code:xml} <outbound-socket-binding name="ajp-remote"> <remote-destination host="localhost" port="8009"/> </outbound-socket-binding> {code} > Reverse proxy configuration should use outbound-socket-binding > -------------------------------------------------------------- > > Key: WFLY-3368 > URL: https://issues.jboss.org/browse/WFLY-3368 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: Matt Wringe > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > The reverse proxy configuration in standalone.xml requires a string value and will not accept variables like most of the other options. > for example, something like this should be valid, but its currently not: > {code:xml} > <handlers> > <reverse-proxy name="reverse-proxy" connections-per-thread="30"> > <host name="${myURL}" instance-id="myRoute"/> > </reverse-proxy> > <handlers> > {code} > Here you need to specify the name as something like "http://127.5.183.1:8080" -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1863) Excessive dropped messages due to missing physical address

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1863?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1863: -------------------------------- Will test this in 3.6: https://issues.jboss.org/browse/JGRP-1865 > Excessive dropped messages due to missing physical address > ---------------------------------------------------------- > > Key: JGRP-1863 > URL: https://issues.jboss.org/browse/JGRP-1863 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.5 > Reporter: Paul Ferraro > Assignee: Bela Ban > Priority: Blocker > Fix For: 3.5 > > > When running the x-site replication tests (and only those tests - the others run fine) from the clustering testsuite in WildFly against JGroups 3.5, I encounter failures due to: > {noformat} > 12:15:48,537 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site SFO: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from SFO (sync, timeout=10000) > {noformat} > The logs preceding this indicate the cause of the timeout: > {noformat} > 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message > 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message > 12:15:39,506 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message > 12:15:39,507 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message > {noformat} > These messages repeat about 100 or so times over a period of 10 seconds. > A little investigation reveals that the process for fetching physical addresses for a given logical destination address has changed. In 3.4, a given call to sendToSingleMember(...) would attempt to lookup the physical address by sending a Event.GET_PHYSICAL_ADDRESS up the stack and wait a predetermined period for a response. Any concurrent calls to sendToSingleMember(...) would also wait, but only one thread in a given time period would ever send the Event.GET_PHYSICAL_ADDRESS event up the stack. > In 3.5 the process is different. In org.jgroups.protocols.TP, the FIND_MBRS event is used to lookup the phsyical addresses, instead of directly sending up a GET_PHYSICAL_ADDRESS event. However, looking at the implementation of the FIND_MBRS event handling within org.jgroups.protocols.Discovery, I see that this triggers a asynchronous GET_MBRS_REQ message. Since this message is sent asynchronously, this means that the response from the original FIND_MBRS event will most certainly be empty. Thus the thread that initiated the FIND_MBRS will most certainly log the PhysicalAddrMissing warning, as will any concurrent/subsequent calls to sendToSingleMember(...) for the same destination until that asynchronous processing completes. This is a departure from the logic in 3.4, where the thread initiating the physical address lookup would wait for some time for the address cache to be updated. I should think that the PhysicalAddrMissing warnings should stop once the original GET_MBRS_REQ message is handled, but that doesn't seem to be happening (hence the 100 or so sequential warning messages over a period of 10 seconds preceding the timeout log message from infinispan). > Curiously, I see a org.jgroups.protocols.TP.setPingData(...) method, which seems to be responsible for populating the physical address cache from the FIND_MBRS event results from org.jgroups.protocols.Discovery - however, this method doesn't seem to be referenced anywhere. Might that be the source of the problem? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 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 July 2014