[JBoss JIRA] (ELY-1493) java.util.concurrent.TimeoutException on slow machines
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1493?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reopened ELY-1493:
-----------------------------
> java.util.concurrent.TimeoutException on slow machines
> ------------------------------------------------------
>
> Key: ELY-1493
> URL: https://issues.jboss.org/browse/ELY-1493
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.2.0.Beta11
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Fix For: 1.2.0.Beta12
>
>
> On solaris 10 (slow machine) there occured timeout for task task2Future.get(1, TimeUnit.SECONDS) on line 492.
> Prolong timeout will probably reduce occurences.
> {noformat}
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:459)
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testParallelAccessToCS(KeystorePasswordStoreTest.java:439)
> Caused by: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:205)
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:457)
> ... 1 more
> Caused by: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest$1.call(KeystorePasswordStoreTest.java:492)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-10280:
-------------------------------------------
What is puzzling is that if you enable passivation after remove of remote, everything is fine.
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Bartosz Baranowski
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> Steps to reproduce:
> {code}
> unzip wildfly-12.0.0.Final.zip
> cd wildfly-12.0.0.Final
> cp tinyEjbPassivation.war standalone/deployments # any EJB deployment should do
> ./bin/jboss-cli.sh
> embed-server --admin-only --std-out=echo --server-config=standalone-full.xml
> /subsystem=ejb3:write-attribute(name=default-sfsb-cache,value=passivating)
> /subsystem=ejb3/service=remote:remove
> reload --start-mode=normal
> {code}
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2271) Race condition in BaseServer.getConnection
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2271?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2271 at 6/15/18 3:59 AM:
---------------------------------------------------------
Hmm, this is a bit more complicated than I thought: {{Socket.isConnected()}} returns true if is has been connected, even if it has been closed later! So the correct condition should be {{if(sock.isConnected() && !sock.isClosed())}} !
This is bad as {{Socket.isClosed()}} acquires {{sockLock}}, which is costly. I guess keeping a {{connected}} variable in {{Connection}} itself, which is set to true on successful connect and false on close, is our best option...
was (Author: belaban):
Hmm, this is a bit more complicated than I thought: Socket.isConnected() returns true if is has been connected, even if it has been closed later! So the correct condition should be {{if(sock.isConnected() && !sock.isClosed())}} !
This is bad as Socket.isClosed() acquired {{sockLock}}, which is costly. I guess keeping a {{connected}} variable in {{Connection}} itself, which is set to true on successful connect and false on close, is our best option...
> Race condition in BaseServer.getConnection
> ------------------------------------------
>
> Key: JGRP-2271
> URL: https://issues.jboss.org/browse/JGRP-2271
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Fix For: 4.0.12, 3.6.16
>
>
> BaseServer.getConnection creates a socket and puts it in the shared map under a lock.
> However it does not connect the socket inside the lock, so another thread calling getConnection at the same time can get the unconnected socket, which will throw a NPE when used because it's not connected yet (all the checks before returning and using it only look for isOpen, not isConnected).
> java.lang.NullPointerException
> at org.jgroups.blocks.cs.TcpConnection.doSend(TcpConnection.java:184)
> at org.jgroups.blocks.cs.TcpConnection._send(TcpConnection.java:171)
> at org.jgroups.blocks.cs.TcpConnection.send(TcpConnection.java:141)
> at org.jgroups.blocks.cs.BaseServer.send(BaseServer.java:185)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2271) Race condition in BaseServer.getConnection
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2271?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2271:
--------------------------------
Hmm, this is a bit more complicated than I thought: Socket.isConnected() returns true if is has been connected, even if it has been closed later! So the correct condition should be {{if(sock.isConnected() && !sock.isClosed())}}!
This is bad as Socket.isClosed() acquired {{sockLock}}, which is costly. I guess keeping a {{connected}} variable in {{Connection}} itself, which is set to true on successful connect and false on close, is our best option...
> Race condition in BaseServer.getConnection
> ------------------------------------------
>
> Key: JGRP-2271
> URL: https://issues.jboss.org/browse/JGRP-2271
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Fix For: 4.0.12, 3.6.16
>
>
> BaseServer.getConnection creates a socket and puts it in the shared map under a lock.
> However it does not connect the socket inside the lock, so another thread calling getConnection at the same time can get the unconnected socket, which will throw a NPE when used because it's not connected yet (all the checks before returning and using it only look for isOpen, not isConnected).
> java.lang.NullPointerException
> at org.jgroups.blocks.cs.TcpConnection.doSend(TcpConnection.java:184)
> at org.jgroups.blocks.cs.TcpConnection._send(TcpConnection.java:171)
> at org.jgroups.blocks.cs.TcpConnection.send(TcpConnection.java:141)
> at org.jgroups.blocks.cs.BaseServer.send(BaseServer.java:185)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2271) Race condition in BaseServer.getConnection
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2271?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2271 at 6/15/18 3:58 AM:
---------------------------------------------------------
Hmm, this is a bit more complicated than I thought: Socket.isConnected() returns true if is has been connected, even if it has been closed later! So the correct condition should be {{if(sock.isConnected() && !sock.isClosed())}} !
This is bad as Socket.isClosed() acquired {{sockLock}}, which is costly. I guess keeping a {{connected}} variable in {{Connection}} itself, which is set to true on successful connect and false on close, is our best option...
was (Author: belaban):
Hmm, this is a bit more complicated than I thought: Socket.isConnected() returns true if is has been connected, even if it has been closed later! So the correct condition should be {{if(sock.isConnected() && !sock.isClosed())}}!
This is bad as Socket.isClosed() acquired {{sockLock}}, which is costly. I guess keeping a {{connected}} variable in {{Connection}} itself, which is set to true on successful connect and false on close, is our best option...
> Race condition in BaseServer.getConnection
> ------------------------------------------
>
> Key: JGRP-2271
> URL: https://issues.jboss.org/browse/JGRP-2271
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Fix For: 4.0.12, 3.6.16
>
>
> BaseServer.getConnection creates a socket and puts it in the shared map under a lock.
> However it does not connect the socket inside the lock, so another thread calling getConnection at the same time can get the unconnected socket, which will throw a NPE when used because it's not connected yet (all the checks before returning and using it only look for isOpen, not isConnected).
> java.lang.NullPointerException
> at org.jgroups.blocks.cs.TcpConnection.doSend(TcpConnection.java:184)
> at org.jgroups.blocks.cs.TcpConnection._send(TcpConnection.java:171)
> at org.jgroups.blocks.cs.TcpConnection.send(TcpConnection.java:141)
> at org.jgroups.blocks.cs.BaseServer.send(BaseServer.java:185)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-6409) Update default domain configuration to use remote+http
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6409?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet updated WFLY-6409:
------------------------------------
Description:
Our default domain configuration still use the native remote protocol on port 9999 for DC-HC communication. Update those files so that we use remote+http on port 9990.
Replace usage of the deprecated http-remoting by remote+http.
was:
Our default domain configuration still use the native remote protocol on port 9999 for DC-HC communication. Update those files so that we use http-remoting on port 9990.
> Update default domain configuration to use remote+http
> ------------------------------------------------------
>
> Key: WFLY-6409
> URL: https://issues.jboss.org/browse/WFLY-6409
> Project: WildFly
> Issue Type: Enhancement
> Components: Management
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Labels: domain-mode
>
> Our default domain configuration still use the native remote protocol on port 9999 for DC-HC communication. Update those files so that we use remote+http on port 9990.
> Replace usage of the deprecated http-remoting by remote+http.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10494) HHH-12651 org.hibernate.Session.*Query(Ljava/lang/String) methods return different types in 5.1 and 5.3
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFLY-10494?page=com.atlassian.jira.plugin... ]
Gail Badner commented on WFLY-10494:
------------------------------------
[~smarlow], [~simkam], this has been fixed upstream for 5.3.2.
[~simkam], can you re-run tests using Hibernate 0RM 5.3.2-SNAPSHOT and let me know if anything else breaks?
> HHH-12651 org.hibernate.Session.*Query(Ljava/lang/String) methods return different types in 5.1 and 5.3
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10494
> URL: https://issues.jboss.org/browse/WFLY-10494
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 13.0.0.Final
> Reporter: Martin Simka
> Assignee: Scott Marlow
> Priority: Blocker
> Labels: blocker-WF14
>
> https://hibernate.atlassian.net/browse/HHH-12651
> although mentioned in HHH-12424, it doesn't seem to be resolved
> in 5.1
> org.hibernate.Session.createQuery(Ljava/lang/String;)Lorg/hibernate/Query
> in 5.3
> org.hibernate.Session.createQuery(Ljava/lang/String;)Lorg/hibernate.query.Query
> It happens when code compiled with Hibernate ORM 5.1 is run with Hibernate ORM 5.3
> I attached very simple reproducer class.
> {code}
> # compile with Hibernate 5.1
> javac App.java -cp ~/.m2/repository/org/hibernate/hibernate-core/5.1.9.Final/hibernate-core-5.1.9.Final.jar
> # run with 5.1 => ok
> java -cp .:/home/msimka/.m2/repository/org/hibernate/hibernate-core/5.1.9.Final/hibernate-core-5.1.9.Final.jar App
> # run with 5.3 => fail
> java -cp .:/home/msimka/.m2/repository/org/hibernate/hibernate-core/5.3.1.Final/hibernate-core-5.3.1.Final.jar:/home/msimka/.m2/repository/javax/persistence/javax.persistence-api/2.2/javax.persistence-api-2.2.jar App
> Exception in thread "main" java.lang.NoSuchMethodError: org.hibernate.Session.createQuery(Ljava/lang/String;)Lorg/hibernate/Query;
> at App.main(App.java:35)
> {code}
> other methods with the same issue:
> java.lang.NoSuchMethodError: org.hibernate.Session.getNamedQuery(Ljava/lang/String;)Lorg/hibernate/Query;
> java.lang.NoSuchMethodError: org.hibernate.Session.createSQLQuery(Ljava/lang/String;)Lorg/hibernate/SQLQuery;
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SECURITY-993) SimpleRole.hashCode NPE when a principal has the roles set to null
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/SECURITY-993?page=com.atlassian.jira.plug... ]
Ilia Vassilev updated SECURITY-993:
-----------------------------------
Git Pull Request: https://github.com/picketbox/picketbox/pull/81
> SimpleRole.hashCode NPE when a principal has the roles set to null
> ------------------------------------------------------------------
>
> Key: SECURITY-993
> URL: https://issues.jboss.org/browse/SECURITY-993
> Project: PicketBox
> Issue Type: Bug
> Components: Identity
> Affects Versions: PicketBox_5_1_0.Final
> Environment: Wild Fly Swarm 2018.2.0
> Reporter: Sergey Beryozkin
> Assignee: Ilia Vassilev
> Priority: Minor
> Fix For: PicketBox_5_1_1.Beta1
>
>
> If a principal is created with the roles set to null then NPE is reported back to the user during the authentication process:
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:140)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:94)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> ....
> Caused by: java.lang.NullPointerException
> at org.jboss.security.identity.plugins.SimpleRole.hashCode(SimpleRole.java:106)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month