December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6066) Upgrade Infinispan to 5.2.0.Beta5

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-6066: ----------------------------------- Summary: Upgrade Infinispan to 5.2.0.Beta5 Key: AS7-6066 URL: https://issues.jboss.org/browse/AS7-6066 Project: Application Server 7 Issue Type: Feature Request Components: Clustering Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 7.2.0.Alpha1 http://infinispan.blogspot.it/2012/12/infinispan-520beta5.html -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-5449) when defining custom executor for connector thread priority is not optional

by Mathieu Lachance (JIRA)

Mathieu Lachance created AS7-5449: ------------------------------------- Summary: when defining custom executor for connector thread priority is not optional Key: AS7-5449 URL: https://issues.jboss.org/browse/AS7-5449 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.2.Final (EAP) Reporter: Mathieu Lachance when defining a custom executor in the threads subsystem for the connector defined in the web subsystem like : {code:xml} <subsystem xmlns="urn:jboss:domain:threads:1.1"> <thread-factory name="ConnectorThreadFactory" group-name="ConnectorThreadPool"/> <unbounded-queue-thread-pool name="ConnectorThreadPool"> <max-threads count="500"/> <keepalive-time time="60" unit="seconds"/> <thread-factory name="ConnectorThreadFactory"/> </unbounded-queue-thread-pool> </subsystem> <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false"> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp" redirect-port="8443" executor="ConnectorThreadPool"/> </subsystem> {code} it will fail with : {quote} 17:19:06,508 ERROR [org.apache.tomcat.util.net.JIoEndpoint] (http-/0.0.0.0:8443-Acceptor-0) Error allocating socket processor: java.lang.IllegalArgumentException at java.lang.Thread.setPriority(Thread.java:1058) [rt.jar:1.6.0_31] at org.jboss.threads.JBossThreadFactory.createThread(JBossThreadFactory.java:127) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] at org.jboss.threads.JBossThreadFactory.newThread(JBossThreadFactory.java:101) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] at java.util.concurrent.ThreadPoolExecutor.addThread(ThreadPoolExecutor.java:672) [rt.jar:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:697) [rt.jar:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652) [rt.jar:1.6.0_31] at org.jboss.threads.JBossThreadPoolExecutor.execute(JBossThreadPoolExecutor.java:63) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] at org.jboss.threads.DelegatingBlockingExecutorService.execute(DelegatingBlockingExecutorService.java:42) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] at org.jboss.as.threads.ManagedExecutorService.execute(ManagedExecutorService.java:64) [jboss-as-threads-7.1.2.Final.jar:7.1.2.Final] at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:1237) [jbossweb-7.0.16.Final.jar:] at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:325) [jbossweb-7.0.16.Final.jar:] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31] {quote} even though if documentation state that thread priority is optional : {code:xml} <xs:complexType name="thread-factory"> <xs:annotation> <xs:documentation> <![CDATA[ A thread factory (implementing java.util.concurrent.ThreadFactory). The "name" attribute is the bean name of the created thread factory. The optional "priority" attribute may be used to specify the thread priority of created threads. The optional "group-name" attribute specifies the name of a the thread group to create for this thread factory. The "thread-name-pattern" is the template used to create names for threads. The following patterns may be used: %% - emit a percent sign %t - emit the per-factory thread sequence number %g - emit the global thread sequence number %f - emit the factory sequence number %i - emit the thread ID %G - emit the thread group name ]]> </xs:documentation> </xs:annotation> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="group-name" type="xs:string" use="optional"/> <xs:attribute name="thread-name-pattern" type="xs:string" use="optional"/> <xs:attribute name="priority" type="priority" use="optional"/> </xs:complexType> {code} -- 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

3
9
0 / 0

[JBoss JIRA] (AS7-6064) Datasource pool parameters cannot be edited in the admin console without disabling the datasource first

by Tom Fonteyne (JIRA)

Tom Fonteyne created AS7-6064: --------------------------------- Summary: Datasource pool parameters cannot be edited in the admin console without disabling the datasource first Key: AS7-6064 URL: https://issues.jboss.org/browse/AS7-6064 Project: Application Server 7 Issue Type: Bug Components: Console Affects Versions: 7.1.2.Final (EAP) Reporter: Tom Fonteyne Assignee: Heiko Braun Priority: Minor Datasource pool parameters cannot be edited in the admin console without disabling the datasource first -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6065) CLONE - Datasource pool parameters cannot be edited in the admin console without disabling the datasource first

