February 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3505) Strange behaviour of bean passivation with definition of max-size attribute at file-passivation-store

by Ondřej Chaloupka (JIRA)

Ondřej Chaloupka created AS7-3505: ------------------------------------- Summary: Strange behaviour of bean passivation with definition of max-size attribute at file-passivation-store Key: AS7-3505 URL: https://issues.jboss.org/browse/AS7-3505 Project: Application Server 7 Issue Type: Bug Components: EJB Reporter: Ondřej Chaloupka Assignee: jaikiran pai Please check my test: https://github.com/ochaloup/jboss-as/blob/JBQA-5483-test-migration-passiv... Bean passivation has strange behavior after definition of max-size for file-passivation-store. The test creates two SFSB. In case that I set max-size = 1 the passivation was not provided despite it should be because of size of store. In case that I set max-size = 2 (or 3) the test freezes. There is no exception but it ends with timeout and no action is provided (the debug log level says: "[com.arjuna.ats.arjuna] (Periodic Recovery) Periodic recovery second pass at Mon, 30 Jan 2012 17:11:29" and continues with messages in similar way) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] (AS7-2870) Get rid of subsystem element attributes in jpa 1.1 xsd

by Kabir Khan (Created) (JIRA)

Get rid of subsystem element attributes in jpa 1.1 xsd ------------------------------------------------------ Key: AS7-2870 URL: https://issues.jboss.org/browse/AS7-2870 Project: Application Server 7 Issue Type: Feature Request Components: JPA / Hibernate Reporter: Kabir Khan Assignee: Scott Marlow Fix For: 7.1.0.CR1 http://lists.jboss.org/pipermail/jboss-as7-dev/2011-November/004759.html If the schema has already been released in 7.0.x a schema version bump is needed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
1
0 / 0

[JBoss JIRA] (AS7-2872) Get rid of subsystem element attributes in web 1.1 xsd

by Kabir Khan (Created) (JIRA)

Get rid of subsystem element attributes in web 1.1 xsd ------------------------------------------------------ Key: AS7-2872 URL: https://issues.jboss.org/browse/AS7-2872 Project: Application Server 7 Issue Type: Feature Request Components: Web Reporter: Kabir Khan Assignee: Remy Maucherat Fix For: 7.1.0.CR1 http://lists.jboss.org/pipermail/jboss-as7-dev/2011-November/004759.html If the schema has already been released in 7.0.x a schema version bump is needed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

4
4
0 / 0

[JBoss JIRA] (AS7-3662) Allow the default configuration file names to be external set

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-3662: ------------------------------------- Summary: Allow the default configuration file names to be external set Key: AS7-3662 URL: https://issues.jboss.org/browse/AS7-3662 Project: Application Server 7 Issue Type: Feature Request Components: Server Reporter: Brian Stansberry Assignee: Brian Stansberry The default config versions used if -c, --server-config, --domain-config, --host-config are not provided are currently hardcoded. Instead make them configurable via a system property (set in domain.conf and standalone.conf), with the hardcoded defaults a fallback if the system properties are not set. Benefit of this is a user who always wants, for example, to use standalone-ha.xml doesn't have to repeatedly type ./standalone.sh -c standalone-ha.xml. They can just edit standalone.conf and thereafter simply use ./standalone.sh -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
1
0 / 0

[JBoss JIRA] (AS7-2869) Get rid of subsystem element attributes in jgroups 1.1 xsd

by Kabir Khan (Created) (JIRA)

Get rid of subsystem element attributes in jgroups 1.1 xsd ---------------------------------------------------------- Key: AS7-2869 URL: https://issues.jboss.org/browse/AS7-2869 Project: Application Server 7 Issue Type: Feature Request Components: Clustering Reporter: Kabir Khan Assignee: Paul Ferraro Fix For: 7.1.0.CR1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
4
0 / 0

[JBoss JIRA] (AS7-3456) Synchronize default values provided by Infinispan xsd and Management AttributeDefinitions

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created AS7-3456: ---------------------------------------- Summary: Synchronize default values provided by Infinispan xsd and Management AttributeDefinitions Key: AS7-3456 URL: https://issues.jboss.org/browse/AS7-3456 Project: Application Server 7 Issue Type: Task Components: Domain Management Affects Versions: 7.1.0.CR1b Reporter: Richard Achmatowicz Assignee: Richard Achmatowicz Fix For: 7.1.0.Final Need to make sure that the default values for Infinispan cache configuration elements and attributes are correctly picked up, whether from XML (via definition in the xsd) or from the management interface, programmatically or via the command line (via CommonAttribute definitions). The main tasks here are to: - correctly define the default values for all common attributes used - make sure that any resource handlers make use of the appropriate AttributeDefinition methods which use the attribute definition to correctly pick up default values for parameters which have not had values specified: attr.validateOperation(operation) // validate the value of the attribute in the operation and return it attr.validateAndSet(operation, model) // as above and set the value in the model attr.validateResolvedOperation(operation) // validate the resolved value for the EXPRESSION type -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
2
0 / 0

