March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1547) deploy directories not cleaned up

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1547: ----------------------------------------------- James Livingston <jlivings(a)redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from ASSIGNED to POST > deploy directories not cleaned up > --------------------------------- > > Key: WFLY-1547 > URL: https://issues.jboss.org/browse/WFLY-1547 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Alpha1 > Reporter: Shaun Appleton > Assignee: jaikiran pai > Fix For: 8.0.0.Beta1 > > Attachments: deployment_with_hack_no_hook.txt > > > JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories. > The following reproduces this - > i) ensure run.conf has the -Xrs set > ii) ensure deployments has a deployable .ear in it > iii) ./run standalone.sh and allow the deployments to deploy > iv) stop the EAP process ie kill <process_id> > v) observe content tmp/vfs > (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP) > This will eventually cause problems with lack of disk space. > Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems. > It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-457) TaskModelProvider's ServiceLoader sync problem

by Mariano De Maio (JIRA)

[ https://issues.jboss.org/browse/DROOLS-457?page=com.atlassian.jira.plugin... ] Mariano De Maio resolved DROOLS-457. ------------------------------------ Fix Version/s: 6.1.0.Beta2 Resolution: Done Pull request merged into master by Maciej Swiderski > TaskModelProvider's ServiceLoader sync problem > ---------------------------------------------- > > Key: DROOLS-457 > URL: https://issues.jboss.org/browse/DROOLS-457 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1, 6.1.0.Beta2, 6.1.0.Final > Reporter: Mariano De Maio > Assignee: Mark Proctor > Fix For: 6.1.0.Beta2 > > Attachments: test-case.zip > > > This bug was found related to jBPM6 components, but its solution needs to be implemented in the kie-internal project, hence we report it in this project. > When the TaskModelProvider access the factory object, it iterates the service loader directly. Unfortunately, the ServiceLoader class states: > "Instances of this class are not safe for use by multiple concurrent threads." (http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html) > This causes that environments that need to use the TaskModelProvider from different threads with no prior invocation. > I'll add a maven test to reproduce the issue. We have also a solution we'll submit in a pull request -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3108) Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3108: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from ASSIGNED to POST > Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml > -------------------------------------------------------------------------------------------- > > Key: WFLY-3108 > URL: https://issues.jboss.org/browse/WFLY-3108 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.1.Final > > > The prescribed mechanism for converting a slave HC to master is to: > 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml). > 2) Stop the existing master. > 3) Use the cli to connect to the slave and > /host=<slavename>:write-local-domain-controller > 4) Then, in the CLI > reload --host=<slavename> > Problem is this fails because the HC expects to have a domain config file "domain.xml". > 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] > Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory) > at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45] > at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45] > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > ... 3 more > Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-332) Add sessionDrainingStrategy configuration option to modcluster subsystem

by rafael liu (JIRA)

[ https://issues.jboss.org/browse/WFLY-332?page=com.atlassian.jira.plugin.s... ] rafael liu commented on WFLY-332: --------------------------------- Also there's have a more specific use case where the user can set a certain sessionDrainingStrategy value at the moment of the *redeploy*. I think mod_cluster doesn't support this kind o ad-hoc configuration, but IMO that has some real usages: 1. Suppose sessionDrainingStrategy=DEFAULT/ALWAYS, if there's 1 user hanging (say doing a huge download) the redeploy will timeout. Even worst, in a N node scenario, there will be N-1 nodes active during that time. 2. Again with sessionDrainingStrategy=DEFAULT/ALWAYS, if there's a critical bug, draining may not make sense or may introduce an undesirable delay. > Add sessionDrainingStrategy configuration option to modcluster subsystem > ------------------------------------------------------------------------ > > Key: WFLY-332 > URL: https://issues.jboss.org/browse/WFLY-332 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Fix For: 8.0.0.Beta1 > > > Add sessionDrainingStrategy configuration option to modcluster subsystem > * xsd 1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-455) Event expiration calculation may overflow

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-455: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1076361|https://bugzilla.redhat.com/show_bug.cgi?id=1076361] from ASSIGNED to MODIFIED > Event expiration calculation may overflow > ----------------------------------------- > > Key: DROOLS-455 > URL: https://issues.jboss.org/browse/DROOLS-455 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.1.0.Beta2 > > > The calculation of the expiration timestamp of an event in the OTN is effectively given by the combination : > {code} > Handle.startTimeStamp + Handle.duration + OTN.expirationOffset > {code} > If the addition overflows, the event will be scheduled for expiration immediately. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3120) Upgrade JSF based on Mojarra 2.2.6 Final

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-3120?page=com.atlassian.jira.plugin.... ] Farah Juma updated WFLY-3120: ----------------------------- Summary: Upgrade JSF based on Mojarra 2.2.6 Final (was: Upgrade jsf-impl to 2.2.5-jbossorg-4) > Upgrade JSF based on Mojarra 2.2.6 Final > ---------------------------------------- > > Key: WFLY-3120 > URL: https://issues.jboss.org/browse/WFLY-3120 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 8.0.0.Final > Reporter: Farah Juma > Assignee: Farah Juma > > Incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFA... for WildFly 8.0.1.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3120) Upgrade JSF based on Mojarra 2.2.6 Final

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-3120?page=com.atlassian.jira.plugin.... ] Farah Juma updated WFLY-3120: ----------------------------- Description: Upgrade JSF based on Mojarra 2.2.6 Final. Also incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFA... for WildFly 8.0.1.Final. (was: Incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFA... for WildFly 8.0.1.Final.) > Upgrade JSF based on Mojarra 2.2.6 Final > ---------------------------------------- > > Key: WFLY-3120 > URL: https://issues.jboss.org/browse/WFLY-3120 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 8.0.0.Final > Reporter: Farah Juma > Assignee: Farah Juma > > Upgrade JSF based on Mojarra 2.2.6 Final. Also incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFA... for WildFly 8.0.1.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3120) Upgrade jsf-impl to 2.2.5-jbossorg-4

