[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
11 years, 5 months
[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
11 years, 5 months
[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
11 years, 5 months
[JBoss JIRA] (AS7-6055) Support multiple <entry> elements for <pooled-connection-factory>
by Justin Bertram (JIRA)
Justin Bertram created AS7-6055:
-----------------------------------
Summary: Support multiple <entry> elements for <pooled-connection-factory>
Key: AS7-6055
URL: https://issues.jboss.org/browse/AS7-6055
Project: Application Server 7
Issue Type: Bug
Components: JMS
Affects Versions: 7.1.1.Final
Reporter: Justin Bertram
Assignee: Jeff Mesnil
Currently a <pooled-connection-factory> can only be bound to a single JNDI location because it only supports one <entry> despite the fact that the schema allows multiple <entry> elements.
--
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
11 years, 5 months
[JBoss JIRA] Created: (JBAS-7882) Wrong provider code base for security provider included in packed ear
by Petr H (JIRA)
Wrong provider code base for security provider included in packed ear
---------------------------------------------------------------------
Key: JBAS-7882
URL: https://jira.jboss.org/jira/browse/JBAS-7882
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: VFS
Affects Versions: JBossAS-6.0.0.M2, JBossAS-5.1.0.GA
Environment: Any OS, JDK 5 and 6, JBoss AS 5.1.0 and 6.0.0.M2
Reporter: Petr H
We've got applications which uses the IAIK JCE provider (http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/JCA-JCE) whose library is included directly in our application.
On JBoss AS 5 and later, we can't use this provider as usually.
The new VFS mechanism seems to break the path determination to the IAIK provider library (needed to determine provider code base) - it still points into the ear/war structure inside the server deploy directory but as all this is packed into one ear file, the provider verification.fails because of unsigned ear/war and thus the following exception is thrown:
2010-04-01 15:04:20,890 ERROR [STDERR] (http-0.0.0.0-8180-1) java.lang.SecurityException: JCE cannot authenticate the provider IAIK
2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..)
2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..)
2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at iaik.test.ControllerServlet.service(ControllerServlet.java:123)
2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:905)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:592)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2036)
2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at java.lang.Thread.run(Thread.java:619)
2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) Caused by: java.util.jar.JarException: Cannot parse jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war
2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_c.a(DashoA13*..)
2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.b(DashoA13*..)
2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.a(DashoA13*..)
2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) ... 24 more
This works when one of tho three mentioned workarounds is used.
The most interesting of course is the third workaround for which the code base corectly points to the temporary IAIK library instance in the java.io.tmpdir:
2010-04-01 15:09:51,291 INFO [STDOUT] (http-0.0.0.0-8180-1) Provider code base: file:/tmp/nestedjar2481829661547119990.tmp
I'll attach a simple testcase ear (IAIKTest.ear) which contains an evaluation version of IAIK provider library (thanks for permission to the IAIK authors) and a simple servlet (including source) which demonstrates the problem.
All you need to do is to have the unrestricted JCE policy files installed in your JRE and then just put the IAIKTest.ear into the deploy directory, start the JBoss instance and access the test servlet URL in browser, for example: http://localhost:8080/IAIKTestWeb/ControllerServlet
On init (which happens on start) it will register the IAIK provider
On service (after you access it in browser) it will attempt to get some cipher instance and here it fails.
I'll also attach two log files covering the problem:
- server-default.log with default server setup where the issue occurs
- server-forceVfsJar.log with jboss.vfs.forceVfsJar=true where the issue doesn't occur
Also I think this is more generic problem because we had similar issues, where some jar or resource location was pointing to the packed ear/war structure inside the deploy directory instead of those VFS temporary locations, with our own code (when attemting to obtain full path) and had to perform some modifications in order to make it working. The same set of workarounds could resolve these issues as well.
--
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
11 years, 5 months