[JBoss JIRA] (DROOLS-450) Cannot use decimal formatters for integers in an excel decision table
by Maxime Falaize (JIRA)
[ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin... ]
Maxime Falaize commented on DROOLS-450:
---------------------------------------
I added a test case to my PR. You can test it with and without the patch.
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
> Key: DROOLS-450
> URL: https://issues.jboss.org/browse/DROOLS-450
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Maxime Falaize
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
> text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-2334) EL expansion broken in persistence.xml
by Ken H (JIRA)
[ https://issues.jboss.org/browse/WFLY-2334?page=com.atlassian.jira.plugin.... ]
Ken H updated WFLY-2334:
------------------------
Description:
When testing migration from Jboss AS 7.1.1 to 7.2.0.Final or WildFly 8.0.0.Final, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
{code}
<jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
{code}
was:
When testing migration from Jboss AS 7.1.1, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
{code}
<jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
{code}
> EL expansion broken in persistence.xml
> --------------------------------------
>
> Key: WFLY-2334
> URL: https://issues.jboss.org/browse/WFLY-2334
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final
> Environment: OSX, jdk 1.7.0_21
> Reporter: Ken H
>
> When testing migration from Jboss AS 7.1.1 to 7.2.0.Final or WildFly 8.0.0.Final, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
> {code}
> <jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
> {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
10 years, 10 months
[JBoss JIRA] (WFLY-2334) EL expansion broken in persistence.xml
by Ken H (JIRA)
[ https://issues.jboss.org/browse/WFLY-2334?page=com.atlassian.jira.plugin.... ]
Ken H updated WFLY-2334:
------------------------
Affects Version/s: 8.0.0.Final
JBoss AS7 7.2.0.Final
(was: 8.0.0.Beta1)
> EL expansion broken in persistence.xml
> --------------------------------------
>
> Key: WFLY-2334
> URL: https://issues.jboss.org/browse/WFLY-2334
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final
> Environment: OSX, jdk 1.7.0_21
> Reporter: Ken H
>
> When testing migration from Jboss AS 7.1.1, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
> {code}
> <jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
> {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
10 years, 10 months
[JBoss JIRA] (WFLY-2474) Security subsystem does not handle acl's module properly, and is missing transformer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2474?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2474:
-----------------------------------------------
Tomaz Cerar <tcerar(a)redhat.com> changed the Status of [bug 1029938|https://bugzilla.redhat.com/show_bug.cgi?id=1029938] from NEW to POST
> Security subsystem does not handle acl's module properly, and is missing transformer
> ------------------------------------------------------------------------------------
>
> Key: WFLY-2474
> URL: https://issues.jboss.org/browse/WFLY-2474
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.0.0.CR1
>
>
> The parsed add is done for /subsystem=security/security-domain=other/acl=classic/acl-module=acl
> However in the acl resource this is called login-module=acl.
> WHen marshalling
> {code}
> <acl>
> <acl-module name="acl" code="AclThingy" flag="required" module="test">
> <module-option name="d" value="r"/>
> </acl-module>
> </acl>
> {code}
> becomes
> {code}
> <acl>
> <login-module name="acl" code="AclThingy" flag="required" module="test">
> <module-option name="d" value="r"/>
> </login-module>
> </acl>
> {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
10 years, 10 months
[JBoss JIRA] (JGRP-1792) "No buffer space available" when sending on Mac OS
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1792?page=com.atlassian.jira.plugin.... ]
Bela Ban reopened JGRP-1792:
----------------------------
Occurred again
> "No buffer space available" when sending on Mac OS
> --------------------------------------------------
>
> Key: JGRP-1792
> URL: https://issues.jboss.org/browse/JGRP-1792
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> When sending multicast messages (with MPerf & fast.xml), the following message appears:
> {noformat}
> 8981 [ERROR] UDP: JGRP000029: A: failed sending message to cluster (1053 bytes): java.io.IOException: No buffer space available,
> headers: MPerf: DATA999, NAKACK2: [MSG, seqno=1003], UDP: [cluster_name=mperf]
> {noformat}
> The messages *are* received, but the error message occurs on almost every message (1 sender thread sending 1000 messages).
> With {{UdpPerf}} (also shipped with JGroups), which also multicasts messages, the error doesn't happen.
> With {{UPerf}}, which uses unicasts, the error doesn't occur either.
> Todo: compare UdpPerf to MPerf (UDP protocol) to see what the diff is.
--
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
10 years, 10 months
[JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite behaves differently with various JDKs
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/JBWEB-294?page=com.atlassian.jira.plugin.... ]
Jean-Frederic Clere commented on JBWEB-294:
-------------------------------------------
I will ignore the "JBWEB002081: No cipher match" until you check the cipher supported by the JVM.
For the javax.net.ssl.SSLHandshakeException you need to find which cipher causes it and look in the debug of the ssl to make sure what is wrong - guess the certificate doesn't correspond to the cipher you ask? -
> The same JSSE cipher-suite behaves differently with various JDKs
> ----------------------------------------------------------------
>
> Key: JBWEB-294
> URL: https://issues.jboss.org/browse/JBWEB-294
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.4.0.GA
> Reporter: Michal Babacek
> Assignee: Remy Maucherat
> Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys, I believe this is a bug, but correct me if it's just a feature unknown to me.
> I have the following settings:
> h3. Apache HTTP Server (mod_cluster load balancer)
> {code}
> Listen 10.16.92.111:8847
> LogLevel debug
> <VirtualHost 10.16.92.111:8847>
> ServerName 10.16.92.111:8847
> <Directory />
> Order deny,allow
> Deny from all
> Allow from all
> </Directory>
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> ServerAdvertise on
> AdvertiseFrequency 5
> ManagerBalancerName qacluster
> AdvertiseGroup 224.0.5.98:60220
> EnableMCPMReceive
> SSLEngine on
> SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
> SSLCertificateFile /mnt/hudson_workspace/proper/server.crt
> SSLCertificateKeyFile /mnt/hudson_workspace/proper/server.key
> SSLCACertificateFile /mnt/hudson_workspace/proper/myca.crt
> #SSLVerifyClient require
> #SSLProxyVerify require
> SSLProxyEngine On
> SSLVerifyDepth 10
> <Location /mcm>
> SetHandler mod_cluster-manager
> Order deny,allow
> Deny from all
> Allow from all
> </Location>
> </VirtualHost>
> {code}
> h3. JBossWeb subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https"
> scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
> certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> certificate-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> password="tomcat" verify-client="false" key-alias="javaclient"
> cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
> protocol="TLS"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> h3. mod_cluster subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config connector="https" advertise-socket="modcluster">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
> certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> password="tomcat" key-alias="javaclient"
> cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
> protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> {code}
> h3. Some properties
> {code}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/mnt/hudson_workspace/proper/client-cert-key.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> <property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-6.3"/>
> <property name="jboss.node.name" value="jboss-eap-6.3"/>
> </system-properties>
> {code}
> The test runs several standalone-ha instances, client accesses the AS7 instances directly, then via mod_cluster load balancer. Some of the AS7 instances are being shut down, failover takes place. Client uses client certificate for authentication.
> The result of this test is as follows:
> ||JDK||Arch||Error||Test result||
> |Oracle JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |Oracle JDK 1.7|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |Oracle JDK 1.8|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |IBM JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |IBM JDK 1.7|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |OpenJDK 1.7|RHEL6 x64| |(/)|
> |OpenJDK 1.6|RHEL6 x64| |(/)|
> |HP JDK 1.7|HP-UX v11.3|JBWEB002081: No cipher match|(x)|
> h4. (i) javax.net.ssl.SSLHandshakeException
> The funny thing here is that the client can access the AS7 server directly, HTTPS connector is up and running just fine, certificates valid, no problem.
> Yet, the AS7 server fails to do handshake with the Apache HTTP Server instance.
> Please, note that in the aforementioned cipher-suite, some (those leveraging AES-128) methods are prefixed with *!*, so are some methods in the aforementioned Apache HTTP Server configuration.
> {noformat}
> [0m[31m12:58:35,574 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to 10.16.94.122/10.16.94.122:8847: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.7.0_45]
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) [jsse.jar:1.7.0_45]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [rt.jar:1.7.0_45]
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [rt.jar:1.7.0_45]
> at java.io.BufferedWriter.flush(BufferedWriter.java:254) [rt.jar:1.7.0_45]
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:494)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:583)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:370)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458)
> at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249)
> at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> h3. Question
> How come that some JDKs does not know these JSSE cipher-suite methods, some JDKs do, but fail to do handshake with Apache HTTP Server whereas OpenJDK simply passes with "all green"?
> What is actually a bug? Is it that OpenJDK should fail as well, because the configuration is wrong, or the other JDKs should pass?
--
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
10 years, 10 months
[JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on AspectManager
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.... ]
Yong Hao Gao closed JBMESSAGING-1941.
-------------------------------------
Resolution: Done
Note: Aaron not in the assignee list so I assigned to me. The fix has been done by Aaron.
> Messaging deadlocks on AspectManager
> ------------------------------------
>
> Key: JBMESSAGING-1941
> URL: https://issues.jboss.org/browse/JBMESSAGING-1941
> Project: JBoss Messaging
> Issue Type: Bug
> Affects Versions: 1.4.8.SP9
> Environment: -JBoss Enterprise Application Platform (EAP) 5
> Reporter: Aaron Ogburn
> Assignee: Yong Hao Gao
> Fix For: 1.4.8.SP10
>
> Attachments: 00779442testpatch.diff, JBMESSAGING-1941.diff
>
>
> Messaging can stall JBoss at start up. The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat}
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
> - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
> at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
> - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat}
> Since the main thread is stalled, so too is start up. This lock is always held by another making a similar call like so:
> {noformat}
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
> java.lang.Thread.State: RUNNABLE
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
> - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat}
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
> synchronized (AspectManager.instance())
> {
> advised = new SessionAdvised(ep); // line 273
> }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses. There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait(). Checking the thread through pstack, we can see the issue. It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0 0x0000003b3e40b43c in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1 0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2 0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3 0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4 0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5 0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6 0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time. Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is. But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here. The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock. It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager. This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.
--
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
10 years, 10 months
[JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on AspectManager
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.... ]
Yong Hao Gao reassigned JBMESSAGING-1941:
-----------------------------------------
Assignee: Yong Hao Gao
> Messaging deadlocks on AspectManager
> ------------------------------------
>
> Key: JBMESSAGING-1941
> URL: https://issues.jboss.org/browse/JBMESSAGING-1941
> Project: JBoss Messaging
> Issue Type: Bug
> Affects Versions: 1.4.8.SP9
> Environment: -JBoss Enterprise Application Platform (EAP) 5
> Reporter: Aaron Ogburn
> Assignee: Yong Hao Gao
> Attachments: 00779442testpatch.diff, JBMESSAGING-1941.diff
>
>
> Messaging can stall JBoss at start up. The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat}
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
> - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
> at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
> - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat}
> Since the main thread is stalled, so too is start up. This lock is always held by another making a similar call like so:
> {noformat}
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
> java.lang.Thread.State: RUNNABLE
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
> - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat}
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
> synchronized (AspectManager.instance())
> {
> advised = new SessionAdvised(ep); // line 273
> }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses. There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait(). Checking the thread through pstack, we can see the issue. It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0 0x0000003b3e40b43c in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1 0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2 0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3 0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4 0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5 0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6 0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time. Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is. But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here. The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock. It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager. This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.
--
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
10 years, 10 months
[JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on AspectManager
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1941:
--------------------------------------
Fix Version/s: 1.4.8.SP10
> Messaging deadlocks on AspectManager
> ------------------------------------
>
> Key: JBMESSAGING-1941
> URL: https://issues.jboss.org/browse/JBMESSAGING-1941
> Project: JBoss Messaging
> Issue Type: Bug
> Affects Versions: 1.4.8.SP9
> Environment: -JBoss Enterprise Application Platform (EAP) 5
> Reporter: Aaron Ogburn
> Assignee: Yong Hao Gao
> Fix For: 1.4.8.SP10
>
> Attachments: 00779442testpatch.diff, JBMESSAGING-1941.diff
>
>
> Messaging can stall JBoss at start up. The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat}
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
> - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
> at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
> - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat}
> Since the main thread is stalled, so too is start up. This lock is always held by another making a similar call like so:
> {noformat}
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
> java.lang.Thread.State: RUNNABLE
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
> - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat}
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
> synchronized (AspectManager.instance())
> {
> advised = new SessionAdvised(ep); // line 273
> }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses. There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait(). Checking the thread through pstack, we can see the issue. It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0 0x0000003b3e40b43c in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1 0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2 0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3 0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4 0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5 0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6 0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time. Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is. But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here. The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock. It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager. This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.
--
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
10 years, 10 months