[JBoss JIRA] (WFLY-13262) Enforcer conflict in wildfly-microprofile-health-smallrye
by Szymon Klepacz (Jira)
Szymon Klepacz created WFLY-13262:
-------------------------------------
Summary: Enforcer conflict in wildfly-microprofile-health-smallrye
Key: WFLY-13262
URL: https://issues.redhat.com/browse/WFLY-13262
Project: WildFly
Issue Type: Component Upgrade
Components: MP Health
Affects Versions: 19.0.0.Final
Reporter: Szymon Klepacz
Assignee: Jeff Mesnil
Enforcer conflict for MP health:
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-microprofile-health-smallrye</artifactId>
<version>19.0.0.Final</version>
</dependency>
+-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+-org.wildfly:wildfly-microprofile-health-smallrye:19.0.0.Final
+-org.wildfly:wildfly-undertow:19.0.0.Final
+-io.undertow:undertow-servlet:2.0.30.Final
and
+-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+-org.wildfly:wildfly-microprofile-health-smallrye:19.0.0.Final
+-org.wildfly:wildfly-undertow:19.0.0.Final
+-io.undertow:undertow-websockets-jsr:2.0.30.Final
+-io.undertow:undertow-servlet:2.0.30.Final
and
+-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+-org.wildfly:wildfly-microprofile-health-smallrye:19.0.0.Final
+-org.wildfly:wildfly-undertow:19.0.0.Final
+-io.undertow.jastow:jastow:2.0.8.Final
+-io.undertow:undertow-servlet:1.2.6.Final
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13253) CommandDispatcher cannot optimize marshalling of user commands
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-13253?page=com.atlassian.jira.plugi... ]
Parul Sharma commented on WFLY-13253:
-------------------------------------
Hi [~pferraro],
Are you working on this? And also can you please let me know the reproducer?
Thanks,
Parul Sharma
> CommandDispatcher cannot optimize marshalling of user commands
> --------------------------------------------------------------
>
> Key: WFLY-13253
> URL: https://issues.redhat.com/browse/WFLY-13253
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 19.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Currently, all CommandDispatcher instances created from a given CommandDispatcherFactory share a single marshaller. This means that the marshaller used by WF for its internal commands is the same as the one used to marshal user commands. This limits the extent to which commands may optimize their marshalling, or indeed, use a different marshaller (e.g. ProtoStream).
> We can remove the limitations above by using a distinct mashaller for each CommandDispatcher.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-10137) EJB lookup over HTTP fails if object is used in the signiture
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-10137?page=com.atlassian.jira.plugi... ]
Parul Sharma commented on WFLY-10137:
-------------------------------------
Hi [~crazycradd],
Can you please let me know the reproducer?
Thanks,
Parul Sharma
> EJB lookup over HTTP fails if object is used in the signiture
> -------------------------------------------------------------
>
> Key: WFLY-10137
> URL: https://issues.redhat.com/browse/WFLY-10137
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 11.0.0.Final
> Reporter: peter craddock
> Priority: Major
>
> I have a swing client that makes calls to the EJB tier via RMI the majority of the calls work fine using the workaround from WFLY-9636.
> The following calls was failing when connected over HTTP but was fine when using the original TCP connection
> public EntityList getAllWorkingSetsForCube( ModelRef modelRef, FinanceCubeRef financeCubeRef, int userId, Integer[] allowedStates )
> I worked round this and found that creating a method without the Integer[] as part of the signature works.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-10137) EJB lookup over HTTP fails if object is used in the signiture
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-10137?page=com.atlassian.jira.plugi... ]
Parul Sharma reassigned WFLY-10137:
-----------------------------------
Assignee: Parul Sharma
> EJB lookup over HTTP fails if object is used in the signiture
> -------------------------------------------------------------
>
> Key: WFLY-10137
> URL: https://issues.redhat.com/browse/WFLY-10137
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 11.0.0.Final
> Reporter: peter craddock
> Assignee: Parul Sharma
> Priority: Major
>
> I have a swing client that makes calls to the EJB tier via RMI the majority of the calls work fine using the workaround from WFLY-9636.
> The following calls was failing when connected over HTTP but was fine when using the original TCP connection
> public EntityList getAllWorkingSetsForCube( ModelRef modelRef, FinanceCubeRef financeCubeRef, int userId, Integer[] allowedStates )
> I worked round this and found that creating a method without the Integer[] as part of the signature works.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-10886) Poor JMS message sending throughput with remote broker and XA transactions
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-10886?page=com.atlassian.jira.plugi... ]
Parul Sharma commented on WFLY-10886:
-------------------------------------
Hi [~jarek.przygodzki],
Can you please let me know how to reproduce this issue?
Thanks,
Parul Sharma
> Poor JMS message sending throughput with remote broker and XA transactions
> --------------------------------------------------------------------------
>
> Key: WFLY-10886
> URL: https://issues.redhat.com/browse/WFLY-10886
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 10.1.0.Final
> Reporter: Jarek Przygódzki
> Priority: Major
> Labels: JMS
>
> JMS message sending throughput with remote broker and XA transactions is throttled. It happens because creation of InjectedJMSContext is synchronized on lock held for significant amount of time (transaction enlistment).
> {noformat}
> "EE-ManagedThreadFactory-default-Thread-9" #437 daemon prio=5 os_prio=0 tid=0x00007f2568250b70 nid=0x303 waiting on condition [0x00007f2540675000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000008a1d43d8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:376)
> - locked <0x000000008a1d4418> (a java.lang.Object)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:304)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaStart(ActiveMQSessionContext.java:503)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.start(ClientSessionImpl.java:1372)
> at org.apache.activemq.artemis.ra.ActiveMQRAXAResource.start(ActiveMQRAXAResource.java:90)
> at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.start(ActiveMQXAResourceWrapperImpl.java:121)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:662)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:423)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:986)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:379)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:553)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:928)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:750)
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> - locked <0x00000000f25b9738> (a java.util.HashSet)
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:739)
> at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:467)
> at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:420)
> at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:437)
> at org.wildfly.extension.messaging.activemq.deployment.injection.AbstractJMSContext.createContext(AbstractJMSContext.java:61)
> at org.wildfly.extension.messaging.activemq.deployment.injection.AbstractJMSContext.getContext(AbstractJMSContext.java:49)
> - locked <0x00000000f25b9378> (a org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext)
> at sun.reflect.GeneratedMethodAccessor721.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> at org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> - locked <0x0000000089fe0a70> (a org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy)
> at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
> "EE-ManagedThreadFactory-default-Thread-8" #391 daemon prio=5 os_prio=0 tid=0x00007f2648520df0 nid=0x2d5 waiting for monitor entry [0x00007f25446a4000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> - waiting to lock <0x0000000089fe0a70> (a org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy)
> at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
> "EE-ManagedThreadFactory-default-Thread-22" #466 daemon prio=5 os_prio=0 tid=0x00007f256c040710 nid=0x3d0 waiting for monitor entry [0x00007f2535852000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> - waiting to lock <0x0000000089fe0a70> (a org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy)
> at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
> "EE-ManagedThreadFactory-default-Thread-19" #463 daemon prio=5 os_prio=0 tid=0x00007f256c03c3f0 nid=0x3cd waiting for monitor entry [0x00007f2535b55000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> - waiting to lock <0x0000000089fe0a70> (a org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy)
> at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createProducer(JMSContextWrapper.java:66)
> "EE-ManagedThreadFactory-default-Thread-18" #462 daemon prio=5 os_prio=0 tid=0x00007f256c03aaf0 nid=0x3cc waiting for monitor entry [0x00007f2535c56000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> - waiting to lock <0x0000000089fe0a70> (a org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy)
> at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
> "EE-ManagedThreadFactory-default-Thread-14" #451 daemon prio=5 os_prio=0 tid=0x00007f264c02c920 nid=0x332 waiting for monitor entry [0x00007f253755e000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> - waiting to lock <0x0000000089fe0a70> (a org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy)
> at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
> "EE-ManagedThreadFactory-default-Thread-13" #450 daemon prio=5 os_prio=0 tid=0x00007f2648527070 nid=0x331 waiting for monitor entry [0x00007f2538660000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> - waiting to lock <0x0000000089fe0a70> (a org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy)
> at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4882) [GSS](7.2.z) CMTOOL-255 - Broken 'domain.xml' after migration of <host-scoped-roles> leading to 'Boostrap error' in HAL
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFCORE-4882?page=com.atlassian.jira.plug... ]
Chao Wang moved JBEAP-19006 to WFCORE-4882:
-------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-4882 (was: JBEAP-19006)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Management
Server
(was: Migration)
Affects Version/s: 11.0.0.Final
(was: 7.2.3.GA)
QE Test Coverage: (was: +)
Fix Version/s: (was: 7.2.9.GA)
> [GSS](7.2.z) CMTOOL-255 - Broken 'domain.xml' after migration of <host-scoped-roles> leading to 'Boostrap error' in HAL
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4882
> URL: https://issues.redhat.com/browse/WFCORE-4882
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Server
> Affects Versions: 11.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
>
> When migrating a domain configuration from JBoss EAP 7.1.6 having a broken {{<host-scoped-roles>}} configuration, the resulting {{domain.xml}} on EAP 7.2 is broken as well.
> JBoss EAP 7.1 is relaxed during accessing the HAL and simply ignores the broken configuration, whereas JBoss EAP 7.2 will not allow access to the HAL and report a *_Bootstrap error_*.
> The {{jboss-server-migration.[sh|bat]}} should identify this broken configuration and *deny* the migration of it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4882) [GSS](7.2.z) CMTOOL-255 - Broken 'domain.xml' after migration of <host-scoped-roles> leading to 'Boostrap error' in HAL
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFCORE-4882?page=com.atlassian.jira.plug... ]
Chao Wang updated WFCORE-4882:
------------------------------
> [GSS](7.2.z) CMTOOL-255 - Broken 'domain.xml' after migration of <host-scoped-roles> leading to 'Boostrap error' in HAL
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4882
> URL: https://issues.redhat.com/browse/WFCORE-4882
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Server
> Affects Versions: 11.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
>
> When migrating a domain configuration from JBoss EAP 7.1.6 having a broken {{<host-scoped-roles>}} configuration, the resulting {{domain.xml}} on EAP 7.2 is broken as well.
> JBoss EAP 7.1 is relaxed during accessing the HAL and simply ignores the broken configuration, whereas JBoss EAP 7.2 will not allow access to the HAL and report a *_Bootstrap error_*.
> The {{jboss-server-migration.[sh|bat]}} should identify this broken configuration and *deny* the migration of it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months