by Tom Fonteyne (JIRA)

Tom Fonteyne created AS7-6065: --------------------------------- Summary: CLONE - Datasource pool parameters cannot be edited in the admin console without disabling the datasource first Key: AS7-6065 URL: https://issues.jboss.org/browse/AS7-6065 Project: Application Server 7 Issue Type: Bug Components: Console Affects Versions: 7.1.2.Final (EAP) Reporter: Tom Fonteyne Assignee: Heiko Braun Priority: Minor Datasource pool parameters cannot be edited in the admin console without disabling the datasource first -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6057) Error message when adding a messaging's grouping-handler

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-6057: -------------------------------- Summary: Error message when adding a messaging's grouping-handler Key: AS7-6057 URL: https://issues.jboss.org/browse/AS7-6057 Project: Application Server 7 Issue Type: Feature Request Reporter: Jeff Mesnil Fix For: 7.2.0.Alpha1 When a grouping-handler is added to the hornetq-server section, the AS7 server starts with an error: 15:18:14,521 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 52) JBAS014613: Operation ("add") failed - address: ([ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("grouping-handler" => "group-handler-test") ]) - failure description: "JBAS011637: A child resource of type grouping-handler already exists; the messaging subsystem only allows a single resource of type grouping-handler" The error is misleading as there is only 1 grouping-handler and the server runs fine. -- 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

1
1
0 / 0

[JBoss JIRA] (JASSIST-182) update ClassFileWriter for Java 7 invokedynamic

by Shigeru Chiba (JIRA)

Shigeru Chiba created JASSIST-182: ------------------------------------- Summary: update ClassFileWriter for Java 7 invokedynamic Key: JASSIST-182 URL: https://issues.jboss.org/browse/JASSIST-182 Project: Javassist Issue Type: Feature Request Affects Versions: 3.17.0-GA Reporter: Shigeru Chiba Assignee: Shigeru Chiba Priority: Minor (Originally reported by Grigori Goronzy) With Javassist 3.17, the ClassFile, ConstPool, etc. classes gained support for the invokedynamic JVM opcode and associated constant pool data. However, ClassFileWriter wasn't updated, and it isn't possible, for instance, to add an InvokeDynamic_info with a ConstPoolWriter. The attached patch fixes this in the most straight-forward manner. I haven't tested it well, but the code is so simple that it is unlikely to have any bugs. -- 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

1
2
0 / 0

[JBoss JIRA] (JASSIST-180) Javassist fails to load class from jar (com.tivoli.pd.jutil.PDPermResource_cs )

by ami tabak (JIRA)

ami tabak created JASSIST-180: --------------------------------- Summary: Javassist fails to load class from jar (com.tivoli.pd.jutil.PDPermResource_cs ) Key: JASSIST-180 URL: https://issues.jboss.org/browse/JASSIST-180 Project: Javassist Issue Type: Bug Affects Versions: 3.17.0-GA Reporter: ami tabak Assignee: Shigeru Chiba Trying to load class com.tivoli.mts.util.PDPermResource_cs which has only java dependencies. (based on JAD) Getting the following error at instantiation. 1. Not sure if its related to the 3.17.0 or just 3.17.1 code drops. 2. Not sure why its looking to the second class com.tivoli.pd.jutil.PDPermResource_cs rather than to what I'm trying to load. java.lang.InstantiationException: javassist.CtClassType at java.lang.Class.newInstance0(Class.java:357) at java.lang.Class.newInstance(Class.java:325) at com.optier.bug.report.WASTest.wasTestCase(WASTest.java:42) at com.optier.bug.report.WASTest.main(WASTest.java:18) Exception in thread "main" java.lang.RuntimeException: cannot find com.tivoli.mts.util.PDPermResource_cs: com.tivoli.pd.jutil.PDPermResource_cs found in com/tivoli/mts/util/PDPermResource_cs.class at javassist.CtClassType.getClassFile2(CtClassType.java:194) at javassist.CtClassType.makeFieldCache(CtClassType.java:848) at javassist.CtClassType.getMembers(CtClassType.java:839) at javassist.CtClassType.getDeclaredBehaviors(CtClassType.java:987) at com.optier.bug.report.WASTest.wasTestCase(WASTest.java:50) at com.optier.bug.report.WASTest.main(WASTest.java:18) -- 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

