[JBoss JIRA] (AS7-6126) Check ModelTypes in jacorb subsystem
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6126:
-------------------------------------
Summary: Check ModelTypes in jacorb subsystem
Key: AS7-6126
URL: https://issues.jboss.org/browse/AS7-6126
Project: Application Server 7
Issue Type: Task
Components: Domain Management, IIOP
Affects Versions: 7.1.3.Final (EAP)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.3.0.Alpha1
There are a number of attributes in the Jacorb subsystem that use ModelType.STRING for things that look like booleans. Check through the attributes and change to ModelType.BOOLEAN where appropriate.
This shouldn't raise a compatibility issue, since ModelType.BOOLEAN is freely convertible to ModelType.STRING, and vice-versa so long as the string represents as boolean (which it would have to do for the attribute to work anyway.) If anything is changed though, a Console subtask should be created to look into any UI implications.
--
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, 7 months
[JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-163?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-163:
---------------------------------------
The generated class file does not contain the stack map table,
which Java 7 requires every class file contains. So this is
basically a bug related to Java7 support.
To fix the bug, BulkAccessorFactor class needs to be updated to
generate the stack map table. Just call rebuildStackMapIf6()
on every MethodInfo object created.
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
> Key: JASSIST-163
> URL: https://issues.jboss.org/browse/JASSIST-163
> Project: Javassist
> Issue Type: Enhancement
> Affects Versions: 3.15.0-GA, 3.16.1-GA
> Environment: hibernate-core 3.6.10.Final
> Reporter: Nikita Tovstoles
> Assignee: Shigeru Chiba
> Fix For: 3.17.0-GA
>
> Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
> synchronized (methods) {
> if (methods[index] == null) {
> methods[index + 1] = thisMethod == null ? null
> : findMethod(self, thisMethod, desc);
> methods[index] = findSuperMethod(self, superMethod, desc);
> }
> }
> {code}
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately
--
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, 7 months
[JBoss JIRA] (AS7-6105) Shutdown process hangs using thread pool executor
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/AS7-6105?page=com.atlassian.jira.plugin.s... ]
Mathieu Lachance commented on AS7-6105:
---------------------------------------
jboss thread subsystem do not expose the daemon flag
> Shutdown process hangs using thread pool executor
> -------------------------------------------------
>
> Key: AS7-6105
> URL: https://issues.jboss.org/browse/AS7-6105
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.1.Final, 7.1.3.Final (EAP)
> Reporter: Eiichi Nagai
> Assignee: Remy Maucherat
>
> When AJP connecotr uses thread pool executor configuration[1], AJP's worker thread is waited by AjpProcessor.read()[2]. QueueExecuter recognizes it as active thread. Therefor, unless httpd server shut down, EAP server shutdown process does not finish forever.
> [1] standalone.xml
> <subsystem xmlns="urn:jboss:domain:threads:1.1">
> <bounded-queue-thread-pool name="http-executor">
> <queue-length count="1"/>
> <max-threads count="1"/>
> </bounded-queue-thread-pool>
> </subsystem>
> --- snip ---
> <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false">
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp" executor="http-executor"/>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> [2]
> "http-executor-threads - 1" prio=6 tid=0x55515000 nid=0x20c0 runnable [0x5590f000]
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:1131)
> at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:1213)
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:451)
> at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:519)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821)
> at java.lang.Thread.run(Thread.java:662)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
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, 7 months
[JBoss JIRA] (AS7-6105) Shutdown process hangs using thread pool executor
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/AS7-6105?page=com.atlassian.jira.plugin.s... ]
Mathieu Lachance edited comment on AS7-6105 at 12/10/12 11:25 AM:
------------------------------------------------------------------
jboss thread subsystem do not expose the daemon flag, I think the issue should be re-opened.
was (Author: matlach):
jboss thread subsystem do not expose the daemon flag
> Shutdown process hangs using thread pool executor
> -------------------------------------------------
>
> Key: AS7-6105
> URL: https://issues.jboss.org/browse/AS7-6105
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.1.Final, 7.1.3.Final (EAP)
> Reporter: Eiichi Nagai
> Assignee: Remy Maucherat
>
> When AJP connecotr uses thread pool executor configuration[1], AJP's worker thread is waited by AjpProcessor.read()[2]. QueueExecuter recognizes it as active thread. Therefor, unless httpd server shut down, EAP server shutdown process does not finish forever.
> [1] standalone.xml
> <subsystem xmlns="urn:jboss:domain:threads:1.1">
> <bounded-queue-thread-pool name="http-executor">
> <queue-length count="1"/>
> <max-threads count="1"/>
> </bounded-queue-thread-pool>
> </subsystem>
> --- snip ---
> <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false">
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp" executor="http-executor"/>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> [2]
> "http-executor-threads - 1" prio=6 tid=0x55515000 nid=0x20c0 runnable [0x5590f000]
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:1131)
> at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:1213)
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:451)
> at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:519)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821)
> at java.lang.Thread.run(Thread.java:662)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
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, 7 months
[JBoss JIRA] (AS7-6125) Upgrade PicketBox to 4.0.15.Final
by Josef Cacek (JIRA)
Josef Cacek created AS7-6125:
--------------------------------
Summary: Upgrade PicketBox to 4.0.15.Final
Key: AS7-6125
URL: https://issues.jboss.org/browse/AS7-6125
Project: Application Server 7
Issue Type: Task
Affects Versions: 7.1.3.Final (EAP)
Reporter: Josef Cacek
Assignee: Stefan Guilhen
A TCK test is failing for AS7 with PicketBox 4.0.14 (it's related to changes in AS7-5114). Please update the PicketBox version.
Remove also the @Ignore in the
testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/jacc/JACCAuthzPropagationTestCase.java
--
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, 7 months
[JBoss JIRA] (AS7-4673) Failure to set "SetBigStringTryClob=true" ConnectionProperties in xa-datasource-property
by John Mazzitelli (JIRA)
[ https://issues.jboss.org/browse/AS7-4673?page=com.atlassian.jira.plugin.s... ]
John Mazzitelli commented on AS7-4673:
--------------------------------------
Just as an aside, as per http://docs.oracle.com/cd/E11882_01/java.112/e16548/oralob.htm#CHDGEIHF
"The SetBigStringTryClob connection property of Oracle Database 10g Release 1 (10.1) is no longer used or needed."
So if you don't support Oracle 9 and below, you can remove this setting.
This still doesn't solve the more general problem of how do you set any XA datasource property that is translated to type Properties, but for this specific issue of SetBigStringTryClob, if you only support Oracle 10g and above, you don't need it (as per the Oracle documentation linked above).
> Failure to set "SetBigStringTryClob=true" ConnectionProperties in xa-datasource-property
> ----------------------------------------------------------------------------------------
>
> Key: AS7-4673
> URL: https://issues.jboss.org/browse/AS7-4673
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.1.Final
> Environment: Red Hat Enterprise Linux Server release 5.7, JDK 7, Oracle 10g
> Reporter: Roger S
> Labels: rhq
>
> I found that when the following is set in the standalone.xml of JBoss-7.1.1.Final, it will have a fatal error:
> <xa-datasource....>
> ....
> <xa-datasource-property name="ConnectionProperties">SetBigStringTryClob=true</xa-datasource-property>
> ....
> </xa-datasource>
> The error is:
>
> Caused by: javax.resource.ResourceException: No property editor found for type: class java.util.Properties
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXADataSource(XAManagedConnectionFactory.java:601)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:430)
>
> When I don't define the SetBigStringTryClob setting, all is fine. However, the SetBigStringTryClob is really important for the application to work correctly. Hope there's at least a workaround.
> This worked without problems in JBoss 4.2.3.
--
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, 7 months
[JBoss JIRA] (JBREM-1317) BisocketClientInvoker waits for failed clients
by Doug Grove (JIRA)
Doug Grove created JBREM-1317:
---------------------------------
Summary: BisocketClientInvoker waits for failed clients
Key: JBREM-1317
URL: https://issues.jboss.org/browse/JBREM-1317
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: callbacks
Affects Versions: 2.5.4.SP3
Environment: JBoss EAP 5.1.2
Reporter: Doug Grove
Assignee: Ron Sigal
Priority: Minor
When a client dies or is killed, the failure is actually detected in org.jboss.remoting.transport.socket.MicroSocketClientInvoker:
(NEW ClientSocketWrapper[Socket[addr=/10.0.0.212,port=36600,localport=4458].d3e837]) got Exception: java.io.IOException: Broken pipe
The "Broken pipe" exception means that the client has disconnected and can not return. This exception is treated in the code a retry-able, however.
This is ignored, however, and the ode carries on, finally calling BisocketClientInvoker.createSocket(). This code then waits for a socket to appear in a list. I can see no way for a new socket to ever appear in the list.
This results in the code waiting for the full duration of the configured timeout.
--
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, 7 months
[JBoss JIRA] (AS7-6104) jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove()
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6104?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6104:
----------------------------------
Assignee: Stefano Maestri (was: Jason Greene)
Component/s: Domain Management
JCA
(was: Server)
> jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove()
> ------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6104
> URL: https://issues.jboss.org/browse/AS7-6104
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 7.1.1.Final
> Environment: Windows 7 Professional SP1
> Reporter: Raymond Naseef
> Assignee: Stefano Maestri
> Labels: jboss-as7, modules, postgresql
>
> NullPointerException during jboss-cli remove with commands:
> jboss-cli --connect command="/subsystem=datasources/jdbc-driver=postgresql-driver:add(driver-name=postgresql-driver, driver-class-name=org.postgresql.Driver, driver-module-name=org.postgresql"
> * this works
> jboss-cli --connect command="/subsystem=datasources/jdbc-driver=postgresql-driver:remove"
> MS-DOS Console:
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: null",
> "rolled-back" => true
> }
> Server Log:
> 23:17:42,627 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 19) JBAS014612: Operation ("remove") failed - address: ([
> ("subsystem" => "datasources"),
> ("jdbc-driver" => "postgresql-driver")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.doRemove(OperationContextImpl.java:298) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.OperationContextImpl.removeService(OperationContextImpl.java:293) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.connector.subsystems.datasources.JdbcDriverRemove.performRuntime(JdbcDriverRemove.java:66)
> at org.jboss.as.controller.AbstractRemoveStepHandler$1.execute(AbstractRemoveStepHandler.java:50) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:466) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:287) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:487) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
--
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, 7 months
[JBoss JIRA] (AS7-4673) Failure to set "SetBigStringTryClob=true" ConnectionProperties in xa-datasource-property
by John Mazzitelli (JIRA)
[ https://issues.jboss.org/browse/AS7-4673?page=com.atlassian.jira.plugin.s... ]
John Mazzitelli commented on AS7-4673:
--------------------------------------
This is from:
http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/deployment.htm...
"Table 5.14. xa-datasource elements", element "xa-datasource-property":
"Specifies a property to assign to the XADataSource implementation class. Each property is identified by the name attribute and the property value is given by the xa-datasource-property element content. The property is mapped onto the XADataSource implementation by looking for a JavaBeans style getter method for the property name. If found, the value of the property is set using the JavaBeans setter with the element text translated to the true property type using the java.beans.PropertyEditor for the type"
So, it appears this ConnectionProperties property is mapped to Properties but there is no JavaBeans PropertyEditor installed for that type "Properties". There is one available in commons-core (org.jboss.util.propertyeditor.PropertiesEditor). I think AS7 needs to register it somehow, or as a workaround some custom extension a user writes needs to do it at startup (via a call to "java.beans.PropertyEditorManager.registerEditor(java.util.Properties.class, org.jboss.util.propertyeditor.PropertiesEditor.class);").
I don't know any other workaround.
> Failure to set "SetBigStringTryClob=true" ConnectionProperties in xa-datasource-property
> ----------------------------------------------------------------------------------------
>
> Key: AS7-4673
> URL: https://issues.jboss.org/browse/AS7-4673
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.1.Final
> Environment: Red Hat Enterprise Linux Server release 5.7, JDK 7, Oracle 10g
> Reporter: Roger S
> Labels: rhq
>
> I found that when the following is set in the standalone.xml of JBoss-7.1.1.Final, it will have a fatal error:
> <xa-datasource....>
> ....
> <xa-datasource-property name="ConnectionProperties">SetBigStringTryClob=true</xa-datasource-property>
> ....
> </xa-datasource>
> The error is:
>
> Caused by: javax.resource.ResourceException: No property editor found for type: class java.util.Properties
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXADataSource(XAManagedConnectionFactory.java:601)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:430)
>
> When I don't define the SetBigStringTryClob setting, all is fine. However, the SetBigStringTryClob is really important for the application to work correctly. Hope there's at least a workaround.
> This worked without problems in JBoss 4.2.3.
--
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, 7 months
