[JBoss JIRA] (WFWIP-83) [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFWIP-83?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil commented on WFWIP-83:
----------------------------------
[~martyn-taylor] Indeed that's quite a change from the previous Artemis behaviour... I don't understand how it is compatible with Artemis Resource Adapter that provides a pool of connections. All these connections are with the same clientID.
Where is the text in the spec that triggered this change?
> [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-83
> URL: https://issues.jboss.org/browse/WFWIP-83
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> There is regression TCK 7 when running WF/EAP with Artemis 2.x resource adapter against AMQ 7.2.0.GA. WF/EAP with Artemis 2.x is last build from [2018-08-06]:
> https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-...
> There are approximately 200 failures with exception:
> {code}
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) 08-03-2018 09:55:10: SVR-ERROR: javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.validateClientID(ActiveMQConnection.java:266)
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:681)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:849)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXATopicConnection(ActiveMQConnectionFactory.java:387)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:745)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:161)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:151)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(Semaphor
> eConcurrentLinkedDequeManagedConnectionPool.java:1326)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinke
> dDequeManagedConnectionPool.java:499)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
> [javatest.batch] ESC[0mESC[0m09:55:10,606 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:872)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:531)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:746)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:751)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:475)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createTopicConnection(ActiveMQRAConnectionFactoryImpl.java:217)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.testInitForT(TransactionTests.java:354)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.Test06(TransactionTests.java:634)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.EETest.run(EETest.java:550)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.tests.common.vehicle.ejb.EJBVehicle.runTest(EJBVehicle.java:70)
> {code}
> Note that TCK 7 is passing when trying with current Wildfly master (Artemis 1.5.5.012).
> Link to TCK 7 job:
> https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-third-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-93) Critical IO Error ... when starting Artemis with HA JDBC store
by Peter Mačkay (JIRA)
Peter Mačkay created WFWIP-93:
---------------------------------
Summary: Critical IO Error ... when starting Artemis with HA JDBC store
Key: WFWIP-93
URL: https://issues.jboss.org/browse/WFWIP-93
Project: WildFly WIP
Issue Type: Bug
Components: Artemis, JMS
Reporter: Peter Mačkay
Assignee: Martyn Taylor
Priority: Blocker
One of the servers in collocated HA topology with JDBC store can fail on critical IO exception and stop itself.
This was hit on Artemis 1.5.5.012 and WF: https://github.com/jmesnil/wildfly - WFLY-9513_messaging_jdbc_HA_shared-store branch.
Test scenario:
* Start 2 WF/EAP servers in collocated topology with Artemis HA JDBC store
* Start client which are sending and consuming messages to/from queue from 1st server
Result:
There is intermittent failure when client start to send/receive messages on 1st server. 1st fails on Critical IO Error with exception:
{code}
10:19:27,965 WARN [org.apache.activemq.artemis.journal] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7de7cbe3)) AMQ142021: Error on IO callback, null
10:19:27,965 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7de7cbe3)) AMQ222010: Critical IO Error, shutting down the server. file=org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile@407c5d8f, message=Error writing to JDBC file.: java.lang.NullPointerException
at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.internalWrite(JDBCSequentialFile.java:161) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.internalWrite(JDBCSequentialFile.java:186) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.lambda$scheduleWrite$1(JDBCSequentialFile.java:197) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
{code}
NPE happens at {{JDBCSequentialFile.internalWrite}} line 161:
{code}
private synchronized int internalWrite(byte[] data, IOCallback callback) {
try {
open();
161 synchronized (writeLock) { <-- NPE is thrown here
...
{code}
.
Attaching logs from the test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2870) [DMN Designer] Can not build project with multiple models
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2870?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2870:
----------------------------------------
[~jomarko] OK, so this is an issue with our editor..
I need to expose some properties on {{DMNDiagram.Definitions}} that include the name of the model.
I'd propose the model name defaults to the file name of the asset in the workbench (and is perhaps read-only in the Properties Panel). Renaming the file should also rename the DMN model (so I'd need a {{org.uberfire.ext.editor.commons.backend.service.helper.RenameHelper}} implementation for DMN files).
[~tirelli] Can you advise what properties in {{DMNDiagram.Definitions}} have to be exposed in the Editor (IDK, minimal set for now?)
> [DMN Designer] Can not build project with multiple models
> ---------------------------------------------------------
>
> Key: DROOLS-2870
> URL: https://issues.jboss.org/browse/DROOLS-2870
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.10.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2018-08-09 10-20-16.png
>
>
> If the project contains multiple dmn models, it can not be built.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10814) Clustered singleton MDB doesn't get activated after master node is shutdown
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10814?page=com.atlassian.jira.plugin... ]
Erich Duda updated WFLY-10814:
------------------------------
Description:
*Scenario*
* There are two Wildfly servers configured in cluster
* Both servers have deployment with clustered singleton MDB
* Start both servers
* Check that MDB is active only on one server
* Shutdown server with active MDB
* Check that MDB get activated on the second server.
Sometimes happens that MDB doesn't get activated on the second server. The test waits 60 seconds for it. Always when this issue happens, I can see following exception in the log of the second server which is logged after the first server is shutdown.
The issue was hit with WildFly master built on 9th August (6675410).
*Blocker* priority was set because it is regression against WF 13.
{code}
09:12:45,274 WARN [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0012: Failed to notify server/default service provider registration listener of new providers: [node-2]: java.util.con
current.CompletionException: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size =
0, active threads = 0, queued tasks = 0, completed tasks = 2]
at java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375) [rt.jar:1.8.0_171]
at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934) [rt.jar:1.8.0_171]
at org.jgroups.blocks.UnicastRequest.lambda$join$0(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.UnicastRequest.around(UnicastRequest.java:137) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.UnicastRequest.join(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.wildfly.clustering.server.singleton.AbstractDistributedSingletonService.providersChanged(AbstractDistributedSingletonService.java:121) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.B
eta2-SNAPSHOT]
at org.wildfly.clustering.server.provider.CacheServiceProviderRegistry.lambda$modified$5(CacheServiceProviderRegistry.java:285) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size = 0, active threads
= 0, queued tasks = 0, completed tasks = 2]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) [rt.jar:1.8.0_171]
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) [rt.jar:1.8.0_171]
at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.handle(ChannelCommandDispatcherFactory.java:143) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:383) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:356) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:307) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:582) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.JChannel.up(JChannel.java:816) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:893) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FORK.up(FORK.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FRAG3.up(FRAG3.java:171) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:351) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:359) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:873) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:375) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:253) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.MERGE3.up(MERGE3.java:280) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.Discovery.up(Discovery.java:269) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1248) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
{code}
was:
*Scenario*
* There are two Wildfly servers configured in cluster
* Both servers have deployment with clustered singleton MDB
* Start both servers
* Check that MDB is active only on one server
* Shutdown server with active MDB
* Check that MDB get activated on the second server.
Sometimes happens that MDB doesn't get activated on the second server. The test waits 60 seconds for it. Always when this issue happens, I can see following exception in the log of the second server which is logged after the first server is shutdown.
The issue was hit with WildFly master built on 9th August (6675410).
*Blocker* priority was set because it is regression against WF 13.
{code}
current.CompletionException: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size =
0, active threads = 0, queued tasks = 0, completed tasks = 2]
at java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375) [rt.jar:1.8.0_171]
at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934) [rt.jar:1.8.0_171]
at org.jgroups.blocks.UnicastRequest.lambda$join$0(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.UnicastRequest.around(UnicastRequest.java:137) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.UnicastRequest.join(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.wildfly.clustering.server.singleton.AbstractDistributedSingletonService.providersChanged(AbstractDistributedSingletonService.java:121) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.B
eta2-SNAPSHOT]
at org.wildfly.clustering.server.provider.CacheServiceProviderRegistry.lambda$modified$5(CacheServiceProviderRegistry.java:285) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size = 0, active threads
= 0, queued tasks = 0, completed tasks = 2]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) [rt.jar:1.8.0_171]
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) [rt.jar:1.8.0_171]
at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.handle(ChannelCommandDispatcherFactory.java:143) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:383) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:356) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:307) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:582) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.JChannel.up(JChannel.java:816) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:893) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FORK.up(FORK.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FRAG3.up(FRAG3.java:171) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:351) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:359) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:873) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:375) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:253) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.MERGE3.up(MERGE3.java:280) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.Discovery.up(Discovery.java:269) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1248) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
{code}
> Clustered singleton MDB doesn't get activated after master node is shutdown
> ---------------------------------------------------------------------------
>
> Key: WFLY-10814
> URL: https://issues.jboss.org/browse/WFLY-10814
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.CR1
> Reporter: Erich Duda
> Assignee: Paul Ferraro
> Priority: Blocker
>
> *Scenario*
> * There are two Wildfly servers configured in cluster
> * Both servers have deployment with clustered singleton MDB
> * Start both servers
> * Check that MDB is active only on one server
> * Shutdown server with active MDB
> * Check that MDB get activated on the second server.
> Sometimes happens that MDB doesn't get activated on the second server. The test waits 60 seconds for it. Always when this issue happens, I can see following exception in the log of the second server which is logged after the first server is shutdown.
> The issue was hit with WildFly master built on 9th August (6675410).
> *Blocker* priority was set because it is regression against WF 13.
> {code}
> 09:12:45,274 WARN [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0012: Failed to notify server/default service provider registration listener of new providers: [node-2]: java.util.con
> current.CompletionException: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size =
> 0, active threads = 0, queued tasks = 0, completed tasks = 2]
> at java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375) [rt.jar:1.8.0_171]
> at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934) [rt.jar:1.8.0_171]
> at org.jgroups.blocks.UnicastRequest.lambda$join$0(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.UnicastRequest.around(UnicastRequest.java:137) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.UnicastRequest.join(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.wildfly.clustering.server.singleton.AbstractDistributedSingletonService.providersChanged(AbstractDistributedSingletonService.java:121) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.B
> eta2-SNAPSHOT]
> at org.wildfly.clustering.server.provider.CacheServiceProviderRegistry.lambda$modified$5(CacheServiceProviderRegistry.java:285) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size = 0, active threads
> = 0, queued tasks = 0, completed tasks = 2]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) [rt.jar:1.8.0_171]
> at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) [rt.jar:1.8.0_171]
> at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.handle(ChannelCommandDispatcherFactory.java:143) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:383) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:356) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:307) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:582) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.JChannel.up(JChannel.java:816) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:893) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FORK.up(FORK.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FRAG3.up(FRAG3.java:171) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:351) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:359) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:873) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:375) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:253) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:280) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.Discovery.up(Discovery.java:269) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1248) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10814) Clustered singleton MDB doesn't get activated after master node is shutdown
by Erich Duda (JIRA)
Erich Duda created WFLY-10814:
---------------------------------
Summary: Clustered singleton MDB doesn't get activated after master node is shutdown
Key: WFLY-10814
URL: https://issues.jboss.org/browse/WFLY-10814
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 14.0.0.CR1
Reporter: Erich Duda
Assignee: Paul Ferraro
Priority: Blocker
*Scenario*
* There are two Wildfly servers configured in cluster
* Both servers have deployment with clustered singleton MDB
* Start both servers
* Check that MDB is active only on one server
* Shutdown server with active MDB
* Check that MDB get activated on the second server.
Sometimes happens that MDB doesn't get activated on the second server. The test waits 60 seconds for it. Always when this issue happens, I can see following exception in the log of the second server which is logged after the first server is shutdown.
The issue was hit with WildFly master built on 9th August (6675410).
*Blocker* priority was set because it is regression against WF 13.
{code}
current.CompletionException: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size =
0, active threads = 0, queued tasks = 0, completed tasks = 2]
at java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375) [rt.jar:1.8.0_171]
at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934) [rt.jar:1.8.0_171]
at org.jgroups.blocks.UnicastRequest.lambda$join$0(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.UnicastRequest.around(UnicastRequest.java:137) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.UnicastRequest.join(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.wildfly.clustering.server.singleton.AbstractDistributedSingletonService.providersChanged(AbstractDistributedSingletonService.java:121) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.B
eta2-SNAPSHOT]
at org.wildfly.clustering.server.provider.CacheServiceProviderRegistry.lambda$modified$5(CacheServiceProviderRegistry.java:285) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size = 0, active threads
= 0, queued tasks = 0, completed tasks = 2]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) [rt.jar:1.8.0_171]
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) [rt.jar:1.8.0_171]
at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.handle(ChannelCommandDispatcherFactory.java:143) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:383) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:356) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:307) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:582) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.JChannel.up(JChannel.java:816) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:893) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FORK.up(FORK.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FRAG3.up(FRAG3.java:171) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:351) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:359) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:873) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:375) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:253) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.MERGE3.up(MERGE3.java:280) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.Discovery.up(Discovery.java:269) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1248) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.13.Final.jar:4.0.13.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-83) [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/WFWIP-83?page=com.atlassian.jira.plugin.s... ]
Yong Hao Gao commented on WFWIP-83:
-----------------------------------
[~martyn-taylor][~mnovak] btw I found when the process ends there is one or two java process stay in background and I have to kill -9 them. That leads me to some thought that the error may be caused by previous test not cleaning up well. But just a thought, no proof yet.
Howard
> [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-83
> URL: https://issues.jboss.org/browse/WFWIP-83
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> There is regression TCK 7 when running WF/EAP with Artemis 2.x resource adapter against AMQ 7.2.0.GA. WF/EAP with Artemis 2.x is last build from [2018-08-06]:
> https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-...
> There are approximately 200 failures with exception:
> {code}
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) 08-03-2018 09:55:10: SVR-ERROR: javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.validateClientID(ActiveMQConnection.java:266)
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:681)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:849)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXATopicConnection(ActiveMQConnectionFactory.java:387)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:745)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:161)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:151)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(Semaphor
> eConcurrentLinkedDequeManagedConnectionPool.java:1326)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinke
> dDequeManagedConnectionPool.java:499)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
> [javatest.batch] ESC[0mESC[0m09:55:10,606 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:872)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:531)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:746)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:751)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:475)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createTopicConnection(ActiveMQRAConnectionFactoryImpl.java:217)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.testInitForT(TransactionTests.java:354)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.Test06(TransactionTests.java:634)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.EETest.run(EETest.java:550)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.tests.common.vehicle.ejb.EJBVehicle.runTest(EJBVehicle.java:70)
> {code}
> Note that TCK 7 is passing when trying with current Wildfly master (Artemis 1.5.5.012).
> Link to TCK 7 job:
> https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-third-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-83) [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFWIP-83?page=com.atlassian.jira.plugin.s... ]
Martyn Taylor commented on WFWIP-83:
------------------------------------
[~jmesnil] Jeff, it looks like this might be caused by using pooled connection factory size > 1 with client id set. We fixed an issue in Artemis that was breaking spec, the client ID must be unique for every* connection. Artemis now throws an InvalidClientId exception when a new connection attempt is made with a Client ID that already exists. I've ask [~mnovak] to set the pool size to 1 with the TCK but it looks like this is causing more issues. Any ideas?
> [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-83
> URL: https://issues.jboss.org/browse/WFWIP-83
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> There is regression TCK 7 when running WF/EAP with Artemis 2.x resource adapter against AMQ 7.2.0.GA. WF/EAP with Artemis 2.x is last build from [2018-08-06]:
> https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-...
> There are approximately 200 failures with exception:
> {code}
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) 08-03-2018 09:55:10: SVR-ERROR: javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.validateClientID(ActiveMQConnection.java:266)
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:681)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:849)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXATopicConnection(ActiveMQConnectionFactory.java:387)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:745)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:161)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:151)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(Semaphor
> eConcurrentLinkedDequeManagedConnectionPool.java:1326)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinke
> dDequeManagedConnectionPool.java:499)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
> [javatest.batch] ESC[0mESC[0m09:55:10,606 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:872)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:531)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:746)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:751)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:475)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createTopicConnection(ActiveMQRAConnectionFactoryImpl.java:217)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.testInitForT(TransactionTests.java:354)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.Test06(TransactionTests.java:634)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.EETest.run(EETest.java:550)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.tests.common.vehicle.ejb.EJBVehicle.runTest(EJBVehicle.java:70)
> {code}
> Note that TCK 7 is passing when trying with current Wildfly master (Artemis 1.5.5.012).
> Link to TCK 7 job:
> https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-third-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-83) [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/WFWIP-83?page=com.atlassian.jira.plugin.s... ]
Yong Hao Gao commented on WFWIP-83:
-----------------------------------
[~mnovak] Hi, I tried from the top again but got the same error. However this time I use the same terminal as before. Maybe the env has already been contaminated. I'll start a fresh new terminal and try again.
Thanks.
> [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-83
> URL: https://issues.jboss.org/browse/WFWIP-83
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> There is regression TCK 7 when running WF/EAP with Artemis 2.x resource adapter against AMQ 7.2.0.GA. WF/EAP with Artemis 2.x is last build from [2018-08-06]:
> https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-...
> There are approximately 200 failures with exception:
> {code}
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) 08-03-2018 09:55:10: SVR-ERROR: javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.validateClientID(ActiveMQConnection.java:266)
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:681)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:849)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXATopicConnection(ActiveMQConnectionFactory.java:387)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:745)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:161)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:151)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(Semaphor
> eConcurrentLinkedDequeManagedConnectionPool.java:1326)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinke
> dDequeManagedConnectionPool.java:499)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
> [javatest.batch] ESC[0mESC[0m09:55:10,606 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:872)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:531)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:746)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:751)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:475)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createTopicConnection(ActiveMQRAConnectionFactoryImpl.java:217)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.testInitForT(TransactionTests.java:354)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.Test06(TransactionTests.java:634)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.EETest.run(EETest.java:550)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.tests.common.vehicle.ejb.EJBVehicle.runTest(EJBVehicle.java:70)
> {code}
> Note that TCK 7 is passing when trying with current Wildfly master (Artemis 1.5.5.012).
> Link to TCK 7 job:
> https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-third-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2792) [DMN Designer] Data-types: Grid: LiteralExpression
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2792?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2792:
-----------------------------------
Description:
*_Literal Expression_*
- (/) Grid header _could_ show Output Data Type
- (/) Editing Output Data Type is possible via Properties panel
- (/) Update header when Output Data Type is changed via Properties panel
h3. Manual acceptance test
- Resizing (/)
- Ctrl+C, Ctrl+v (/)
- Default Data Type for literal expression (/)
- Selecting itemDefinition (/)
- Long name of data type (?)
-- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
-- [manstis] We could resize the column based on the Data Type name; feel free to open a (minor) JIRA and [~tirelli] can comment.
- Used in levels of context grid (?)
-- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
-- Should be the data type shown anytime or just if literal expression is top level context entry?
-- [manstis] For {{LiteralExpression}} only when top-level. {{ContextEntry}} will have a similar editor when https://issues.jboss.org/browse/DROOLS-2796 is complete.
- Changing data type in graph node (/)
- Changing data type in properties panel (/)
- Building project (?)
-- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
-- [manstis] Validation will be performed when saved/validated and errors appear in the Message Console. How validation is supported is, IIRC, a JIRA somewhere already.
- Undo / Redo
was:
*_Literal Expression_*
- (/) Grid header _could_ show Output Data Type
- (/) Editing Output Data Type is possible via Properties panel
- (/) Update header when Output Data Type is changed via Properties panel
h3. Manual acceptance test
- Resizing (/)
- Ctrl+C, Ctrl+v (/)
- Default Data Type for literal expression (/)
- Selecting itemDefinition (/)
- Long name of data type (?)
-- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
- Used in levels of context grid (?)
-- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
-- Should be the data type shown anytime or just if literal expression is top level context entry?
- Changing data type in graph node (/)
- Changing data type in properties panel (/)
- Building project (?)
-- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
- Undo / Redo
> [DMN Designer] Data-types: Grid: LiteralExpression
> --------------------------------------------------
>
> Key: DROOLS-2792
> URL: https://issues.jboss.org/browse/DROOLS-2792
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Attachments: DROOLS-2792.odt, Screen Shot 2018-08-01 at 10.11.48 AM.png, Screen Shot 2018-08-01 at 10.20.35 AM.png, Screenshot from 2018-08-09 09-21-01.png
>
>
> *_Literal Expression_*
> - (/) Grid header _could_ show Output Data Type
> - (/) Editing Output Data Type is possible via Properties panel
> - (/) Update header when Output Data Type is changed via Properties panel
> h3. Manual acceptance test
> - Resizing (/)
> - Ctrl+C, Ctrl+v (/)
> - Default Data Type for literal expression (/)
> - Selecting itemDefinition (/)
> - Long name of data type (?)
> -- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
> -- [manstis] We could resize the column based on the Data Type name; feel free to open a (minor) JIRA and [~tirelli] can comment.
> - Used in levels of context grid (?)
> -- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
> -- Should be the data type shown anytime or just if literal expression is top level context entry?
> -- [manstis] For {{LiteralExpression}} only when top-level. {{ContextEntry}} will have a similar editor when https://issues.jboss.org/browse/DROOLS-2796 is complete.
> - Changing data type in graph node (/)
> - Changing data type in properties panel (/)
> - Building project (?)
> -- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
> -- [manstis] Validation will be performed when saved/validated and errors appear in the Message Console. How validation is supported is, IIRC, a JIRA somewhere already.
> - Undo / Redo
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2792) [DMN Designer] Data-types: Grid: LiteralExpression
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2792?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2792:
-----------------------------------
Description:
*_Literal Expression_*
- (/) Grid header _could_ show Output Data Type
- (/) Editing Output Data Type is possible via Properties panel
- (/) Update header when Output Data Type is changed via Properties panel
h3. Manual acceptance test
- Resizing (/)
- Ctrl+C, Ctrl+v (/)
- Default Data Type for literal expression (/)
- Selecting itemDefinition (/)
- Long name of data type (?)
-- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
- Used in levels of context grid (?)
-- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
-- Should be the data type shown anytime or just if literal expression is top level context entry?
- Changing data type in graph node (/)
- Changing data type in properties panel (/)
- Building project (?)
-- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
- Undo / Redo
was:
*_Literal Expression_*
- (x) Grid header _could_ show Output Data Type
- (/) Editing Output Data Type is possible via Properties panel
- (x) Update header when Output Data Type is changed via Properties panel
h3. Manual acceptance test
- Resizing (/)
- Ctrl+C, Ctrl+v (/)
- Default Data Type for literal expression (/)
- Selecting itemDefinition (/)
- Long name of data type (?)
-- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
- Used in levels of context grid (?)
-- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
-- Should be the data type shown anytime or just if literal expression is top level context entry?
- Changing data type in graph node (/)
- Changing data type in properties panel (/)
- Building project (?)
-- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
- Undo / Redo
> [DMN Designer] Data-types: Grid: LiteralExpression
> --------------------------------------------------
>
> Key: DROOLS-2792
> URL: https://issues.jboss.org/browse/DROOLS-2792
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Attachments: DROOLS-2792.odt, Screen Shot 2018-08-01 at 10.11.48 AM.png, Screen Shot 2018-08-01 at 10.20.35 AM.png, Screenshot from 2018-08-09 09-21-01.png
>
>
> *_Literal Expression_*
> - (/) Grid header _could_ show Output Data Type
> - (/) Editing Output Data Type is possible via Properties panel
> - (/) Update header when Output Data Type is changed via Properties panel
> h3. Manual acceptance test
> - Resizing (/)
> - Ctrl+C, Ctrl+v (/)
> - Default Data Type for literal expression (/)
> - Selecting itemDefinition (/)
> - Long name of data type (?)
> -- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
> - Used in levels of context grid (?)
> -- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
> -- Should be the data type shown anytime or just if literal expression is top level context entry?
> - Changing data type in graph node (/)
> - Changing data type in properties panel (/)
> - Building project (?)
> -- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
> - Undo / Redo
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months