[JBoss JIRA] (AS7-5663) CLONE - System properties are currently unusable for setting a connector's proxy-name
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5663?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5663:
----------------------------------
Parent: AS7-6120
Issue Type: Sub-task (was: Enhancement)
> CLONE - System properties are currently unusable for setting a connector's proxy-name
> -------------------------------------------------------------------------------------
>
> Key: AS7-5663
> URL: https://issues.jboss.org/browse/AS7-5663
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Domain Management, Web
> Affects Versions: 7.1.1.Final
> Environment: -JBoss Enterprise Application Platform (EAP) 6.0.0
> Reporter: Aaron Ogburn
> Assignee: Emanuel Muckenhuber
> Fix For: 7.2.0.CR1
>
>
> A connector's proxy-name cannot be set through system properties currently in the web subsystem:
> ==domain.xml==
> <subsystem xmlns="urn:jbossomain:web:1.1" default-virtual-server="default-host" instance-id="${jboss.node.name}"
> native="false">
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" proxy-name="${jboss.proxy.name}"/>
> The property is never parsed though and
> request.getServerName() just returns ${jboss.node.name}.
--
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-6063) Deadlock in Module FallbackClassLoader
by Steve Reed (JIRA)
[ https://issues.jboss.org/browse/AS7-6063?page=com.atlassian.jira.plugin.s... ]
Steve Reed updated AS7-6063:
----------------------------
Attachment: ThreadDump-2.txt
> 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
> Fix For: 7.2.0.Alpha1
>
> Attachments: jboss-dead-lock.txt, ThreadDump-2.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
13 years, 7 months
[JBoss JIRA] (AS7-6063) Deadlock in Module FallbackClassLoader
by Steve Reed (JIRA)
[ https://issues.jboss.org/browse/AS7-6063?page=com.atlassian.jira.plugin.s... ]
Steve Reed commented on AS7-6063:
---------------------------------
As instructed, I have re-created today with master pulled on 04/12. However because this is a timing related issue it's very difficult to re-create hence the delay in updating this issue.
I have attached a new Thread dump.
> 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
> Fix For: 7.2.0.Alpha1
>
> Attachments: jboss-dead-lock.txt, ThreadDump-2.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
13 years, 7 months
[JBoss JIRA] (AS7-5583) Allow defining server http port (and other basic properties) via jvm arguments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5583?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5583:
----------------------------------
Fix Version/s: 7.3.0.Alpha1
(was: 7.2.0.Alpha1)
> Allow defining server http port (and other basic properties) via jvm arguments
> ------------------------------------------------------------------------------
>
> Key: AS7-5583
> URL: https://issues.jboss.org/browse/AS7-5583
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Build System, Domain Management
> Affects Versions: 7.1.1.Final
> Reporter: Michal Matloka
> Assignee: Michal Matloka
> Fix For: 7.3.0.Alpha1
>
>
> Currently the only way to specify server port is to edit server configuration .xml. However there are cases which could use definition via jvm arg. Forums shows the following workaround (https://community.jboss.org/thread/168140). I'd like to propose to include in default jboss-as standalone.xml configuration, properties for the most important parameters:
> eg.
> change <socket-binding name="http" port="8080"/> to
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> Then would be possible to run jboss on different port via jvm arg
> ./bin/standalone.sh --server-config=standalone-ha.xml -Djboss.http.port=8888
> Solving this issue is important, because some other issues relies on it: eg. https://issues.jboss.org/browse/AS7-1036
> With this change, solving mentioned ticket would be very easy, and will allow to run arquillian tests directly on jboss downloaded and unpacked via maven goal, and then managed directly via arquillian (it is the only way to run arquillian tests in some environments, however often 8080 port is already used).
> I'm willing to solve this feature by myself, however I'd like to hear opinions from other people.
--
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-5663) CLONE - System properties are currently unusable for setting a connector's proxy-name
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5663?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry reassigned AS7-5663:
-------------------------------------
Assignee: Emanuel Muckenhuber (was: Tomaz Cerar)
Assigning to Emanuel as he is handling the web subsystem aspects of AS7-6120.
> CLONE - System properties are currently unusable for setting a connector's proxy-name
> -------------------------------------------------------------------------------------
>
> Key: AS7-5663
> URL: https://issues.jboss.org/browse/AS7-5663
> Project: Application Server 7
> Issue Type: Enhancement
> Components: Domain Management, Web
> Affects Versions: 7.1.1.Final
> Environment: -JBoss Enterprise Application Platform (EAP) 6.0.0
> Reporter: Aaron Ogburn
> Assignee: Emanuel Muckenhuber
> Fix For: 7.2.0.CR1
>
>
> A connector's proxy-name cannot be set through system properties currently in the web subsystem:
> ==domain.xml==
> <subsystem xmlns="urn:jbossomain:web:1.1" default-virtual-server="default-host" instance-id="${jboss.node.name}"
> native="false">
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" proxy-name="${jboss.proxy.name}"/>
> The property is never parsed though and
> request.getServerName() just returns ${jboss.node.name}.
--
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-5801) Intermittent failures in PersistanceResourceTestCase.testNonPersistentConfigurationFileFromBackupUsingThePrefix
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5801?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5801:
----------------------------------
Fix Version/s: 7.3.0.Alpha1
(was: 7.2.0.CR1)
> Intermittent failures in PersistanceResourceTestCase.testNonPersistentConfigurationFileFromBackupUsingThePrefix
> ---------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5801
> URL: https://issues.jboss.org/browse/AS7-5801
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 7.3.0.Alpha1
>
>
> Reported on the TeamCity server Tomaz has set up:
> Build JBoss AS7 :: Windows testsuite - master-next #35 failed (Tests failed: 1 (1 new), passed: 3513, ignored: 88)
> Agent: build02
> Changes included: 1 change.
> Change 48968c4f68c4ec3c6e3491fa1ab268fbb001cd0c by stuart.w.douglas(a)gmail.com (1 file): AS7-5786 Remote Naming 1.0.5.Final
> Failed tests summary: 1 (1 new)
> (new) org.jboss.as.controller.persistence.PersistanceResourceTestCase.testNonPersistentConfigurationFileFromBackupUsingThePrefix details »
> Stacktraces:
> (new) org.jboss.as.controller.persistence.PersistanceResourceTestCase.testNonPersistentConfigurationFileFromBackupUsingThePrefix
> java.lang.IllegalStateException: JBAS014647: Could not rename C:\BuildAgent\work\54c978af95cc0ab5\controller\target\persistence-test-configs\standard\standard_xml_history\current to C:\BuildAgent\work\54c978af95cc0ab5\controller\target\persistence-test-configs\standard\standard_xml_history\20121019-065647003 at org.jboss.as.controller.persistence.ConfigurationFile.createHistoryDirectory(ConfigurationFile.java:454) at org.jboss.as.controller.persistence.ConfigurationFile.successfulBoot(ConfigurationFile.java:303) at org.jboss.as.controller.persistence.PersistanceResourceTestCase.testNonPersistentConfigurationFileFromBackupUsingThePrefix(PersistanceResourceTestCase.java:463) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
--
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 David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-6105?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on AS7-6105:
----------------------------------
To elaborate....
- The daemon flag is not sufficient as the connector can be shut down without shutting down the container; to do it "right" the thread pool has to be shut down after the connector is shut down.
- If this is not possible to do with an external executor-based thread pool, then we simply shouldn't allow users to configure an executor for AJP within the subsystem configuration.
- If this *generally* not possible to shut down the thread pool after shutting down the connector, then it's a real bug and we have to address that.
> 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-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:
--------------------------------------
It was brought to my attention that I might be misinterpreting that quote from the Oracle docs "The SetBigStringTryClob connection property of Oracle Database 10g Release 1 (10.1) is no longer used or needed". I read that as "Oracle 10.1 and up no longer needs it" but I think it really is saying "that property that was in 10.1 (an apparently used) is no longer needed or used in later versions". So I may be wrong that it isn't used in 10.1.
> 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
> Assignee: Stefano Maestri
> 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] (AS7-5950) Streamline :read-resource-description
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5950?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5950:
----------------------------------
Fix Version/s: 7.3.0.Alpha1
(was: 7.2.0.CR1)
> Streamline :read-resource-description
> -------------------------------------
>
> Key: AS7-5950
> URL: https://issues.jboss.org/browse/AS7-5950
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
> Fix For: 7.3.0.Alpha1
>
>
> We have a need for a streamlined read-resource-description operation response. In many cases we only need the attribute descriptions and from those descriptions only a subset of the meta data available.
> For instance:
> {noformat}
> "enable-statistics" => {
> "type" => BOOLEAN,
> "description" => "Whether statistics should be enabled.",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => false,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {noformat}
> Clients that require information about the structure don't need:
> - access-type
> - storage
> - restart-required
> In many cases we don't even need
> - operations
> - children
> Would it be possible to further parametrize the read-resource-description operation to allow these distinctions? This would help to reduce the overall payload size when clients communicate with the DC and improve thus improve the overall performance. Not to mention parsing greatly benefits from a streamlined model as well.
--
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 Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4673?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-4673:
----------------------------------
Assignee: Stefano Maestri
> 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
> Assignee: Stefano Maestri
> 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