January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3274) Cancled recurring timer reactivated after server restart

by Wolf-Dieter Fink (Created) (JIRA)

Cancled recurring timer reactivated after server restart -------------------------------------------------------- Key: AS7-3274 URL: https://issues.jboss.org/browse/AS7-3274 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.0.2.Final Reporter: Wolf-Dieter Fink Assignee: Wolf-Dieter Fink If a timer should be cancled by invoking its cancel() method and this timer is current in timeout (method is processing) the cancelation is not complete successful. The scheduling is stopped imediately but after restarting the server this timer become active again. -- 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, 3 months

3
3
0 / 0

[JBoss JIRA] (AS7-3318) CLONE - ClassNotFoundException during start - org.jboss.as.messaging.jms.TransactionManagerLocator

by Miroslav Novak (JIRA)

Miroslav Novak created AS7-3318: ----------------------------------- Summary: CLONE - ClassNotFoundException during start - org.jboss.as.messaging.jms.TransactionManagerLocator Key: AS7-3318 URL: https://issues.jboss.org/browse/AS7-3318 Project: Application Server 7 Issue Type: Bug Components: JMS Affects Versions: 7.1.0.CR1 Reporter: Miroslav Novak Assignee: Clebert Suconic Fix For: 7.1.0.Final When logging subsystem is set to DEBUG level for "org.hornetq" then ClassNotFoundException exception appears in console log: {code} 12:45:01,163 DEBUG [org.hornetq.ra.Util] (MSC service thread 1-4) org.jboss.as.messaging.jms.TransactionManagerLocator from [Module "org.hornetq.ra:main" from local module loader @6e811c88 (roots: /mnt/shared/test-eap6/server1/jboss-eap-6.0/modules)]: java.lang.ClassNotFoundException: org.jboss.as.messaging.jms.TransactionManagerLocator from [Module "org.hornetq.ra:main" from local module loader @6e811c88 (roots: /mnt/shared/test-eap6/server1/jboss-eap-6.0/modules)] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:473) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:461) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:403) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:125) at org.hornetq.ra.Util.locateTM(Util.java:261) [hornetq-ra-2.2.7.Final.jar:] at org.hornetq.ra.HornetQResourceAdapter.locateTM(HornetQResourceAdapter.java:1555) [hornetq-ra-2.2.7.Final.jar:] at org.hornetq.ra.HornetQResourceAdapter.start(HornetQResourceAdapter.java:210) [hornetq-ra-2.2.7.Final.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_22] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.6.0_22] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.6.0_22] at java.lang.reflect.Method.invoke(Method.java:616) [:1.6.0_22] at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.startContext(AbstractResourceAdapterDeployer.java:345) [ironjacamar-deployers-common-1.0.6.Final-redhat-1.jar:1.0.6.Final] at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2127) [ironjacamar-deployers-common-1.0.6.Final-redhat-1.jar:1.0.6.Final] at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:1030) [ironjacamar-deployers-common-1.0.6.Final-redhat-1.jar:1.0.6.Final] at org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator.doDeploy(ResourceAdapterActivatorService.java:148) [jboss-as-connector-7.1.0.CR1-redhat-1.jar:7.1.0.CR1-redhat-1] at org.jboss.as.connector.services.ResourceAdapterActivatorService.start(ResourceAdapterActivatorService.java:94) [jboss-as-connector-7.1.0.CR1-redhat-1.jar:7.1.0.CR1-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA-redhat-1.jar:1.0.1.GA-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA-redhat-1.jar:1.0.1.GA-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22] at java.lang.Thread.run(Thread.java:679) [:1.6.0_22] {code} -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1037) Ergonomics: size thread pools dynamically

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1037?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1037: --------------------------- Fix Version/s: 3.2 (was: 3.1) > Ergonomics: size thread pools dynamically > ----------------------------------------- > > Key: JGRP-1037 > URL: https://issues.jboss.org/browse/JGRP-1037 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.2 > > > Ergonomics are a step towards less configuration and more dynamic setting of values. Example: a thread pool's min and max sizes can be dynamically changed, based on observations. When we have a min size of 10, but the thread pool is always 75, then we should set the min size to 75 and possibly change the idle time too. > This is just a first step towards ergonomics and needs to be expanded on in 3.x releases -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-1001) Use ByteMan / Metronome to inject faults for testing

