January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6031) deploy directories not cleaned up

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ] Bartosz Baranowski commented on AS7-6031: ----------------------------------------- Hmm seems like PR fails for some reason. > deploy directories not cleaned up > --------------------------------- > > Key: AS7-6031 > URL: https://issues.jboss.org/browse/AS7-6031 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.1.3.Final (EAP) > Reporter: Shaun Appleton > Assignee: Bartosz Baranowski > Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) > > 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6329) Implement 'list-in-use-connections' on JCA CachedConnectionManager and make it available runtime through MBean

by Aleš Bregar (JIRA)

[ https://issues.jboss.org/browse/AS7-6329?page=com.atlassian.jira.plugin.s... ] Aleš Bregar updated AS7-6329: ----------------------------- Attachment: patches.zip > Implement 'list-in-use-connections' on JCA CachedConnectionManager and make it available runtime through MBean > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-6329 > URL: https://issues.jboss.org/browse/AS7-6329 > Project: Application Server 7 > Issue Type: Feature Request > Components: JCA > Reporter: Aleš Bregar > Assignee: Jesper Pedersen > Priority: Trivial > Labels: jca > Attachments: patch1.txt, patch2.txt, patches.zip > > > The missing functionality was present in previous version(s) of AS. As it comes handy sometimes I would like to see this included also in as7. > Possible solution is attached in two patches: > - patch1 for IronJacamar (based on 1.0.14.Final) > - patch2 for as7 jca connector -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6329) Implement 'list-in-use-connections' on JCA CachedConnectionManager and make it available runtime through MBean

by Aleš Bregar (JIRA)

[ https://issues.jboss.org/browse/AS7-6329?page=com.atlassian.jira.plugin.s... ] Aleš Bregar updated AS7-6329: ----------------------------- Attachment: patch1.txt > Implement 'list-in-use-connections' on JCA CachedConnectionManager and make it available runtime through MBean > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-6329 > URL: https://issues.jboss.org/browse/AS7-6329 > Project: Application Server 7 > Issue Type: Feature Request > Components: JCA > Reporter: Aleš Bregar > Assignee: Jesper Pedersen > Priority: Trivial > Labels: jca > Attachments: patch1.txt, patch2.txt > > > The missing functionality was present in previous version(s) of AS. As it comes handy sometimes I would like to see this included also in as7. > Possible solution is attached in two patches: > - patch1 for IronJacamar (based on 1.0.14.Final) > - patch2 for as7 jca connector -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6329) Implement 'list-in-use-connections' on JCA CachedConnectionManager and make it available runtime through MBean

by Aleš Bregar (JIRA)

[ https://issues.jboss.org/browse/AS7-6329?page=com.atlassian.jira.plugin.s... ] Aleš Bregar updated AS7-6329: ----------------------------- Attachment: patch2.txt > Implement 'list-in-use-connections' on JCA CachedConnectionManager and make it available runtime through MBean > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-6329 > URL: https://issues.jboss.org/browse/AS7-6329 > Project: Application Server 7 > Issue Type: Feature Request > Components: JCA > Reporter: Aleš Bregar > Assignee: Jesper Pedersen > Priority: Trivial > Labels: jca > Attachments: patch1.txt, patch2.txt > > > The missing functionality was present in previous version(s) of AS. As it comes handy sometimes I would like to see this included also in as7. > Possible solution is attached in two patches: > - patch1 for IronJacamar (based on 1.0.14.Final) > - patch2 for as7 jca connector -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6329) Implement 'list-in-use-connections' on JCA CachedConnectionManager and make it available runtime through MBean

by Aleš Bregar (JIRA)

Aleš Bregar created AS7-6329: -------------------------------- Summary: Implement 'list-in-use-connections' on JCA CachedConnectionManager and make it available runtime through MBean Key: AS7-6329 URL: https://issues.jboss.org/browse/AS7-6329 Project: Application Server 7 Issue Type: Feature Request Components: JCA Reporter: Aleš Bregar Assignee: Jesper Pedersen Priority: Trivial The missing functionality was present in previous version(s) of AS. As it comes handy sometimes I would like to see this included also in as7. Possible solution is attached in two patches: - patch1 for IronJacamar (based on 1.0.14.Final) - patch2 for as7 jca connector -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6328) SingletonService fails with NullPointerException when bound to 0.0.0.0

by Patrik Varga (JIRA)

[ https://issues.jboss.org/browse/AS7-6328?page=com.atlassian.jira.plugin.s... ] Patrik Varga updated AS7-6328: ------------------------------ Issue Type: Bug (was: Feature Request) > SingletonService fails with NullPointerException when bound to 0.0.0.0 > ----------------------------------------------------------------------- > > Key: AS7-6328 > URL: https://issues.jboss.org/browse/AS7-6328 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.1.2.Final (EAP) > Environment: OS independent, reproduces on Ubuntu 12.10 and Windows XP. > Reporter: Patrik Varga > Assignee: Paul Ferraro > Priority: Critical > > Assume that you have working deployment with a custom MSC service wrapped into a SingletonService. When you are trying to access the value of the SingletonService, the SingletonService.getValue() call fails with NullPointerException iff the JBoss instance is listening on all interfaces, i.e. it is bound to 0.0.0.0 by using <inet-address value="0.0.0.0"/> or <any-address/> under <interface name="public"> in standalone-full-ha.xml. > It works when specifying an explicit IP. > Example: try the cluster-ha-singleton jboss-as-quickstart > Top of the stack trace: > java.lang.NullPointerException > at org.jboss.as.clustering.singleton.SingletonService.getValue(SingletonService.java:176) > at org.jboss.as.clustering.singleton.SingletonService.getValue(SingletonService.java:53) > at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1203) > [...] -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6328) SingletonService fails with NullPointerException when bound to 0.0.0.0

by Patrik Varga (JIRA)

Patrik Varga created AS7-6328: --------------------------------- Summary: SingletonService fails with NullPointerException when bound to 0.0.0.0 Key: AS7-6328 URL: https://issues.jboss.org/browse/AS7-6328 Project: Application Server 7 Issue Type: Feature Request Components: Clustering Affects Versions: 7.1.2.Final (EAP) Environment: OS independent, reproduces on Ubuntu 12.10 and Windows XP. Reporter: Patrik Varga Assignee: Paul Ferraro Priority: Critical Assume that you have working deployment with a custom MSC service wrapped into a SingletonService. When you are trying to access the value of the SingletonService, the SingletonService.getValue() call fails with NullPointerException iff the JBoss instance is listening on all interfaces, i.e. it is bound to 0.0.0.0 by using <inet-address value="0.0.0.0"/> or <any-address/> under <interface name="public"> in standalone-full-ha.xml. It works when specifying an explicit IP. Example: try the cluster-ha-singleton jboss-as-quickstart Top of the stack trace: java.lang.NullPointerException at org.jboss.as.clustering.singleton.SingletonService.getValue(SingletonService.java:176) at org.jboss.as.clustering.singleton.SingletonService.getValue(SingletonService.java:53) at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1203) [...] -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1549) TCP: handle concurrent connections more gracefully

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1549?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1549 at 1/12/13 6:18 AM: --------------------------------------------------------- If a connection exists, but is currently closed, we'll retry *once* to get the connection again. This could be the creation of a new connection, or grabbing an existing connection which was added in the meantime by accept(). This works as connections to non-existing destinations will throw an exception and therefore the code path is different. In other words, we don't run this code when the dest doesn't exist (quite a frequent case, e.g. TCPPING listing non existing destinations). Also, when closing a connection we make sure that we close *our* connection only, to avoid closing a new connection created and added to the connections after our connection was closed. The tetsts are testConcurrentConnect{2} in https://github.com/belaban/JGroups/blob/master/tests/byteman/org/jgroups/... was (Author: belaban): If a connection exists, but is currently closed, we'll retry *once* to get the connection again. This could be the creation of a new connection, or grabbing an existing connection which was added in the meantime by accept(). This works as connections to non-existing destinations will throw an exception and therefore the code path is different. In other words, we don't run this code when the dest doesn't exist (quite a frequent case, e.g. TCPPING listing non existing destinations). Also, when closing a connection we make sure that we close *our* connection only, to avoid closing a new connection created and added to the connections after our connection was closed. > TCP: handle concurrent connections more gracefully > -------------------------------------------------- > > Key: JGRP-1549 > URL: https://issues.jboss.org/browse/JGRP-1549 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > Attachments: cft.log.gz > > > When A connects to B and B connects to A *concurrently*, and no existing connections are present, then one member (with the higher address) will prevail, and the other one will close its connection and drop the message. > This is not usually an issue, as higher-up layers will retransmit the message, thus re-establishing the connection. > However, if we have a protocol based on negative acks, such as UNICAST2, the retransmission might take a while if that message was the last one. > SOLUTION: > The end that closes the connection should simply resend the message *once*, thus re-creating the connection. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1549) TCP: handle concurrent connections more gracefully

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1549?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1549. ---------------------------- Resolution: Done > TCP: handle concurrent connections more gracefully > -------------------------------------------------- > > Key: JGRP-1549 > URL: https://issues.jboss.org/browse/JGRP-1549 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > Attachments: cft.log.gz > > > When A connects to B and B connects to A *concurrently*, and no existing connections are present, then one member (with the higher address) will prevail, and the other one will close its connection and drop the message. > This is not usually an issue, as higher-up layers will retransmit the message, thus re-establishing the connection. > However, if we have a protocol based on negative acks, such as UNICAST2, the retransmission might take a while if that message was the last one. > SOLUTION: > The end that closes the connection should simply resend the message *once*, thus re-creating the connection. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1549) TCP: handle concurrent connections more gracefully

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1549?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1549: -------------------------------- If a connection exists, but is currently closed, we'll retry *once* to get the connection again. This could be the creation of a new connection, or grabbing an existing connection which was added in the meantime by accept(). This works as connections to non-existing destinations will throw an exception and therefore the code path is different. In other words, we don't run this code when the dest doesn't exist (quite a frequent case, e.g. TCPPING listing non existing destinations). Also, when closing a connection we make sure that we close *our* connection only, to avoid closing a new connection created and added to the connections after our connection was closed. > TCP: handle concurrent connections more gracefully > -------------------------------------------------- > > Key: JGRP-1549 > URL: https://issues.jboss.org/browse/JGRP-1549 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > Attachments: cft.log.gz > > > When A connects to B and B connects to A *concurrently*, and no existing connections are present, then one member (with the higher address) will prevail, and the other one will close its connection and drop the message. > This is not usually an issue, as higher-up layers will retransmit the message, thus re-establishing the connection. > However, if we have a protocol based on negative acks, such as UNICAST2, the retransmission might take a while if that message was the last one. > SOLUTION: > The end that closes the connection should simply resend the message *once*, thus re-creating the connection. -- 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

13 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 January 2013