by Farah Juma (JIRA)

Farah Juma created WFLY-3120: -------------------------------- Summary: Upgrade jsf-impl to 2.2.5-jbossorg-4 Key: WFLY-3120 URL: https://issues.jboss.org/browse/WFLY-3120 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: JSF Affects Versions: 8.0.0.Final Reporter: Farah Juma Assignee: Farah Juma Incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFA... for WildFly 8.0.1.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1750) RELAY2 : Address formats are not relayed.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1750?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1750: -------------------------------- Perhaps it would be simpler to create a new interface {{ExtendedAddress}} and an impl {{ExtendedUUID}} which contains the UUID and additional data, e.g. {{site_id}}, {{rack_id}} and {{machine_id}} for {{TopologyUUID}}, or a string for {{PayloadUUID}} etc... The {{AddressGenerator}} would wrap the base address in an {{ExtendedUUID}} and data could then be added to that address, e.g. via puts and gets (conceptual hashmap). This would also allow us to get rid of a number of classes... > RELAY2 : Address formats are not relayed. > ----------------------------------------- > > Key: JGRP-1750 > URL: https://issues.jboss.org/browse/JGRP-1750 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4.1 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Fix For: 3.5 > > > When defining a relay channel, we haven't the ability to set an AddressGenrator. Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID. > This is particularly embarrassing in the following case: when we define a customized address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A and B, address format is lost by crossing relay. Address type of messages sent by A to B are seen as SiteUUID at B side. > Suggestions: > - Making address format "relayable" ? > - Using the same (or an extended format) AddressGenerator of site Channel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1759) BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1759?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1759: -------------------------------- I haven't been able to reproduce such a hang, *not a single time* ! Is this specific to 3.2.x ? > BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks > ---------------------------------------------------------------- > > Key: JGRP-1759 > URL: https://issues.jboss.org/browse/JGRP-1759 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.5 > Environment: Windows 2008, x86_64 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > Running the Byteman tests in the QA lab, this test deadlocks in a repeatable fashion and causes the testsuite to hang. > The test makes use of the Byteman rendezvous built-in function to suspend (and reorder) thread execution. It appears that with threads re-ordered, certain parts of JGroups block in such a way that no progress is made and the test deadlocks. > . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 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 March 2014