by Bela Ban (JIRA)

Use ByteMan / Metronome to inject faults for testing ---------------------------------------------------- Key: JGRP-1001 URL: https://jira.jboss.org/jira/browse/JGRP-1001 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Use ByteMan (jboss.org/byteman) to simulate issues that can happen at runtime: do this in unit tests. For example: crash of merge leader after initial round (who frees the locks ?) (same for FLUSH) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

3
7
0 / 0

[JBoss JIRA] (JGRP-1416) NAKACK / NAKACK2: shorten scope of seqno_lock

by Bela Ban (JIRA)

Bela Ban created JGRP-1416: ------------------------------ Summary: NAKACK / NAKACK2: shorten scope of seqno_lock Key: JGRP-1416 URL: https://issues.jboss.org/browse/JGRP-1416 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.0.3, 3.1 The code in NAKACK/NAKACK2.send() acquires seqno_lock like this: {code:title=NAKACK.send()|borderStyle=solid} seqno_lock.lock(); try { try { // incrementing seqno and adding the msg to sent_msgs needs to be atomic msg_id=seqno +1; msg.putHeader(this.id, NakAckHeader.createMessageHeader(msg_id)); win.add(msg_id, msg); seqno=msg_id; } catch(Throwable t) { throw new RuntimeException("failure adding msg " + msg + " to the retransmit table for " + local_addr, t); } } finally { seqno_lock.unlock(); } {code} This slows concurrent sender threads down if add() takes a while. Method add() can take a while if we have many concurrent adds and removes. The reason we use seqno_lock is to prevent gaps in the sequence numbers, e.g. if we have an exception in add(). SOLUTION: - Assign a new msg_id by incrementing seqno *atomically* (seqno_lock is now de-scoped to only increment seqno, might replace this with an AtomicLong anyway) - In a loop: add the message (calling add()), until add() returns successfully, then break Example: {code} msg_id=seqno.incrementAndGet(); // uses an AtomicLong while(running) { // maybe bound with a counter try { msg.adddHeader(...); add(); break; } catch(Throwable t) { // log } } {code} -- 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, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (AS7-1383) Domain Managent - Ensure current authenticated user is associated with current request / thread and is retrievable.

by Darran Lofthouse (JIRA)

Domain Managent - Ensure current authenticated user is associated with current request / thread and is retrievable. ------------------------------------------------------------------------------------------------------------------- Key: AS7-1383 URL: https://issues.jboss.org/browse/AS7-1383 Project: Application Server 7 Issue Type: Task Components: Domain Management, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.1.0.Beta1 Initially for audit but also for other purposes the current user needs to be identifiable for the request being processed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

3
4
0 / 0