2
5
0 / 0

[JBoss JIRA] (AS7-6063) Deadlock in Module FallbackClassLoader

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-6063?page=com.atlassian.jira.plugin.s... ] Thomas Diesler edited comment on AS7-6063 at 12/3/12 3:50 AM: -------------------------------------------------------------- Does this issue still exist in the latest [jboss-as/master|https://github.com/jbossas/jboss-as] build? was (Author: thomas.diesler): Does this issue still exist in the latest [jboss-as/master](https://github.com/jbossas/jboss-as) build? > Deadlock in Module FallbackClassLoader > -------------------------------------- > > Key: AS7-6063 > URL: https://issues.jboss.org/browse/AS7-6063 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Reporter: Steve Reed > Assignee: Thomas Diesler > Attachments: jboss-dead-lock.txt > > > Actually the version is 2.0.1.final - jbosgi-framework-core-2.0.1.Final.jar > Commit reference for JBOSS AS :- https://github.com/jbossas/jboss-as/commit/ed2bc551a55ec6a8167a8657cbb5d8... > During start up of JBOSS AS7.0 two GeminiBlueprintExtender Threads deadlock, and services in the JBOSS OSGI container are not started. > The deadlock appears to be concerned with a Module FallbackLoader, which acquires a lock during a call to loadClassLocal() and then proceeds to use an alternate Module to load the class, if this results in the alternate Module using it's FallbackLoader to load a class or resource, then it must also acquire a lock first. Obviously if two or more threads are attempting this, then a dead lock is possible. > I will attach the thread dump to this issue as supporting evidence. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6063) Deadlock in Module FallbackClassLoader

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-6063?page=com.atlassian.jira.plugin.s... ] Thomas Diesler commented on AS7-6063: ------------------------------------- Does this issue still exist in the latest [jboss-as/master](https://github.com/jbossas/jboss-as) build? > Deadlock in Module FallbackClassLoader > -------------------------------------- > > Key: AS7-6063 > URL: https://issues.jboss.org/browse/AS7-6063 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Reporter: Steve Reed > Assignee: Thomas Diesler > Attachments: jboss-dead-lock.txt > > > Actually the version is 2.0.1.final - jbosgi-framework-core-2.0.1.Final.jar > Commit reference for JBOSS AS :- https://github.com/jbossas/jboss-as/commit/ed2bc551a55ec6a8167a8657cbb5d8... > During start up of JBOSS AS7.0 two GeminiBlueprintExtender Threads deadlock, and services in the JBOSS OSGI container are not started. > The deadlock appears to be concerned with a Module FallbackLoader, which acquires a lock during a call to loadClassLocal() and then proceeds to use an alternate Module to load the class, if this results in the alternate Module using it's FallbackLoader to load a class or resource, then it must also acquire a lock first. Obviously if two or more threads are attempting this, then a dead lock is possible. > I will attach the thread dump to this issue as supporting evidence. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6063) Deadlock in Module FallbackClassLoader

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-6063?page=com.atlassian.jira.plugin.s... ] Thomas Diesler moved JBOSGI-622 to AS7-6063: -------------------------------------------- Project: Application Server 7 (was: JBoss OSGi) Key: AS7-6063 (was: JBOSGI-622) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: (was: JBossOSGi 2.0.0) Component/s: OSGi (was: Blueprint) Security: (was: Public) > Deadlock in Module FallbackClassLoader > -------------------------------------- > > Key: AS7-6063 > URL: https://issues.jboss.org/browse/AS7-6063 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Reporter: Steve Reed > Assignee: Thomas Diesler > Attachments: jboss-dead-lock.txt > > > Actually the version is 2.0.1.final - jbosgi-framework-core-2.0.1.Final.jar > Commit reference for JBOSS AS :- https://github.com/jbossas/jboss-as/commit/ed2bc551a55ec6a8167a8657cbb5d8... > During start up of JBOSS AS7.0 two GeminiBlueprintExtender Threads deadlock, and services in the JBOSS OSGI container are not started. > The deadlock appears to be concerned with a Module FallbackLoader, which acquires a lock during a call to loadClassLocal() and then proceeds to use an alternate Module to load the class, if this results in the alternate Module using it's FallbackLoader to load a class or resource, then it must also acquire a lock first. Obviously if two or more threads are attempting this, then a dead lock is possible. > I will attach the thread dump to this issue as supporting evidence. -- 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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2012