[JBoss JIRA] (AS7-3637) cache-container start attribute needs "allowed" in resource description

by Stan Silvert (JIRA)

Stan Silvert created AS7-3637: --------------------------------- Summary: cache-container start attribute needs "allowed" in resource description Key: AS7-3637 URL: https://issues.jboss.org/browse/AS7-3637 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.0.CR1b Reporter: Stan Silvert Assignee: Richard Achmatowicz cache-container "start" attribute should specify "EAGER" and "LAZY" as the only allowed values. Specifying allowed values will have the added advantage of letting the CLI GUI know that it should display a drop-down instead of a plain text input box. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] (AS7-3587) Create a AttributeDefinition validator for validating JGroups protocol types

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created AS7-3587: ---------------------------------------- Summary: Create a AttributeDefinition validator for validating JGroups protocol types Key: AS7-3587 URL: https://issues.jboss.org/browse/AS7-3587 Project: Application Server 7 Issue Type: Feature Request Reporter: Richard Achmatowicz Assignee: Richard Achmatowicz The management operation /subsystem=jgroups/stack=udp:add-protocol(type=X, socket-binding=Y, properties={Z}) should have a validator for the JGroups protocol type which will allow the CLI user to see the current list of possible JGroups protocols to include in a stack. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
4
0 / 0

[JBoss JIRA] (AS7-3607) IPv6: Incorrect address binding - web subsystem

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ] Jason Greene updated AS7-3607: ------------------------------ Fix Version/s: 7.1.1.Final (was: 7.1.0.Final) > IPv6: Incorrect address binding - web subsystem > ----------------------------------------------- > > Key: AS7-3607 > URL: https://issues.jboss.org/browse/AS7-3607 > Project: Application Server 7 > Issue Type: Bug > Components: Web > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Assignee: Remy Maucherat > Priority: Critical > Labels: eap6_prd_req > Fix For: 7.1.1.Final > > > There is another example of incorrect address binding in IPv6 environment. > Steps how to reproduce: > 1. Download, unpack DR12 build somewhere > 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf > 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1") > 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1") > 4. Verify if you really have configured wanted eth. interface only aka: > {code} > [root@fedora15-vrt1 Documents]# ifconfig > p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01 > inet6 addr: 1:0:0:1::10/128 Scope:Global > inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:766 (766.0 b) > [root@fedora15-vrt1 Documents]# > {code} > 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)" > 6. Check addresses binding via "netstat -lnp|grep java" > The result it this scenario should be something like mine: > {code} > [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java > tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java > [root@fedora15-vrt1 jboss-as]# > {code} > As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1. > The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-3607) IPv6: Incorrect address binding - web subsystem

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on AS7-3607: ----------------------------------- Pure conjecture says that this is associated with use of the native connector, which uses apr to bind the socket. We are going to turn this off in 7.1.0.Final. > IPv6: Incorrect address binding - web subsystem > ----------------------------------------------- > > Key: AS7-3607 > URL: https://issues.jboss.org/browse/AS7-3607 > Project: Application Server 7 > Issue Type: Bug > Components: Web > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Assignee: Remy Maucherat > Priority: Critical > Labels: eap6_prd_req > Fix For: 7.1.1.Final > > > There is another example of incorrect address binding in IPv6 environment. > Steps how to reproduce: > 1. Download, unpack DR12 build somewhere > 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf > 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1") > 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1") > 4. Verify if you really have configured wanted eth. interface only aka: > {code} > [root@fedora15-vrt1 Documents]# ifconfig > p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01 > inet6 addr: 1:0:0:1::10/128 Scope:Global > inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:766 (766.0 b) > [root@fedora15-vrt1 Documents]# > {code} > 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)" > 6. Check addresses binding via "netstat -lnp|grep java" > The result it this scenario should be something like mine: > {code} > [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java > tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java > tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java > [root@fedora15-vrt1 jboss-as]# > {code} > As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1. > The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 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 February 2012