[JBoss JIRA] (ELY-1648) FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509
by Justin Cook (Jira)
[ https://issues.jboss.org/browse/ELY-1648?page=com.atlassian.jira.plugin.s... ]
Justin Cook commented on ELY-1648:
----------------------------------
[~mchoma] I've been able to reproduce the javax.net.ssl.SSLException: Received fatal alert: bad_certificate on the WildFly CLI but I haven't been able to reproduce the error in server.log, which currently does not show any error for me. I saw the error is from com.redhat.eap.qe.cli.CustomCLIExecutor, how do I reproduce that?
> FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509
> -----------------------------------------------------------------------------------
>
> Key: ELY-1648
> URL: https://issues.jboss.org/browse/ELY-1648
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.5.5.Final
> Reporter: Martin Choma
> Assignee: Justin Cook
> Priority: Major
> Attachments: java.security
>
>
> With SunX509 truststore algorithm I can succesfully connect with CLI.
> {code}
> <configuration>
> <authentication-client xmlns="urn:elytron:client:1.1">
> <key-stores>
> <key-store name="truststore" type="PKCS11">
> <key-store-clear-password password="${password}" />
> </key-store>
> </key-stores>
> <ssl-contexts>
> <ssl-context name="client-cli-context">
> <trust-manager algorithm="SunX509" />
> <trust-store key-store-name="truststore" />
> <cipher-suite selector="${cipher.suite.filter}" />
> <protocol names="${protocol}" />
> </ssl-context>
> </ssl-contexts>
> <ssl-context-rules>
> <rule use-ssl-context="client-cli-context" />
> </ssl-context-rules>
> </authentication-client>
> </configuration>
> {code}
> But there is a exception in log
> {code}
> 13:58:27,652 INFO [com.redhat.eap.qe.cli.CustomCLIExecutor] (main) java.security.KeyStoreException: JKS not found
> at java.security.KeyStore.getInstance(KeyStore.java:851)
> at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:59)
> at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:52)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.util.AnchorCertificates.<clinit>(AnchorCertificates.java:52)
> at sun.security.provider.certpath.AlgorithmChecker.checkFingerprint(AlgorithmChecker.java:214)
> at sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:164)
> at sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:118)
> at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:157)
> at sun.security.validator.Validator.validate(Validator.java:260)
> at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
> at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
> at org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:543)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:314)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:204)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:98)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:72)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.security.NoSuchAlgorithmException: JKS KeyStore not available
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
> at java.security.Security.getImpl(Security.java:695)
> at java.security.KeyStore.getInstance(KeyStore.java:848)
> ... 31 more
> {code}
> When I change SunX509 to PKIX exception does not occure anymore.
> Seems exception is thrown by code https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/sun/...
> AnchorCertificates hardcodes JKS keystore creation. Apparently using PKIX it is avoided.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10925) Adjustable limit to DistributableSessionManager.stop waits
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-10925?page=com.atlassian.jira.plugin... ]
Paul Ferraro closed WFLY-10925.
-------------------------------
Resolution: Out of Date
> Adjustable limit to DistributableSessionManager.stop waits
> ----------------------------------------------------------
>
> Key: WFLY-10925
> URL: https://issues.jboss.org/browse/WFLY-10925
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 14.0.0.Beta2
> Reporter: Aaron Ogburn
> Assignee: Paul Ferraro
> Priority: Major
>
> The DistributableSessionManager.stop wait duration is limited to the session manager default session timeout. That's typically 30 minutes or more and quite long for a shut down wait cap.
> Such a wait cap would be more helpful if we can adjust it to a lower desired value so that in case of a hung/long request (or missed session unlock), the DistributableSessionManager.stop doesn't have to take 30+ minutes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11127) Can not get activemq and undertow subsystem data from HTTP management api
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11127?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11127:
-----------------------------------------
+1 thanks [~gaol]. An address is a list of key/value pairs, so yes, the client constructing one as an ordered map will not work as expected if a key is duplicated.
> Can not get activemq and undertow subsystem data from HTTP management api
> -------------------------------------------------------------------------
>
> Key: WFLY-11127
> URL: https://issues.jboss.org/browse/WFLY-11127
> Project: WildFly
> Issue Type: Bug
> Components: Management, Web (Undertow)
> Affects Versions: 12.0.0.Final
> Reporter: Toni Moreno
> Assignee: Lin Gao
> Priority: Critical
>
> As described in https://github.com/wildfly/wildfly/issues/11309
> I can not get some subsystems info data with the HTTP management API working with
>
> ======================================
> "product-version" => "12.0.0.Final",
> "product-community-identifier" => "Product",
> "product-home" => "/usr/local/wildfly-12.0.0.Final",
> "standalone-or-domain-identifier" => "HOST_CONTROLLER",
> "host-operating-system" => "Debian GNU/Linux 8 (jessie)}}
> ===============
> This the a activemq POST request with curl and its error
> ---------8<------------------------------------------8<-----------------------
> root@snmpcoldev01:~# curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"host":"master","server":"server-two","subsystem":"messaging-activemq","server":"default"},"operation":"read-children-resources","child-type":"jms-queue","include-runtime":"true","json.pretty":1,"recursive-depth":2}' -u admin
> Enter host password for user 'admin':
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm", nonce="ABCwnAAANoo77ka2vPx9H1LY0IuT5cmkcn5HWBS88gigGzT786K6qnnpMAk=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth
> X-Frame-Options: SAMEORIGIN
> Content-Length: 77
> Content-Type: text/html
> Date: Sat, 02 Jun 2018 08:05:53 GMT
> HTTP/1.1 500 Internal Server Error
> Connection: keep-alive
> X-Frame-Options: SAMEORIGIN
> Content-Type: application/json; charset=utf-8
> Content-Length: 103
> Date: Sat, 02 Jun 2018 08:05:53 GMT
> "java.io.IOException: org.jboss.dmr.stream.ModelException: Unexpected content following the DMR
> --------->8------------------------------------------>8-----------------------
> And this the query with the GUI client
> [jboss_jms_queue_gui_query|https://user-images.githubusercontent.com/58834...]
> Also with undertow subsystem
> ---------8<------------------------------------------8<-----------------------
> root@snmpcoldev01:~# curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"address":{"host":"master","server":"server-two","subsystem":"undertow","server":"default-server","http-listener":"default"},"include-runtime":"true","json.pretty":1,"operation":"read-resource","recursive-depth":0}' -u admin
> Enter host password for user 'admin':
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm", nonce="ABC0jwAAN04NaeQD9tlEeeNzizRu5PGuUY9Adi18uuLUzOM1RZNHWkCqnc4=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth
> X-Frame-Options: SAMEORIGIN
> Content-Length: 77
> Content-Type: text/html
> Date: Sat, 02 Jun 2018 08:19:54 GMT
> HTTP/1.1 500 Internal Server Error
> Connection: keep-alive
> X-Frame-Options: SAMEORIGIN
> Content-Type: application/json; charset=utf-8
> Content-Length: 302
> Date: Sat, 02 Jun 2018 08:19:54 GMT
> {
> "outcome" : "failed",
> "failure-description" : "WFLYCTL0030: No resource definition is registered for address [\n (\"host\" => \"master\"),\n (\"server\" => \"default-server\"),\n (\"subsystem\" => \"undertow\"),\n (\"http-listener\" => \"default\")\n]",
> "rolled-back" : true
> }
> --------->8------------------------------------------>8-----------------------
> Here Image of the GUI management query.
> [jboss_undertow_listener_gui_query|https://user-images.githubusercontent.c...]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3339) refactor the PMML regression model to use an external library for regressions
by michael mccune (Jira)
[ https://issues.jboss.org/browse/DROOLS-3339?page=com.atlassian.jira.plugi... ]
michael mccune commented on DROOLS-3339:
----------------------------------------
ahh, my bad [~tirelli], i misunderstood about which topic was for the epic.
i'm fine with either solution here, i can either add more to this card or we can convert to an issue and include in another epic.
> refactor the PMML regression model to use an external library for regressions
> -----------------------------------------------------------------------------
>
> Key: DROOLS-3339
> URL: https://issues.jboss.org/browse/DROOLS-3339
> Project: Drools
> Issue Type: Epic
> Components: PMML
> Affects Versions: 7.14.0.Final
> Reporter: michael mccune
> Assignee: michael mccune
> Priority: Critical
>
> Replace the current DRL generation for regression calculation by a specialized regression library, in order to simplify the code and improve compilation and runtime performance.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11360) JCAOrderedLastSynchronizationList shouldn't be skipped for org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry registered Synchronizations
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11360?page=com.atlassian.jira.plugin... ]
Scott Marlow closed WFLY-11360.
-------------------------------
I just verified that this issue is resolved on WildFly master, thanks for the quick fix [~brian.stansberry]!
> JCAOrderedLastSynchronizationList shouldn't be skipped for org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry registered Synchronizations
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11360
> URL: https://issues.jboss.org/browse/WFLY-11360
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.0.Beta1
> Reporter: Scott Marlow
> Assignee: Brian Stansberry
> Priority: Blocker
> Fix For: 15.0.0.CR1
>
>
> JPA container synchronizations are not registered via JCAOrderedLastSynchronizationList, which means that JCA Synchronization#afterCompletion will not always run after JPA Synchronization#afterCompletion.
> Apparently we are doing a JNDI lookup of "java:jboss/TransactionSynchronizationRegistry" for Hibernate ORM integration, which means we are using the org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper for Hibernate ORM. Should we also be using the org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper class in other WildFly call sites, instead of org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry?
> Call stack below shows the JPA container sync not being registered via JCAOrderedLastSynchronizationList:
> {code}
> 10:48:42,859 ERROR [stderr] (pool-7-thread-7) at java.lang.Thread.dumpStack(Thread.java:1336)
> 10:48:42,865 ERROR [stderr] (pool-7-thread-7) at org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry.registerInterposedSynchronization(ContextTransactionSynchronizationRegistry.java:77)
> 10:48:42,866 ERROR [stderr] (pool-7-thread-7) at org.jboss.as.jpa.transaction.TransactionUtil.registerSynchronization(TransactionUtil.java:74)
> 10:48:42,866 ERROR [stderr] (pool-7-thread-7) at org.jboss.as.jpa.container.TransactionScopedEntityManager.getOrCreateTransactionScopedEntityManager(TransactionScopedEntityManager.java:162)
> 10:48:42,867 ERROR [stderr] (pool-7-thread-7) at org.jboss.as.jpa.container.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityManager.java:87)
> 10:48:42,867 ERROR [stderr] (pool-7-thread-7) at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:580)
> 10:48:42,867 ERROR [stderr] (pool-7-thread-7) at org.jboss.as.test.integration.jpa.transaction.UnsynchronizedSFSB.createAndPropagatedFindMixExceptionExcepted(UnsynchronizedSFSB.java:88)
> {code}
> Call stack below shows the JCA synchronization is also *NOT* registered correctly via JCAOrderedLastSynchronizationList:
> {code}
> 10:45:06,979 ERROR [stderr] (pool-7-thread-8) java.lang.Exception: Stack trace
> 10:45:06,980 ERROR [stderr] (pool-7-thread-8) at java.lang.Thread.dumpStack(Thread.java:1336)
> 10:45:06,980 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.<init>(SynchronizationImple.java:57)
> 10:45:06,980 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.provider.jboss.JBossJTALocalTransactionProvider.registerInterposedSynchronization(JBossJTALocalTransactionProvider.java:87)
> 10:45:06,981 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.LocalTransaction.registerInterposedSynchronization(LocalTransaction.java:202)
> 10:45:06,981 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry.registerInterposedSynchronization(ContextTransactionSynchronizationRegistry.java:77)
> 10:45:06,981 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.lock(TransactionSynchronizer.java:309)
> 10:45:06,981 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:311)
> 10:45:06,982 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:564)
> 10:45:06,982 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:970)
> 10:45:06,982 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:792)
> 10:45:06,982 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> 10:45:06,983 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> 10:45:06,983 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122)
> 10:45:06,983 ERROR [stderr] (pool-7-thread-8) at org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:35)
> 10:45:06,983 ERROR [stderr] (pool-7-thread-8) at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:106)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:136)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:47)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$1.doPrepare(StatementPreparerImpl.java:87)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:172)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareStatement(StatementPreparerImpl.java:78)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3152)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3686)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:90)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
> 10:45:06,986 ERROR [stderr] (pool-7-thread-8) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454)
> 10:45:06,986 ERROR [stderr] (pool-7-thread-8) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511)
> 10:45:06,986 ERROR [stderr] (pool-7-thread-8) at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283)
> 10:45:06,986 ERROR [stderr] (pool-7-thread-8) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479)
> 10:45:06,986 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473)
> 10:45:06,987 ERROR [stderr] (pool-7-thread-8) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:352)
> 10:45:06,987 ERROR [stderr] (pool-7-thread-8) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47)
> 10:45:06,987 ERROR [stderr] (pool-7-thread-8) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37)
> 10:45:06,987 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:113)
> 10:45:06,987 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 10:45:06,989 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288)
> 10:45:06,989 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 10:45:06,989 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> 10:45:06,989 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:77)
> 10:45:06,989 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.LocalUserTransaction.commit(LocalUserTransaction.java:53)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.test.integration.jpa.transaction.SFSB1.createEmployee(SFSB1.java:96)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at java.lang.reflect.Method.invoke(Method.java:498)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ejb3.tx.StatefulBMTInterceptor.handleInvocation(StatefulBMTInterceptor.java:94)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:137)
> {code}
> Lastly, the following call stack shows the Hibernate ORM sync being correctly registered via JCAOrderedLastSynchronizationList:
> {code}
> 10:52:20,820 ERROR [stderr] (pool-7-thread-1) java.lang.Exception: Stack trace
> 10:52:20,821 ERROR [stderr] (pool-7-thread-1) at java.lang.Thread.dumpStack(Thread.java:1336)
> 10:52:20,821 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.registerInterposedSynchronization(JCAOrderedLastSynchronizationList.java:64)
> 10:52:20,821 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.registerInterposedSynchronization(TransactionSynchronizationRegistryWrapper.java:76)
> 10:52:20,821 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.jpa.hibernate5.service.WildFlyCustomJtaPlatform$1.registerSynchronization(WildFlyCustomJtaPlatform.java:45)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.engine.transaction.jta.platform.internal.AbstractJtaPlatform.registerSynchronization(AbstractJtaPlatform.java:126)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.joinJtaTransaction(JtaTransactionCoordinatorImpl.java:170)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.pulse(JtaTransactionCoordinatorImpl.java:158)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.<init>(JtaTransactionCoordinatorImpl.java:94)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl.buildTransactionCoordinator(JtaTransactionCoordinatorBuilderImpl.java:29)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.AbstractSharedSessionContract.<init>(AbstractSharedSessionContract.java:204)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.AbstractSessionImpl.<init>(AbstractSessionImpl.java:29)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.SessionImpl.<init>(SessionImpl.java:254)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.SessionFactoryImpl$SessionBuilderImpl.openSession(SessionFactoryImpl.java:1290)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.SessionFactoryImpl.buildEntityManager(SessionFactoryImpl.java:628)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.SessionFactoryImpl.createEntityManager(SessionFactoryImpl.java:614)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.SessionFactoryImpl.createEntityManager(SessionFactoryImpl.java:154)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.jpa.container.TransactionScopedEntityManager.createEntityManager(TransactionScopedEntityManager.java:187)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.jpa.container.TransactionScopedEntityManager.getOrCreateTransactionScopedEntityManager(TransactionScopedEntityManager.java:157)
> 10:52:20,824 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.jpa.container.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityManager.java:87)
> 10:52:20,824 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.jpa.container.AbstractEntityManager.joinTransaction(AbstractEntityManager.java:536)
> 10:52:20,824 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.test.integration.jpa.transaction.SFSB1.createEmployee(SFSB1.java:93)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3339) refactor the PMML regression model to use an external library for regressions
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-3339?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-3339:
---------------------------------------
[~elmiko] there is no hard rule on this, it is up to the engineer. I think I suggested the EPIC for the general work across modules: so regression first, but then mining, and working on the data mappings, etc. For the regression itself, it can be condensed into a single ticket I think as it is not that big.
Again, no hard rules, use whatever approach you prefer, as long as you are happy with it and it allows the scrum team to track progress.
> refactor the PMML regression model to use an external library for regressions
> -----------------------------------------------------------------------------
>
> Key: DROOLS-3339
> URL: https://issues.jboss.org/browse/DROOLS-3339
> Project: Drools
> Issue Type: Epic
> Components: PMML
> Affects Versions: 7.14.0.Final
> Reporter: michael mccune
> Assignee: michael mccune
> Priority: Critical
>
> Replace the current DRL generation for regression calculation by a specialized regression library, in order to simplify the code and improve compilation and runtime performance.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
