[JBoss JIRA] (DROOLS-2798) [DMN Designer] Data-types: Grid: Invocation
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2798?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2798:
--------------------------------
Description:
*_Invocation_*
- (/) Grid header _could_ show Output Data Type
- (/) Editing Output Data Type is possible via Properties panel
h3. Acceptance test
- Check infer report
- Check pit report
- Changes from grid
- Changes from prop. panel
- Reopening
was:
*_Invocation_*
- (/) Grid header _could_ show Output Data Type
- (/) Editing Output Data Type is possible via Properties panel
> [DMN Designer] Data-types: Grid: Invocation
> -------------------------------------------
>
> Key: DROOLS-2798
> URL: https://issues.jboss.org/browse/DROOLS-2798
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> *_Invocation_*
> - (/) Grid header _could_ show Output Data Type
> - (/) Editing Output Data Type is possible via Properties panel
> h3. Acceptance test
> - Check infer report
> - Check pit report
> - Changes from grid
> - Changes from prop. panel
> - Reopening
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10909) ConcurrentModificationException at ActivationSecurityUtil
by Richard Opalka (JIRA)
Richard Opalka created WFLY-10909:
-------------------------------------
Summary: ConcurrentModificationException at ActivationSecurityUtil
Key: WFLY-10909
URL: https://issues.jboss.org/browse/WFLY-10909
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Richard Opalka
Assignee: Stefano Maestri
Priority: Critical
Fix For: 14.0.0.CR1
org.jboss.as.test.smoke.deployment.rar.tests.multiactivation.MultipleActivationTestCase.testConfiguration: java.lang.AssertionError: CF1 not found
at org.jboss.as.test.smoke.deployment.rar.tests.multiactivation.MultipleActivationTestCase.testConfiguration(MultipleActivationTestCase.java:126)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1475)
at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258)
at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:246)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
------- Stdout: -------
[31m08:51:51,219 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.resourceadapters.ra."archive.rar".Pool2: org.jboss.msc.service.StartException in service jboss.resourceadapters.ra."archive.rar".Pool2: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1042)
at org.jboss.as.connector.metadata.api.resourceadapter.ActivationSecurityUtil.isLegacySecurityRequired(ActivationSecurityUtil.java:41)
at org.jboss.as.connector.subsystems.resourceadapters.ConnectionDefinitionService.start(ConnectionDefinitionService.java:68)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
... 6 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-119) [Artemis 2.x upgrade] Lost message in replicated HA scenario with MDB
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-119?page=com.atlassian.jira.plugin.... ]
Erich Duda commented on WFWIP-119:
----------------------------------
[~clebert.suconic] I've looked at \[1\] and \[2\].
\[1\] failed on "getCountOfMessagesOnQueue() failed for queue:OutQueue and container: node-1. Number of tries: 10". Boot of node-1 failed with an following exception. Do you know what could happen?
{code}
21:57:16,375 ERROR [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 80) AMQ224000: Failure in initialisation: java.lang.NullPointerException
at org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadPreparedTransactions(AbstractJournalStorageManager.java:1745) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadMessageJournal(AbstractJournalStorageManager.java:1181) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2620) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2375) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:116) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:535) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:474) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:206) [wildfly-messaging-activemq-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:65) [wildfly-messaging-activemq-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:100) [wildfly-messaging-activemq-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_181]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_181]
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_181]
at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
21:57:16,375 ERROR [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 80) AMQ224000: Failure in initialisation: java.lang.NullPointerException
at org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadPreparedTransactions(AbstractJournalStorageManager.java:1745) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPS
HOT]
at org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadMessageJournal(AbstractJournalStorageManager.java:1181) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2620) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2375) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:116) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:535) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:474) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:206) [wildfly-messaging-activemq-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:65) [wildfly-messaging-activemq-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:100) [wildfly-messaging-activemq-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_181]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_181]
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_181]
at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
21:57:16,377 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 80) MSC000001: Failed to start service jboss.messaging-activemq.default.jms.manager: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default.jms.manager: java.lang.NullPointerException
at org.wildfly.extension.messaging.activemq.jms.JMSService.lambda$doStart$0(JMSService.java:142) [wildfly-messaging-activemq-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivationFailureListeners(ActiveMQServerImpl.java:1919) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:127) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:535) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:474) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:206) [wildfly-messaging-activemq-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:65) [wildfly-messaging-activemq-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:100) [wildfly-messaging-activemq-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_181]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_181]
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_181]
at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
Caused by: java.lang.NullPointerException
at org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadPreparedTransactions(AbstractJournalStorageManager.java:1745) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadMessageJournal(AbstractJournalStorageManager.java:1181) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2620) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2375) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:116) [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
... 14 more
{code}
The \[2\] failed because of the issue you mentioned that receiver didn't receive messages from node-4. However it is not test issue but it is caused by bug in JGroups. I saw in different test that if JGroups are used, Artemis cluster is not formed sometimes. It is reported in WFWIP-90. I will re-run the job with Netty discovery. Here is the new run \[1\]. If you will run the test by yourself be sure that there is that there is {{-Dprepare.param.CLUSTER_TYPE=NETTY_DISCOVERY}} in {{ADDITIONAL_PARAMS}} field.
\[1\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
\[2\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
\[3\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
> [Artemis 2.x upgrade] Lost message in replicated HA scenario with MDB
> ---------------------------------------------------------------------
>
> Key: WFWIP-119
> URL: https://issues.jboss.org/browse/WFWIP-119
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Martyn Taylor
> Priority: Blocker
>
> *Scenario*
> * Start live/backup pair in replicated dedicated topology and start one more server which is in Artemis cluster with live.
> * Send messages to queue InQueue.
> * Start another server with MDB connected to cluster with live server which resend messages from InQueue to OutQueue.
> * Stop backup server and then live server.
> * Stop server which was in cluster with live server.
> * Start live server and server in cluster.
> * Start backup server.
> The test fails because one message get lost. It wasn't sent to OutQueue.
> Logs from failed test including traces you can find in \[1\].
> \[1\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (LOGMGR-201) SysLogHandler doesn't log null or empty message
by Vladyslav Baidak (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-201?page=com.atlassian.jira.plugin... ]
Vladyslav Baidak commented on LOGMGR-201:
-----------------------------------------
*Pull request:*
https://github.com/jboss-logging/jboss-logmanager/pull/193
> SysLogHandler doesn't log null or empty message
> -----------------------------------------------
>
> Key: LOGMGR-201
> URL: https://issues.jboss.org/browse/LOGMGR-201
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Affects Versions: 2.1.4.Final
> Reporter: Vladyslav Baidak
> Fix For: 2.1.5.Final
>
>
> For cases when message is *null* or *empty*, *SysLogHandler* doesn't publish event (there is a correspondent logic in _doPublish_ method)
> I expect even *null* or *empty* messages to be sent. Consider the following message logged to CONSOLE handler:
> {code:java}
> 21:21:27,562 ERROR [ch.mobi.jes.jaxrs.exception.converter.internal.mapper.AbstractThrowableMapper] (default task-1) null: java.lang.IllegalArgumentException
> at java.util.Optional.orElseThrow(Optional.java:290)
> at ch.mobi.apsbau.pdfservice.entity.guarantee.GuaranteeType.resolve(GuaranteeType.java:36)
> at ch.mobi.apsbau.pdfservice.mapper.guarantee.GuaranteeMapper.toGuaranteeType(GuaranteeMapper.java:43)
> at ch.mobi.apsbau.pdfservice.mapper.guarantee.GuaranteeMapperImpl.toDraftDtoInternal(GuaranteeMapperImpl.java:49)
> at ch.mobi.apsbau.pdfservice.mapper.guarantee.GuaranteeMapper.toDraft(GuaranteeMapper.java:28)
> at ch.mobi.apsbau.pdfservice.boundary.guarantee.GuaranteeResourceImpl.generateDraft(GuaranteeResourceImpl.java:35)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {code}
> As you can see from example above, the message is null and as a result the entire stacktrace is skipped and not published
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10876) Align jar file provided for MP OpenTracing into right modules
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-10876?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-10876:
--------------------------------------
[~juraci.costa] I've got it mostly done here https://github.com/wildfly/wildfly/compare/master...jamezp:WFLY-10876. However 2 tests fail.
{code}
[ERROR] Failures:
[ERROR] ResourceWithCDITestCase.tracedEndpointYieldsSpan:61 expected:<3> but was:<1>
[ERROR] ResourceWithCustomOperationNameBeanTestCase.customOperationName:64 expected:<3> but was:<1>
{code}
It looks like the {{MockSpan}} isn't being invoked for each method call in a {{@Traced}} class.
> Align jar file provided for MP OpenTracing into right modules
> -------------------------------------------------------------
>
> Key: WFLY-10876
> URL: https://issues.jboss.org/browse/WFLY-10876
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Critical
>
> With recent addition of MicroProfile OpenTracing implementation we currently have following set of jar files that are in the build to provide various MicroProfile features:
> {code}
> $ find modules | grep smallrye | grep jar$ | xargs ls -hl
> -rw-rw-r--. 1 jstourac jstourac 39K Aug 16 15:13 modules/system/layers/base/io/smallrye/config/main/smallrye-config-1.3.3.jar
> -rw-rw-r--. 1 jstourac jstourac 8.9K Aug 16 15:13 modules/system/layers/base/io/smallrye/health/main/smallrye-health-1.0.2.jar
> -rw-rw-r--. 1 jstourac jstourac 38K Aug 16 15:13 modules/system/layers/base/org/wildfly/extension/microprofile/config-smallrye/main/wildfly-microprofile-config-smallrye-14.0.0.CR1-SNAPSHOT.jar
> -rw-rw-r--. 1 jstourac jstourac 27K Aug 16 15:13 modules/system/layers/base/org/wildfly/extension/microprofile/health-smallrye/main/wildfly-microprofile-health-smallrye-14.0.0.CR1-SNAPSHOT.jar
> -rw-rw-r--. 1 jstourac jstourac 228K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/gson-2.8.2.jar
> -rw-rw-r--. 1 jstourac jstourac 123K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/jaeger-core-0.30.4.jar
> -rw-rw-r--. 1 jstourac jstourac 2.8M Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/jaeger-thrift-0.30.4.jar
> -rw-rw-r--. 1 jstourac jstourac 14K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-api-0.31.0.jar
> -rw-rw-r--. 1 jstourac jstourac 7.5K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-concurrent-0.1.0.jar
> -rw-rw-r--. 1 jstourac jstourac 41K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-jaxrs2-0.1.6.jar
> -rw-rw-r--. 1 jstourac jstourac 11K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-noop-0.31.0.jar
> -rw-rw-r--. 1 jstourac jstourac 7.4K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-tracerresolver-0.1.5.jar
> -rw-rw-r--. 1 jstourac jstourac 7.9K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-util-0.31.0.jar
> -rw-rw-r--. 1 jstourac jstourac 13K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-web-servlet-filter-0.1.0.jar
> -rw-rw-r--. 1 jstourac jstourac 5.4K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/smallrye-opentracing-1.1.1.jar
> -rw-rw-r--. 1 jstourac jstourac 11K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/wildfly-microprofile-opentracing-smallrye-14.0.0.CR1-SNAPSHOT.jar
> {code}
> It looks like the opentracing-smallrye module could be split up into a few separate modules. There at least two motivations:
> # particular implementation into its own module separate from the e.g. microprofile specification
> # because of the way how current patching mechanism works in WildFly, if we leave current {{opentracing-smallrye}} module as is, in case of a one-off patch it would mean to replace all files in the module - currently 3.3MB:
> {code}
> $ du -h modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/
> 3.3M modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/
> {code}
> My proposal how to align the jar files is following:
> # jaeger specific files should go into separate jaeger module
> # {{wildfly-microprofile-opentracing-smallrye-14.0.0.CR1-SNAPSHOT.jar}} should be moved to new {{modules/system/layers/base/org/wildfly/extension/microprofile/opentracing-smallrye}} module so it matches what is done for {{health-smallrye}} and {{config-smallrye}} in extension subdir
> # {{smallrye-opentracing-1.1.1.jar}} should be moved to {{base/io}} as is done for {{config}} and {{health}} - {{modules/system/layers/base/io/smallrye/opentracing/main/smallrye-opentracing-1.1.1.jar}}
> # what about that {{gson-2.8.2.jar}} dependency? Shall it be moved to some more generic place?
> This would give us following structure:
> {code}
> modules/system/layers/base/io/smallrye/config/main/smallrye-config-1.3.3.jar
> modules/system/layers/base/io/smallrye/health/main/smallrye-health-1.0.2.jar
> modules/system/layers/base/io/smallrye/opentracing/main/smallrye-opentracing-1.1.1.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-api-0.31.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-jaxrs2-0.1.6.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-concurrent-0.1.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-web-servlet-filter-0.1.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-noop-0.31.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-tracerresolver-0.1.5.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-util-0.31.0.jar
> modules/system/layers/base/org/wildfly/extension/microprofile/health-smallrye/main/wildfly-microprofile-health-smallrye-14.0.0.CR1-SNAPSHOT.jar
> modules/system/layers/base/org/wildfly/extension/microprofile/config-smallrye/main/wildfly-microprofile-config-smallrye-14.0.0.CR1-SNAPSHOT.jar
> modules/system/layers/base/org/wildfly/extension/microprofile/opentracing-smallrye/main/wildfly-microprofile-opentracing-smallrye-14.0.0.CR1-SNAPSHOT.jar
> ---- I have no idea how this module for jaeger should be named...
> modules/system/layers/base/org/wildfly/microprofile/jaeger/opentracing-smallrye/main/jaeger-thrift-0.30.4.jar
> modules/system/layers/base/org/wildfly/microprofile/jaeger/opentracing-smallrye/main/jaeger-core-0.30.4.jar
> ---- I have no idea how this module for gson should be named...
> modules/system/layers/base/org/wildfly/gson/main/gson-2.8.2.jar
> {code}
> One additional piece for consideration - maybe we should also split up jar files that are just the microprofile-opentracing specification (api at least I guess) apart from the others in the {{modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/}}
> What do you think?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-119) [Artemis 2.x upgrade] Lost message in replicated HA scenario with MDB
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFWIP-119?page=com.atlassian.jira.plugin.... ]
Clebert Suconic commented on WFWIP-119:
---------------------------------------
same way on last run:
23:54:42,847 Thread-2 INFO [org.jboss.qa.hornetq.test.failover.ReplicatedDedicatedFailoverTestWithMdb:137] Producer: 3000
23:54:42,847 Thread-2 INFO [org.jboss.qa.hornetq.test.failover.ReplicatedDedicatedFailoverTestWithMdb:138] Receiver: 2088
and on hornetq-journal-D.zip with print-data.sh:
### Message Counts ###
message count=0
message reference count
queue id 89,count=912
prepared message count=0
> [Artemis 2.x upgrade] Lost message in replicated HA scenario with MDB
> ---------------------------------------------------------------------
>
> Key: WFWIP-119
> URL: https://issues.jboss.org/browse/WFWIP-119
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Martyn Taylor
> Priority: Blocker
>
> *Scenario*
> * Start live/backup pair in replicated dedicated topology and start one more server which is in Artemis cluster with live.
> * Send messages to queue InQueue.
> * Start another server with MDB connected to cluster with live server which resend messages from InQueue to OutQueue.
> * Stop backup server and then live server.
> * Stop server which was in cluster with live server.
> * Start live server and server in cluster.
> * Start backup server.
> The test fails because one message get lost. It wasn't sent to OutQueue.
> Logs from failed test including traces you can find in \[1\].
> \[1\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months