[JBoss JIRA] (JGRP-2394) Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
by Nistor Adrian (Jira)
[ https://issues.jboss.org/browse/JGRP-2394?page=com.atlassian.jira.plugin.... ]
Nistor Adrian updated JGRP-2394:
--------------------------------
Description:
The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
So we propose adding someting like this:
JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the caller's task to ensure this leads to generation of unique names.
was:
The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
So we propose adding someting like this:
JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the callers task to ensure this leads to generation of unique names.
> Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2394
> URL: https://issues.jboss.org/browse/JGRP-2394
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 4.1.6
> Reporter: Nistor Adrian
> Assignee: Bela Ban
> Priority: Major
>
> The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
> So we propose adding someting like this:
> JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
> which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the caller's task to ensure this leads to generation of unique names.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2394) Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
by Nistor Adrian (Jira)
Nistor Adrian created JGRP-2394:
-----------------------------------
Summary: Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
Key: JGRP-2394
URL: https://issues.jboss.org/browse/JGRP-2394
Project: JGroups
Issue Type: Enhancement
Affects Versions: 4.1.6
Reporter: Nistor Adrian
Assignee: Bela Ban
The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
So we propose adding someting like this:
JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the callers task to ensure this leads to generation of unique names.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4715) [DMN Designer] Structure is lost when user doesn't drag it enough
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-4715?page=com.atlassian.jira.plugi... ]
Guilherme Gomes updated DROOLS-4715:
------------------------------------
Description:
This issue is caused by DROOLS-4484
If user drag a structure not enough == no reordering/reorganization caused by that drag, the structure is lost. See the attached video.
---
⚠️ Notice: this issue is caused by the absence of reference, like the the scenario mentioned on DROOLS-4710. This JIRA must be marked as resolved only when both scenarios are solved.
was:
This issue is caused by DROOLS-4484
If user drag a structure not enough == no reordering/reorganization caused by that drag, the structure is lost. See the attached video.
> [DMN Designer] Structure is lost when user doesn't drag it enough
> -----------------------------------------------------------------
>
> Key: DROOLS-4715
> URL: https://issues.jboss.org/browse/DROOLS-4715
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.30.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: drag-not-enough.webm
>
>
> This issue is caused by DROOLS-4484
> If user drag a structure not enough == no reordering/reorganization caused by that drag, the structure is lost. See the attached video.
> ---
> ⚠️ Notice: this issue is caused by the absence of reference, like the the scenario mentioned on DROOLS-4710. This JIRA must be marked as resolved only when both scenarios are solved.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-10336) MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10336?page=com.atlassian.jira.plugin... ]
James Perkins closed WFLY-10336.
--------------------------------
Resolution: Out of Date
I'm closing this as out of date. All the tests pass for me on the latest WildFly upstream with OpenJ9 + OpenJDK 11 and OpenJ9 + OpenJDK 8.
{code}
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.15.1, JRE 11 Linux amd64-64-Bit Compressed References 20190717_286 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - fa49279450 based on jdk-11.0.4+11)
{code}
{code}
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190717_368 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - f147086df1e based on jdk8u222-b10)
{code}
> MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10336
> URL: https://issues.jboss.org/browse/WFLY-10336
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Web Services
> Environment: {noformat}
> Java(TM) SE Runtime Environment (build 8.0.5.11 - pxa6480sr5fp11-20180326_01(SR5 FP11))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20180309_380776 (JIT enabled, AOT enabled)
> OpenJ9 - 49fcaf39
> OMR - 5cbbadf
> IBM - 4453dac)
> JCL - 20180319_01 based on Oracle jdk8u161-b12
> {noformat}
> Reporter: Petr Kremensky
> Assignee: Daniel Cihak
> Priority: Major
>
> There are test failures running the WildFly Test Suite: Integration - WS on IBM jdk.
> {noformat}
> wildfly/testsuite/integration/ws] $ mvn clean install
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR] EJBSignTestCase.signedRequest:86 » SOAPFault MustUnderstand headers: [{http://...
> [ERROR] SignTestCase.signedRequest:88 » SOAPFault MustUnderstand headers: [{http://doc...
> [ERROR] EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromAlice:90 » SOAPFault
> [ERROR] EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn:102 » SOAPFault
> [ERROR] EJBSignEncryptTestCase.encryptedAndSignedRequest:88 » SOAPFault MustUnderstand...
> [ERROR] SignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromAlice:91 » SOAPFault
> [ERROR] SignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn:103 » SOAPFault
> [ERROR] SignEncryptTestCase.encryptedAndSignedRequest:90 » SOAPFault MustUnderstand he...
> [ERROR] WSTrustTestCase.test:318 » SOAPFault MustUnderstand headers: [{http://docs.oas...
> [ERROR] WSTrustTestCase.testActAs:441 » SOAPFault MustUnderstand headers: [{http://doc...
> [ERROR] WSTrustTestCase.testBearer:541 » SOAPFault MustUnderstand headers: [{http://do...
> [ERROR] WSTrustTestCase.testHolderOfKey:491 » SOAPFault MustUnderstand headers: [{http...
> [ERROR] WSTrustTestCase.testNoClientCallback:383 » SOAPFault MustUnderstand headers: [...
> [ERROR] WSTrustTestCase.testNoSignatureUsername:414 » SOAPFault MustUnderstand headers...
> [ERROR] WSTrustTestCase.testOnBehalfOf:468 » SOAPFault MustUnderstand headers: [{http:...
> [ERROR] WSTrustTestCase.testPicketLink:518 » SOAPFault MustUnderstand headers: [{http:...
> [ERROR] WSTrustTestCase.testUsingEPR:350 » SOAPFault MustUnderstand headers: [{http://...
> [INFO]
> [ERROR] Tests run: 119, Failures: 0, Errors: 17, Skipped: 0
> {noformat}
> *Caused by*
> {noformat}
> Caused by: org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:87)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:53)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:42)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:70)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:35)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:827)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1695)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1572)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1373)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:673)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:442)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:343)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
> ... 129 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-11178) WSTrustTestCase failing on IBM
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11178?page=com.atlassian.jira.plugin... ]
James Perkins closed WFLY-11178.
--------------------------------
Resolution: Out of Date
I'm closing this as out of date. All the tests pass for me on the latest WildFly upstream with OpenJ9 + OpenJDK 11 and OpenJ9 + OpenJDK 8.
{code}
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.15.1, JRE 11 Linux amd64-64-Bit Compressed References 20190717_286 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - fa49279450 based on jdk-11.0.4+11)
{code}
{code}
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190717_368 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - f147086df1e based on jdk8u222-b10)
{code}
> WSTrustTestCase failing on IBM
> ------------------------------
>
> Key: WFLY-11178
> URL: https://issues.jboss.org/browse/WFLY-11178
> Project: WildFly
> Issue Type: Bug
> Components: MSC
> Affects Versions: 14.0.0.Final
> Reporter: Jan Blizňák
> Assignee: Alessio Soldano
> Priority: Major
> Attachments: log.txt
>
>
> As discovered during investigation in WFLY-10336, we are now getting test failures in WSTrustTestCase when IBM JDK is used. The relevant part of the exception is:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Provider org.apache.xerces.jaxp.validation.XMLSchemaFactory not found
> at javax.xml.validation.SchemaFactory.newInstance(Unknown Source)
> at org.opensaml.core.xml.config.XMLConfigurator.<init>(XMLConfigurator.java:94)
> at org.apache.wss4j.common.saml.OpenSAMLBootstrap.bootstrap(OpenSAMLBootstrap.java:85)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:91)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:75)
> at org.apache.wss4j.common.saml.SamlAssertionWrapper.<init>(SamlAssertionWrapper.java:184)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:308)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:120)
> ... 102 more
> {code}
> It turned out the issue is in wildfly for some time, the breaking change was identified as https://github.com/wildfly/wildfly-core/pull/3201/
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12458) WebServices tests failing in IBM JDK8
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12458?page=com.atlassian.jira.plugin... ]
James Perkins closed WFLY-12458.
--------------------------------
Resolution: Out of Date
I'm closing this as out of date. All the tests pass for me on the latest WildFly upstream with OpenJ9 + OpenJDK 11 and OpenJ9 + OpenJDK 8.
{code}
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.15.1, JRE 11 Linux amd64-64-Bit Compressed References 20190717_286 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - fa49279450 based on jdk-11.0.4+11)
{code}
{code}
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190717_368 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - f147086df1e based on jdk8u222-b10)
{code}
> WebServices tests failing in IBM JDK8
> -------------------------------------
>
> Key: WFLY-12458
> URL: https://issues.jboss.org/browse/WFLY-12458
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Environment: java version "1.8.0_211"
> Java(TM) SE Runtime Environment (build 8.0.5.36 - pxa6480sr5fp36-20190510_01(SR5 FP36))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled)
> OpenJ9 - 46e57f9
> OMR - 06a046a
> IBM - 0b909bf)
> JCL - 20190409_01 based on Oracle jdk8u211-b25
> Reporter: Richard Opalka
> Assignee: Jim Ma
> Priority: Major
>
> [ERROR] EJBSignTestCase.signedRequest:86 » SOAPFault MustUnderstand headers: [{http://...
> [ERROR] SignTestCase.signedRequest:88 » SOAPFault MustUnderstand headers: [{http://doc...
> [ERROR] EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromAlice:90 » SOAPFault
> [ERROR] EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn:102 » SOAPFault
> [ERROR] EJBSignEncryptTestCase.encryptedAndSignedRequest:88 » SOAPFault MustUnderstand...
> [ERROR] SignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromAlice:91 » SOAPFault
> [ERROR] SignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn:103 » SOAPFault
> [ERROR] SignEncryptTestCase.encryptedAndSignedRequest:90 » SOAPFault MustUnderstand he...
> [ERROR] WSBearerElytronSecurityPropagationTestCase.testBearer:133 » SOAPFault MustUnde...
> [ERROR] WSBearerSecurityPropagationTestCase.testBearer:133 » SOAPFault MustUnderstand ...
> [ERROR] WSTrustTestCase.test:319 » SOAPFault MustUnderstand headers: [{http://docs.oas...
> [ERROR] WSTrustTestCase.testActAs:442 » SOAPFault MustUnderstand headers: [{http://doc...
> [ERROR] WSTrustTestCase.testBearer:553 » SOAPFault MustUnderstand headers: [{http://do...
> [ERROR] WSTrustTestCase.testHolderOfKey:494 » SOAPFault MustUnderstand headers: [{http...
> [ERROR] WSTrustTestCase.testNoClientCallback:384 » SOAPFault MustUnderstand headers: [...
> [ERROR] WSTrustTestCase.testNoSignatureUsername:415 » SOAPFault MustUnderstand headers...
> [ERROR] WSTrustTestCase.testOnBehalfOf:469 » SOAPFault MustUnderstand headers: [{http:...
> [ERROR] WSTrustTestCase.testPicketLink:526 » SOAPFault MustUnderstand headers: [{http:...
> [ERROR] WSTrustTestCase.testUsingEPR:351 » SOAPFault MustUnderstand headers: [{http://...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-7418) Batch deployments with a large number of executed jobs can lock up or slow down the web console
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-7418:
-------------------------------------
[~dinesh.mahadevan] Unfortunately at this point the best solution is to purge the job repository. To keep the data you could dump it into a different table, but I realize that is less than ideal.
One possible option, which would be a request for enhancement, would be allowing a setting to disable adding batch jobs to the runtime deployment resource. This would however not allow jobs to be seen, started or restarted from web console or via CLI.
> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7418
> URL: https://issues.jboss.org/browse/WFLY-7418
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch, Web Console
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
> Labels: move_to_halnext
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-7418) Batch deployments with a large number of executed jobs can lock up or slow down the web console
by Dinesh Mahadevan (Jira)
[ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.... ]
Dinesh Mahadevan commented on WFLY-7418:
----------------------------------------
Hi [~timonz]
+1 on the issue.
Using WildFly 16, we have an application that fails to start until we added -Djboss.as.management.blocking.timeout=6000" allowing the application to start after 2 hours.
Line 581 of class org.jberet.repository.JdbcRepository is the line that appears in almost all thread dumps. Judging from the context, it is executing the SQL from sqls.getProperty(SELECT_JOB_EXECUTIONS_BY_JOB_INSTANCE_ID)
The quickest solution we can find so far is to disable the MicroProfile setting on Wildfly, or purge the job_execution table manually.
{code:java}
<extension module="org.wildfly.extension.elytron"/>
<extension module="org.wildfly.extension.io"/>
<!--<extension module="org.wildfly.extension.microprofile.config-smallrye"/>
<extension module="org.wildfly.extension.microprofile.health-smallrye"/>
<extension module="org.wildfly.extension.microprofile.metrics-smallrye"/>
<extension module="org.wildfly.extension.microprofile.opentracing-smallrye"/>-->
<extension module="org.wildfly.extension.request-controller"/>
<extension module="org.wildfly.extension.security.manager"/>
<subsystem xmlns="urn:jboss:domain:mail:3.0">
<mail-session jndi-name="java:jboss/mail/Default" name="default">
<smtp-server outbound-socket-binding-ref="mail-smtp"/>
</mail-session>
</subsystem>
<!--<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"/>
<subsystem xmlns="urn:wildfly:microprofile-health-smallrye:1.0" security-enabled="false"/>
<subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:2.0" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}" security-enabled="false"/>
<subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:1.0"/>-->
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<remote-naming/>
</subsystem>
{code}
> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7418
> URL: https://issues.jboss.org/browse/WFLY-7418
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch, Web Console
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
> Labels: move_to_halnext
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months