[JBoss JIRA] (AS7-3311) Add option to use Http11Protocol even if Http11AprProtocol can be used

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created AS7-3311: -------------------------------------- Summary: Add option to use Http11Protocol even if Http11AprProtocol can be used Key: AS7-3311 URL: https://issues.jboss.org/browse/AS7-3311 Project: Application Server 7 Issue Type: Feature Request Components: Web Affects Versions: 7.1.0.Beta1b Reporter: Rostislav Svoboda Assignee: Remy Maucherat Fix For: 7.1.0.Final Currently if APR is installed on machine and can be used by AS7 (AprLifecycleListener.isAprInitialized()) Http11AprProtocol is set as protocol handler. Please introduce option to force usage of Http11Protocol instead of Http11AprProtocol. On machines with apr installed we are not able to work with java based implementation. Possible place for code change: - org.apache.catalina.connector.Connector -- setProtocol -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] (AS7-3042) IPv6: Invalid redirect to Admin console (wrong IP address)

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/AS7-3042?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated AS7-3042: ---------------------------------- Fix Version/s: 7.1.0.Final Priority: Major (was: Blocker) I have re-opened to double check what is happening here. However do please not that the redirection is intended as a convenience for a new out of the box installation, it is not intended for redirecting requests received from the public interface so in this scenario it currently sounds more likely that a displayed error is going to be the correct outcome rather than a successful redirect. > IPv6: Invalid redirect to Admin console (wrong IP address) > ---------------------------------------------------------- > > Key: AS7-3042 > URL: https://issues.jboss.org/browse/AS7-3042 > Project: Application Server 7 > Issue Type: Bug > Components: Console, Web > Affects Versions: 7.1.0.Beta1b > Reporter: Pavel Janousek > Assignee: Darran Lofthouse > Fix For: 7.1.0.Final > > > This issue is some derivation from AS7-3040. Lets imagine starting server like this: > {code}./standalone.sh -Djava.net.preferIPv4Stack=false -Djboss.bind.address=::1{code} > So by default the admin/management is bound to _::ffff:127.0.0.1:9990_ and _::ffff:127.0.0.1:9999_, but it isn't accessible from Web WelcomePage at _::1:8080_ because the URL is specified as: {code}<a href="/console">{code} and so the next request is http://[::1]:8080/console which redirect requester to http://[::1]:9990, but there isn't any console because it is here - http://[::ffff:127.0.0.1]:9990. > This is not good as it could lead to integration issues between components (X trying to connect to Y on ::1; Y listening on ::ffff:127.0.0.1). -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-3042) IPv6: Invalid redirect to Admin console (wrong IP address)

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/AS7-3042?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse edited comment on AS7-3042 at 1/16/12 6:07 AM: ---------------------------------------------------------------- I have re-opened to double check what is happening here. However do please note that the redirection is intended as a convenience for a new out of the box installation, it is not intended for redirecting requests received from the public interface so in this scenario it currently sounds more likely that a displayed error is going to be the correct outcome rather than a successful redirect. was (Author: dlofthouse): I have re-opened to double check what is happening here. However do please not that the redirection is intended as a convenience for a new out of the box installation, it is not intended for redirecting requests received from the public interface so in this scenario it currently sounds more likely that a displayed error is going to be the correct outcome rather than a successful redirect. > IPv6: Invalid redirect to Admin console (wrong IP address) > ---------------------------------------------------------- > > Key: AS7-3042 > URL: https://issues.jboss.org/browse/AS7-3042 > Project: Application Server 7 > Issue Type: Bug > Components: Console, Web > Affects Versions: 7.1.0.Beta1b > Reporter: Pavel Janousek > Assignee: Darran Lofthouse > Fix For: 7.1.0.Final > > > This issue is some derivation from AS7-3040. Lets imagine starting server like this: > {code}./standalone.sh -Djava.net.preferIPv4Stack=false -Djboss.bind.address=::1{code} > So by default the admin/management is bound to _::ffff:127.0.0.1:9990_ and _::ffff:127.0.0.1:9999_, but it isn't accessible from Web WelcomePage at _::1:8080_ because the URL is specified as: {code}<a href="/console">{code} and so the next request is http://[::1]:8080/console which redirect requester to http://[::1]:9990, but there isn't any console because it is here - http://[::ffff:127.0.0.1]:9990. > This is not good as it could lead to integration issues between components (X trying to connect to Y on ::1; Y listening on ::ffff:127.0.0.1). -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-3042) IPv6: Invalid redirect to Admin console (wrong IP address)

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/AS7-3042?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reopened AS7-3042: ----------------------------------- > IPv6: Invalid redirect to Admin console (wrong IP address) > ---------------------------------------------------------- > > Key: AS7-3042 > URL: https://issues.jboss.org/browse/AS7-3042 > Project: Application Server 7 > Issue Type: Bug > Components: Console, Web > Affects Versions: 7.1.0.Beta1b > Reporter: Pavel Janousek > Assignee: Darran Lofthouse > Priority: Blocker > > This issue is some derivation from AS7-3040. Lets imagine starting server like this: > {code}./standalone.sh -Djava.net.preferIPv4Stack=false -Djboss.bind.address=::1{code} > So by default the admin/management is bound to _::ffff:127.0.0.1:9990_ and _::ffff:127.0.0.1:9999_, but it isn't accessible from Web WelcomePage at _::1:8080_ because the URL is specified as: {code}<a href="/console">{code} and so the next request is http://[::1]:8080/console which redirect requester to http://[::1]:9990, but there isn't any console because it is here - http://[::ffff:127.0.0.1]:9990. > This is not good as it could lead to integration issues between components (X trying to connect to Y on ::1; Y listening on ::ffff:127.0.0.1). -- 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, 3 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 2012