[JBoss JIRA] (WFLY-12581) Optimize distributed web/ejb expiration schedulers
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12581?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-12581:
--------------------------------
Attachment: EJB DistributableCache (passivating).png
> Optimize distributed web/ejb expiration schedulers
> --------------------------------------------------
>
> Key: WFLY-12581
> URL: https://issues.jboss.org/browse/WFLY-12581
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: EJB DistributableCache (passivating).png, EJB SimpleCache.png, Schedulers for distributed workloads.png, Schedulers for local workloads.png
>
>
> WFLY-12321 added a new expiration scheduler implementation for SFSBs specifically optimized for non-distributed environments. The key features of this implementations are:
> * Uses a single scheduled task instead of a scheduled task per SFSB
> * Uses a double-linked list to track SFSBs to be expired
> Because most scheduled tasks will be canceled before they are executed, the performance of a given scheduler implementation is primarily limited by the cost of insertion and removal into the backing data structure. The goal of this jira is to generalize the scheduler implementation introduced by WFLY-12321 such that it can be used for scheduling of both local and distributed web sessions and SFSBs.
> In the scheduler implemented as part of WFLY-12321, the use of a linked queue is based on the following assumptions:
> # All SFSB using a given scheduler use the same @StatefulTimeout
> # A given call to Scheduler.schedule(...) is always the last item to be scheduled
> Unfortunately, the second assumption is not valid for distributed SFSBs as a member may assume the responsibility of expiring a SFSB previously owned by another member.
> Additionally, the second assumption is not valid for local nor distributed web sessions, as a given web session can override the default session timeout of the application.
> This jira proposes the following:
> * Generalize the Scheduler interface for reuse between SFSBs and web sessions.
> * Generalize the new local scheduler implementation such that the same scheduler can support both local and distributed objects using different data structures for tracking scheduled items
> * Replace ExpirationTracker with a ConcurrentDirectDeque to support local case, which has O(1) add/remove characteristics
> ** ConcurrentDirectDeque outperforms ExpirationTracker under concurrent load (see attached graph)
> * Local web sessions and all distributed use cases will store scheduled entries within a ConcurrentSkipListSet, which has O(log N) add/remove characteristics
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12581) Optimize distributed web/ejb expiration schedulers
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12581?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-12581:
-------------------------------------
Applying this new expiration scheduler to the EJB simple cache effectively doubles the performance of EJB invocations under load. See attached chart.
> Optimize distributed web/ejb expiration schedulers
> --------------------------------------------------
>
> Key: WFLY-12581
> URL: https://issues.jboss.org/browse/WFLY-12581
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: EJB SimpleCache.png, Schedulers for distributed workloads.png, Schedulers for local workloads.png
>
>
> WFLY-12321 added a new expiration scheduler implementation for SFSBs specifically optimized for non-distributed environments. The key features of this implementations are:
> * Uses a single scheduled task instead of a scheduled task per SFSB
> * Uses a double-linked list to track SFSBs to be expired
> Because most scheduled tasks will be canceled before they are executed, the performance of a given scheduler implementation is primarily limited by the cost of insertion and removal into the backing data structure. The goal of this jira is to generalize the scheduler implementation introduced by WFLY-12321 such that it can be used for scheduling of both local and distributed web sessions and SFSBs.
> In the scheduler implemented as part of WFLY-12321, the use of a linked queue is based on the following assumptions:
> # All SFSB using a given scheduler use the same @StatefulTimeout
> # A given call to Scheduler.schedule(...) is always the last item to be scheduled
> Unfortunately, the second assumption is not valid for distributed SFSBs as a member may assume the responsibility of expiring a SFSB previously owned by another member.
> Additionally, the second assumption is not valid for local nor distributed web sessions, as a given web session can override the default session timeout of the application.
> This jira proposes the following:
> * Generalize the Scheduler interface for reuse between SFSBs and web sessions.
> * Generalize the new local scheduler implementation such that the same scheduler can support both local and distributed objects using different data structures for tracking scheduled items
> * Replace ExpirationTracker with a ConcurrentDirectDeque to support local case, which has O(1) add/remove characteristics
> ** ConcurrentDirectDeque outperforms ExpirationTracker under concurrent load (see attached graph)
> * Local web sessions and all distributed use cases will store scheduled entries within a ConcurrentSkipListSet, which has O(log N) add/remove characteristics
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12581) Optimize distributed web/ejb expiration schedulers
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12581?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-12581:
--------------------------------
Attachment: EJB SimpleCache.png
> Optimize distributed web/ejb expiration schedulers
> --------------------------------------------------
>
> Key: WFLY-12581
> URL: https://issues.jboss.org/browse/WFLY-12581
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: EJB SimpleCache.png, Schedulers for distributed workloads.png, Schedulers for local workloads.png
>
>
> WFLY-12321 added a new expiration scheduler implementation for SFSBs specifically optimized for non-distributed environments. The key features of this implementations are:
> * Uses a single scheduled task instead of a scheduled task per SFSB
> * Uses a double-linked list to track SFSBs to be expired
> Because most scheduled tasks will be canceled before they are executed, the performance of a given scheduler implementation is primarily limited by the cost of insertion and removal into the backing data structure. The goal of this jira is to generalize the scheduler implementation introduced by WFLY-12321 such that it can be used for scheduling of both local and distributed web sessions and SFSBs.
> In the scheduler implemented as part of WFLY-12321, the use of a linked queue is based on the following assumptions:
> # All SFSB using a given scheduler use the same @StatefulTimeout
> # A given call to Scheduler.schedule(...) is always the last item to be scheduled
> Unfortunately, the second assumption is not valid for distributed SFSBs as a member may assume the responsibility of expiring a SFSB previously owned by another member.
> Additionally, the second assumption is not valid for local nor distributed web sessions, as a given web session can override the default session timeout of the application.
> This jira proposes the following:
> * Generalize the Scheduler interface for reuse between SFSBs and web sessions.
> * Generalize the new local scheduler implementation such that the same scheduler can support both local and distributed objects using different data structures for tracking scheduled items
> * Replace ExpirationTracker with a ConcurrentDirectDeque to support local case, which has O(1) add/remove characteristics
> ** ConcurrentDirectDeque outperforms ExpirationTracker under concurrent load (see attached graph)
> * Local web sessions and all distributed use cases will store scheduled entries within a ConcurrentSkipListSet, which has O(log N) add/remove characteristics
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12300) Convert to Jakarta EE 8 specification APIs
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12300?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-12300:
-------------------------------------
Marking as resolved, as all of the subtasks are resolved! Time for champagne or beer to celebrate this milestone! :-)
> Convert to Jakarta EE 8 specification APIs
> ------------------------------------------
>
> Key: WFLY-12300
> URL: https://issues.jboss.org/browse/WFLY-12300
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 18.0.0.Final
>
>
> This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
> The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
> I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
> The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
> For each JBoss specification API fork that existed in EAP 7.2, a designated owner for that API jar has been determined. The task for each owner consists of:
> # Create/update a jboss.org Jakarta fork.
> # Track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
> # For the fork, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
> Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
> _Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
> _In fact, doing this is strongly encouraged as it allows us to further verify the fork._
> Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
> For artifacts that will not involve a fork (e.g. JPA), the component owner should plan to file a PR moving to the Jakarta artifact (e.g. jakarta.persistence:jakarta.persistence-api) as soon as the official version after Jakarta is available in maven central (after Jakarta EE 8 final release).
> Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
> ||API||Owner||
> |jakarta.annotation:jakarta.annotation-api|Yeray Borges|
> |jakarta.batch:jakarta.batch-api|Cheng Fang|
> |jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
> |jakarta.el:jakarta.el-api|Scott Marlow|
> |jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
> |jakarta.faces:jakarta.faces-api|Farah Juma|
> |jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
> |jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
> |jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
> |jakarta.resource:jakarta.resource-api|Stefano Maestri|
> |jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
> |jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
> |jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
> |jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
> |jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
> |jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
> |jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
> |jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
> |jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
> |jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
> |jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFWIP-187) Changes to PVC are not reflected in Operator
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-187?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFWIP-187:
------------------------------------
[~jmesnil] was it necessary to introduce new annotation on StatefulSet. There is currently Kubernetes standard {{metadata.generation}}. I just want to make sure you have considered this option as well.
> Changes to PVC are not reflected in Operator
> --------------------------------------------
>
> Key: WFWIP-187
> URL: https://issues.jboss.org/browse/WFWIP-187
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: operator
>
> Any chnages (adding, removing or updating) made to PVC after WildFlyServer CR was created are not reflected in underlying PVC kubernetes object.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4569) XLS editor should have a save button
by Toni Rikkola (Jira)
Toni Rikkola created DROOLS-4569:
------------------------------------
Summary: XLS editor should have a save button
Key: DROOLS-4569
URL: https://issues.jboss.org/browse/DROOLS-4569
Project: Drools
Issue Type: Bug
Components: XLS Decision Table Editor
Reporter: Toni Rikkola
Assignee: Toni Rikkola
It is impossible to save metadata changes without a Save button. You can however update the XLS file by uploading it each time.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFWIP-213) Can't resolve artifact for module when executing CLI modification
by Jan Blizňák (Jira)
[ https://issues.jboss.org/browse/WFWIP-213?page=com.atlassian.jira.plugin.... ]
Jan Blizňák updated WFWIP-213:
------------------------------
Description:
Using image {{docker-registry.upshift.redhat.com/kwills/eap-cd-openshift-rhel8:18.0-EAP7-1216}} when we workaround the issues WFWIP-208 & WFWIP-212 the CLI modification still won't process successfully because of the exception:
{code:java}
I0926 13:20:23.465008 1 sti.go:697] Exception in thread "main" org.jboss.modules.ModuleLoadException: Error loading module from /opt/eap/modules/system/layers/base/org/apache/xerces/main/module.xml
I0926 13:20:23.465037 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:339)
I0926 13:20:23.465047 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:295)
I0926 13:20:23.465052 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:256)
I0926 13:20:23.465060 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.parseModuleXmlFile(LocalModuleFinder.java:250)
I0926 13:20:23.465067 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.lambda$findModule$1(LocalModuleFinder.java:195)
I0926 13:20:23.465075 1 sti.go:697] at java.base/java.security.AccessController.doPrivileged(Native Method)
I0926 13:20:23.465082 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:195)
I0926 13:20:23.465089 1 sti.go:697] at org.jboss.modules.ModuleLoader.findModule0(ModuleLoader.java:696)
I0926 13:20:23.465096 1 sti.go:697] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:689)
I0926 13:20:23.465103 1 sti.go:697] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:499)
I0926 13:20:23.465110 1 sti.go:697] at org.jboss.modules.DelegatingModuleLoader.preloadModule(DelegatingModuleLoader.java:57)
I0926 13:20:23.465117 1 sti.go:697] at org.jboss.modules.Module.addPaths(Module.java:1252)
I0926 13:20:23.465125 1 sti.go:697] at org.jboss.modules.Module.link(Module.java:1622)
I0926 13:20:23.465132 1 sti.go:697] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
I0926 13:20:23.465141 1 sti.go:697] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:299)
I0926 13:20:23.465147 1 sti.go:697] at org.jboss.modules.Main.main(Main.java:437)
I0926 13:20:23.465153 1 sti.go:697] Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve artifact 'xerces:xercesImpl:2.12.0.SP02' (position: END_TAG seen ...esources>\n <artifact name="xerces:xercesImpl:2.12.0.SP02"/>... @26:57)
I0926 13:20:23.465159 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:1063)
I0926 13:20:23.465177 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:950)
I0926 13:20:23.465206 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:710)
I0926 13:20:23.465211 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:471)
I0926 13:20:23.465217 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:337)
I0926 13:20:23.465224 1 sti.go:697] ... 15 more
{code}
Because jboss-modules will try to resolve artifact from ~/.m2/settings.xml and galleon integration replaces this file before this error, there must be something wrong.
was:
Using image {{docker-registry.upshift.redhat.com/kwills/eap-cd-openshift-rhel8:18.0-EAP7-1216}} when we workaround the issues WFWIP-208 & WFWIP-212 the CLI modification still won't process successfully because of the exception:
{code:java}
I0926 13:20:23.465008 1 sti.go:697] Exception in thread "main" org.jboss.modules.ModuleLoadException: Error loading module from /opt/eap/modules/system/layers/base/org/apache/xerces/main/module.xml
I0926 13:20:23.465037 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:339)
I0926 13:20:23.465047 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:295)
I0926 13:20:23.465052 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:256)
I0926 13:20:23.465060 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.parseModuleXmlFile(LocalModuleFinder.java:250)
I0926 13:20:23.465067 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.lambda$findModule$1(LocalModuleFinder.java:195)
I0926 13:20:23.465075 1 sti.go:697] at java.base/java.security.AccessController.doPrivileged(Native Method)
I0926 13:20:23.465082 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:195)
I0926 13:20:23.465089 1 sti.go:697] at org.jboss.modules.ModuleLoader.findModule0(ModuleLoader.java:696)
I0926 13:20:23.465096 1 sti.go:697] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:689)
I0926 13:20:23.465103 1 sti.go:697] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:499)
I0926 13:20:23.465110 1 sti.go:697] at org.jboss.modules.DelegatingModuleLoader.preloadModule(DelegatingModuleLoader.java:57)
I0926 13:20:23.465117 1 sti.go:697] at org.jboss.modules.Module.addPaths(Module.java:1252)
I0926 13:20:23.465125 1 sti.go:697] at org.jboss.modules.Module.link(Module.java:1622)
I0926 13:20:23.465132 1 sti.go:697] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
I0926 13:20:23.465141 1 sti.go:697] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:299)
I0926 13:20:23.465147 1 sti.go:697] at org.jboss.modules.Main.main(Main.java:437)
I0926 13:20:23.465153 1 sti.go:697] Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve artifact 'xerces:xercesImpl:2.12.0.SP02' (position: END_TAG seen ...esources>\n <artifact name="xerces:xercesImpl:2.12.0.SP02"/>... @26:57)
I0926 13:20:23.465159 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:1063)
I0926 13:20:23.465177 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:950)
I0926 13:20:23.465206 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:710)
I0926 13:20:23.465211 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:471)
I0926 13:20:23.465217 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:337)
I0926 13:20:23.465224 1 sti.go:697] ... 15 more
{code}
> Can't resolve artifact for module when executing CLI modification
> -----------------------------------------------------------------
>
> Key: WFWIP-213
> URL: https://issues.jboss.org/browse/WFWIP-213
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Brian Stansberry
> Priority: Blocker
>
> Using image {{docker-registry.upshift.redhat.com/kwills/eap-cd-openshift-rhel8:18.0-EAP7-1216}} when we workaround the issues WFWIP-208 & WFWIP-212 the CLI modification still won't process successfully because of the exception:
> {code:java}
> I0926 13:20:23.465008 1 sti.go:697] Exception in thread "main" org.jboss.modules.ModuleLoadException: Error loading module from /opt/eap/modules/system/layers/base/org/apache/xerces/main/module.xml
> I0926 13:20:23.465037 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:339)
> I0926 13:20:23.465047 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:295)
> I0926 13:20:23.465052 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:256)
> I0926 13:20:23.465060 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.parseModuleXmlFile(LocalModuleFinder.java:250)
> I0926 13:20:23.465067 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.lambda$findModule$1(LocalModuleFinder.java:195)
> I0926 13:20:23.465075 1 sti.go:697] at java.base/java.security.AccessController.doPrivileged(Native Method)
> I0926 13:20:23.465082 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:195)
> I0926 13:20:23.465089 1 sti.go:697] at org.jboss.modules.ModuleLoader.findModule0(ModuleLoader.java:696)
> I0926 13:20:23.465096 1 sti.go:697] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:689)
> I0926 13:20:23.465103 1 sti.go:697] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:499)
> I0926 13:20:23.465110 1 sti.go:697] at org.jboss.modules.DelegatingModuleLoader.preloadModule(DelegatingModuleLoader.java:57)
> I0926 13:20:23.465117 1 sti.go:697] at org.jboss.modules.Module.addPaths(Module.java:1252)
> I0926 13:20:23.465125 1 sti.go:697] at org.jboss.modules.Module.link(Module.java:1622)
> I0926 13:20:23.465132 1 sti.go:697] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
> I0926 13:20:23.465141 1 sti.go:697] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:299)
> I0926 13:20:23.465147 1 sti.go:697] at org.jboss.modules.Main.main(Main.java:437)
> I0926 13:20:23.465153 1 sti.go:697] Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve artifact 'xerces:xercesImpl:2.12.0.SP02' (position: END_TAG seen ...esources>\n <artifact name="xerces:xercesImpl:2.12.0.SP02"/>... @26:57)
> I0926 13:20:23.465159 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:1063)
> I0926 13:20:23.465177 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:950)
> I0926 13:20:23.465206 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:710)
> I0926 13:20:23.465211 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:471)
> I0926 13:20:23.465217 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:337)
> I0926 13:20:23.465224 1 sti.go:697] ... 15 more
> {code}
> Because jboss-modules will try to resolve artifact from ~/.m2/settings.xml and galleon integration replaces this file before this error, there must be something wrong.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFWIP-213) Can't resolve artifact for module when executing CLI modification
by Jan Blizňák (Jira)
Jan Blizňák created WFWIP-213:
---------------------------------
Summary: Can't resolve artifact for module when executing CLI modification
Key: WFWIP-213
URL: https://issues.jboss.org/browse/WFWIP-213
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Jan Blizňák
Assignee: Brian Stansberry
Using image {{docker-registry.upshift.redhat.com/kwills/eap-cd-openshift-rhel8:18.0-EAP7-1216}} when we workaround the issues WFWIP-208 & WFWIP-212 the CLI modification still won't process successfully because of the exception:
{code:java}
I0926 13:20:23.465008 1 sti.go:697] Exception in thread "main" org.jboss.modules.ModuleLoadException: Error loading module from /opt/eap/modules/system/layers/base/org/apache/xerces/main/module.xml
I0926 13:20:23.465037 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:339)
I0926 13:20:23.465047 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:295)
I0926 13:20:23.465052 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:256)
I0926 13:20:23.465060 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.parseModuleXmlFile(LocalModuleFinder.java:250)
I0926 13:20:23.465067 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.lambda$findModule$1(LocalModuleFinder.java:195)
I0926 13:20:23.465075 1 sti.go:697] at java.base/java.security.AccessController.doPrivileged(Native Method)
I0926 13:20:23.465082 1 sti.go:697] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:195)
I0926 13:20:23.465089 1 sti.go:697] at org.jboss.modules.ModuleLoader.findModule0(ModuleLoader.java:696)
I0926 13:20:23.465096 1 sti.go:697] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:689)
I0926 13:20:23.465103 1 sti.go:697] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:499)
I0926 13:20:23.465110 1 sti.go:697] at org.jboss.modules.DelegatingModuleLoader.preloadModule(DelegatingModuleLoader.java:57)
I0926 13:20:23.465117 1 sti.go:697] at org.jboss.modules.Module.addPaths(Module.java:1252)
I0926 13:20:23.465125 1 sti.go:697] at org.jboss.modules.Module.link(Module.java:1622)
I0926 13:20:23.465132 1 sti.go:697] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
I0926 13:20:23.465141 1 sti.go:697] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:299)
I0926 13:20:23.465147 1 sti.go:697] at org.jboss.modules.Main.main(Main.java:437)
I0926 13:20:23.465153 1 sti.go:697] Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve artifact 'xerces:xercesImpl:2.12.0.SP02' (position: END_TAG seen ...esources>\n <artifact name="xerces:xercesImpl:2.12.0.SP02"/>... @26:57)
I0926 13:20:23.465159 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:1063)
I0926 13:20:23.465177 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:950)
I0926 13:20:23.465206 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:710)
I0926 13:20:23.465211 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:471)
I0926 13:20:23.465217 1 sti.go:697] at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:337)
I0926 13:20:23.465224 1 sti.go:697] ... 15 more
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFWIP-212) [Galleon] openshift-common.sh will always shut down without any error message if something goes wrong with JBoss CLI
by Michal Jurc (Jira)
[ https://issues.jboss.org/browse/WFWIP-212?page=com.atlassian.jira.plugin.... ]
Michal Jurc updated WFWIP-212:
------------------------------
Description:
The build will exit without any message no matter if something goes wrong around this line in {{openshift-common.sh}}:
{code:bash}eval ${JBOSS_HOME}/bin/jboss-cli.sh "--file=${CLI_SCRIPT_FILE_FOR_EMBEDDED}" "--properties=${CLI_SCRIPT_PROPERTY_FILE}" "&>${CLI_SCRIPT_OUTPUT_FILE}"{code}
This blocks testing of EAP7-891.
was:
The build will exit without any message no matter if something goes wrong around this line in {{openshift-common.sh}}:
{code:bash}eval ${JBOSS_HOME}/bin/jboss-cli.sh "--file=${CLI_SCRIPT_FILE_FOR_EMBEDDED}" "--properties=${CLI_SCRIPT_PROPERTY_FILE}" "&>${CLI_SCRIPT_OUTPUT_FILE}"{code}
> [Galleon] openshift-common.sh will always shut down without any error message if something goes wrong with JBoss CLI
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-212
> URL: https://issues.jboss.org/browse/WFWIP-212
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Environment: docker-registry.upshift.redhat.com/kwills/eap-cd-openshift-rhel8:18.0-EAP...
> 18.0-EAP7-1216 builder image
> Reporter: Michal Jurc
> Assignee: Brian Stansberry
> Priority: Blocker
>
> The build will exit without any message no matter if something goes wrong around this line in {{openshift-common.sh}}:
> {code:bash}eval ${JBOSS_HOME}/bin/jboss-cli.sh "--file=${CLI_SCRIPT_FILE_FOR_EMBEDDED}" "--properties=${CLI_SCRIPT_PROPERTY_FILE}" "&>${CLI_SCRIPT_OUTPUT_FILE}"{code}
> This blocks testing of EAP7-891.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months