[JBoss JIRA] (WFLY-5131) Kerberos authentication for remoting EJB without interaction does not fallback correctly
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5131?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-5131:
--------------------------------------
Assignee: Darran Lofthouse (was: David Lloyd)
> Kerberos authentication for remoting EJB without interaction does not fallback correctly
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-5131
> URL: https://issues.jboss.org/browse/WFLY-5131
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Affects Versions: 10.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when kerberos authentication with properties fallback is correctly configured in security realm and user without correct kerberos ticket tries to invoke EJB via EJB client, then EJB client asks for kerberos username in interactive mode. It works correctly when user interacts with this mode but it causes inconvenience for access without user interaction. Fallback cannot be taken into account because EJB invocation stucks in interactive mode which leads to RuntimeException: Operation failed with status WAITING. There should be any possibility how to disable interactive mode for users which invoke EJB without kerberos.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5456) Failback of standalone JMS client fails with http connector
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-5456?page=com.atlassian.jira.plugin.... ]
Miroslav Novak reopened WFLY-5456:
----------------------------------
> Failback of standalone JMS client fails with http connector
> -----------------------------------------------------------
>
> Key: WFLY-5456
> URL: https://issues.jboss.org/browse/WFLY-5456
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Critical
> Attachments: log.txt, servers.zip, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> Failback of standalone JMS client fails if http connector is used. There are 2 EAP 7.0.0.DR11 (Artemis 1.1.0) servers configured in dedicated topology with shared store.
> If live server is killed (clients failover) and then restarted (so failback occurs) then sometimes client does not failback to live server.
> From the thread dump of one client it seems that it's stuck on:
> {code}
> Stack trace of thread: Thread[Thread-16,5,main]
> Stack trace of thread: Thread[Thread-2 (ActiveMQ-client-global-threads-1995983824),5,ActiveMQ-client-global-threads-1995983824]
> ---sun.misc.Unsafe.park(Native Method)
> ---java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> ---java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> ---java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> ---java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> ---org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.waitOnLatch(ActiveMQClientProtocolManager.java:130)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:770)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:694)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:558)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:461)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$400(ClientSessionFactoryImpl.java:68)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1120)
> ---org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:57)
> ---org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:204)
> ---org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:179)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:946)
> ---org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:94)
> ---java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ---java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ---java.lang.Thread.run(Thread.java:745)
> {code}
> See attached log.txt for more details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5456) Failback of standalone JMS client fails with http connector
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-5456?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-5456.
--------------------------------
Resolution: Won't Fix
> Failback of standalone JMS client fails with http connector
> -----------------------------------------------------------
>
> Key: WFLY-5456
> URL: https://issues.jboss.org/browse/WFLY-5456
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Critical
> Attachments: log.txt, servers.zip, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> Failback of standalone JMS client fails if http connector is used. There are 2 EAP 7.0.0.DR11 (Artemis 1.1.0) servers configured in dedicated topology with shared store.
> If live server is killed (clients failover) and then restarted (so failback occurs) then sometimes client does not failback to live server.
> From the thread dump of one client it seems that it's stuck on:
> {code}
> Stack trace of thread: Thread[Thread-16,5,main]
> Stack trace of thread: Thread[Thread-2 (ActiveMQ-client-global-threads-1995983824),5,ActiveMQ-client-global-threads-1995983824]
> ---sun.misc.Unsafe.park(Native Method)
> ---java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> ---java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> ---java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> ---java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> ---org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.waitOnLatch(ActiveMQClientProtocolManager.java:130)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:770)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:694)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:558)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:461)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$400(ClientSessionFactoryImpl.java:68)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1120)
> ---org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:57)
> ---org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:204)
> ---org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:179)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:946)
> ---org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:94)
> ---java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ---java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ---java.lang.Thread.run(Thread.java:745)
> {code}
> See attached log.txt for more details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5456) Failback of standalone JMS client fails with http connector
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-5456?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-5456.
--------------------------------
Resolution: Done
Attribute failback-delay set to 1s caused that live did not have enough time to start. After setting default value 5s clients failed back.
> Failback of standalone JMS client fails with http connector
> -----------------------------------------------------------
>
> Key: WFLY-5456
> URL: https://issues.jboss.org/browse/WFLY-5456
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Critical
> Attachments: log.txt, servers.zip, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> Failback of standalone JMS client fails if http connector is used. There are 2 EAP 7.0.0.DR11 (Artemis 1.1.0) servers configured in dedicated topology with shared store.
> If live server is killed (clients failover) and then restarted (so failback occurs) then sometimes client does not failback to live server.
> From the thread dump of one client it seems that it's stuck on:
> {code}
> Stack trace of thread: Thread[Thread-16,5,main]
> Stack trace of thread: Thread[Thread-2 (ActiveMQ-client-global-threads-1995983824),5,ActiveMQ-client-global-threads-1995983824]
> ---sun.misc.Unsafe.park(Native Method)
> ---java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> ---java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> ---java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> ---java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> ---org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.waitOnLatch(ActiveMQClientProtocolManager.java:130)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:770)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:694)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:558)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:461)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$400(ClientSessionFactoryImpl.java:68)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1120)
> ---org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:57)
> ---org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:204)
> ---org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:179)
> ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:946)
> ---org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:94)
> ---java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ---java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ---java.lang.Thread.run(Thread.java:745)
> {code}
> See attached log.txt for more details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5400) Failover of standalone JMS client fails with netty (blocking/non-blocking) connector
by ANGELA ROBERTSON (JIRA)
[ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.... ]
ANGELA ROBERTSON reassigned WFLY-5400:
--------------------------------------
Assignee: Andrea Hoffer (was: ANGELA ROBERTSON)
> Failover of standalone JMS client fails with netty (blocking/non-blocking) connector
> ------------------------------------------------------------------------------------
>
> Key: WFLY-5400
> URL: https://issues.jboss.org/browse/WFLY-5400
> Project: WildFly
> Issue Type: Bug
> Components: Documentation, JMS
> Affects Versions: 10.0.0.CR1
> Reporter: Miroslav Novak
> Assignee: Andrea Hoffer
> Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml
>
>
> Failover of standalone JMS client fails if netty (blocking/non-blocking) connector is used. There are 2 EAP 7.0.0.DR10 (Artemis 1.1.0) servers configured in dedicated topology with shared store.
> If live server is killed then backup activates but client does not failover to it:
> {code}
> ent message with property count: 110867, messageId:ID:20310150-62a0-11e5-ada8-b3332c72af23
> Sent message with property count: 110868, messageId:ID:20310151-62a0-11e5-ada8-b3332c72af23
> Sep 24, 2015 11:39:27 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:39:40 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:39:55 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:40:10 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> {code}
> Attaching live/backup configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5474) exploded jsp is not deployed after server reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5474?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-5474:
--------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> exploded jsp is not deployed after server reload
> ------------------------------------------------
>
> Key: WFLY-5474
> URL: https://issues.jboss.org/browse/WFLY-5474
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.0.0.CR2
> Reporter: Jan Stourac
> Assignee: ehsavoie Hugonnet
> Attachments: simple-jsp.war
>
>
> When I deploy exploded jsp on EAP server via marker file, undeploy it and again redeploy it via cli, then perform server reload, after those steps particular jsp is not available anymore.
> For more info see "Steps to Reproduce" section.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5474) exploded jsp is not deployed after server reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5474?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-5474:
----------------------------------------
This almost certainly is not a critical bug.
You need to choose how you want to manage your deployment -- via the scanner or manually via the CLI. Switching from one to the other is something where we try our best to let the scanner figure out what you've done manually and keep up, but it's really a best effort. If you are using the scanner for your deployment, stick to the scanner.
I suspect what happens here is the deployment is still owned by the scanner, since :undeploy / : deploy doesn't remove/re-add the deployment. Then the scanner's attempts to track what happens with the deployment get lost after the :undeploy. The effect is when you reload, the deployment is owned by the scanner but the scanner considers it undeployed and doesn't deploy it.
> exploded jsp is not deployed after server reload
> ------------------------------------------------
>
> Key: WFLY-5474
> URL: https://issues.jboss.org/browse/WFLY-5474
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.0.0.CR2
> Reporter: Jan Stourac
> Assignee: Brian Stansberry
> Priority: Critical
> Attachments: simple-jsp.war
>
>
> When I deploy exploded jsp on EAP server via marker file, undeploy it and again redeploy it via cli, then perform server reload, after those steps particular jsp is not available anymore.
> For more info see "Steps to Reproduce" section.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5235) CDI interceptors are not called when invoking private observer method
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-5235?page=com.atlassian.jira.plugin.... ]
Martin Kouba updated WFLY-5235:
-------------------------------
Summary: CDI interceptors are not called when invoking private observer method (was: CDI interceptors are not called when invoking observer method)
> CDI interceptors are not called when invoking private observer method
> ---------------------------------------------------------------------
>
> Key: WFLY-5235
> URL: https://issues.jboss.org/browse/WFLY-5235
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 9.0.1.Final
> Reporter: Dirk Weil
> Assignee: Martin Kouba
>
> The following code runs with an active transaction on WFLY 8.2.0, but failes with an TransactionRequiredException on WFLY 9.0.1:
> @ApplicationScoped
> public class InitCocktailDemoDataService
> {
> @PersistenceContext
> private EntityManager entityManager;
> @Transactional
> private void createDemoData(@Observes @Initialized(ApplicationScoped.class) Object event)
> {
> this.entityManager.merge(someEntity);
> }
> It seems that interceptors aren't called at all - at least for observers of scope lifecycle events.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months