[JBoss JIRA] (WFLY-13505) Transaction JTS module misses dependencies to proper handling context propagation async calls
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created WFLY-13505:
---------------------------------------
Summary: Transaction JTS module misses dependencies to proper handling context propagation async calls
Key: WFLY-13505
URL: https://issues.redhat.com/browse/WFLY-13505
Project: WildFly
Issue Type: Bug
Components: Transactions
Affects Versions: 20.0.0.Beta1
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
The transaction JTS module misses the dependency with libraries which manage the reactive asynchronous handling for context propagation.
This is connected to JBTM-3246 which added the context propagation async handling capabilities to Narayana codebase.
The Narayana CDI interceptor is capable to handle reactive async code but it's dependent on reactive streams classes which have to be added as optional dependencies for `jts` module.
When the context propagation feature pack (https://github.com/kabir/wildfly-mp-reactive-feature-pack/) is deployed then these modules are provided into WildFly and the `jts` module will be then capable to use them and provide the context propagation capabilities managed in the feature pack.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4978) Remove setting Metaspace
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-4978?page=com.atlassian.jira.plug... ]
James Perkins moved WFLY-13301 to WFCORE-4978:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-4978 (was: WFLY-13301)
> Remove setting Metaspace
> ------------------------
>
> Key: WFCORE-4978
> URL: https://issues.redhat.com/browse/WFCORE-4978
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Moulali Shikalwadi
> Assignee: Moulali Shikalwadi
> Priority: Major
>
> Unlike perm gen, it is typically not necessary to set a max/min metaspace size[1] for the following reasons:
> *Metaspace size is unlimited by default. Since it only holds class metadata, size requirements are minimal.
> *It does not require a full gc to resize the metaspace, as it did with the perm generation.
> MaxMetaspaceSize includes CompressedClassSpaceSize, so MaxMetaspaceSize should be larger than CompressedClassSpaceSize.
> The default MaxMetaspaceSize is 1g:
> java -XX:+PrintFlagsFinal -version | grep CompressedClassSpaceSize
> uintx CompressedClassSpaceSize = 1073741824
> {product}
> If MaxMetaspaceSize is set smaller than CompressedClassSpaceSize, the JVM auto adjusts CompressedClassSpaceSize as follows: CompressedClassSpaceSize = MaxMetaspaceSize - (2 * InitialBootClassLoaderMetaspaceSize).[2]
> The default EAP Metaspace sizes are less than the default CompressedClassSpaceSize:
> -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> This adjusts down the MaxMetaspaceSize to 248m:
> java -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -XX:+PrintFlagsFinal -version | grep CompressedClassSpaceSize
> uintx CompressedClassSpaceSize := 260046848 {product}
> We have had a lot of OOME Metaspace cases[3], and support is no longer recommending customers set Metaspace:
> "In general, you should not need to set a maximum size, unless you are experiencing large metaspace leaks and would prefer it to fail rather than keep increasing memory size."[1]
> This was discussed with the OpenJDK developers[4], and their recommendation was to remove the Metaspace settings, and especially in the context of containers.
> References:
> [1]https://access.redhat.com/solutions/1489263
> [2]https://access.redhat.com/solutions/2132101
> [3]https://access.redhat.com/solutions/2038983
> [4]http://post-office.corp.redhat.com/archives/support-openjdk/2019-July/m...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13305) Bootable jar for Wildfly
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-13305?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFLY-13305:
--------------------------------------
[~jdenise] What is the status of this? It looks like the PR sent is because of the proposal.
> Bootable jar for Wildfly
> ------------------------
>
> Key: WFLY-13305
> URL: https://issues.redhat.com/browse/WFLY-13305
> Project: WildFly
> Issue Type: Feature Request
> Components: Server
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> Provides support for running MicroService apps without the need archive it as a deployment and without the need to deploy it in a running application server.
> Provides support for ability to run MicroService apps on the Operating Systems command line as a bootable jar.
> Provides support for developing and running the app. "java -jar app.jar" and maven command line interface.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5358) Add a way to define ResourceType inside kiebase
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5358?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5358:
-------------------------------------
Description:
Step to reproduce
1) create a project with multiple pmml files, each in its own package (eg. resources/package_name/file.pmml)
2) create a kmodule xml and define one kiebase for each package
3) compile the kjar
4) in the kjar the files/classes are all in the proper place (i.e. in the expected package)
5) add the kjar in a new project
6) in the new project invoke
KieServices.get().newKieClasspathContainer().getKieBase(kbaseName);
The jar packages are inside the kieBase.getPackages(), but they are not marked as "PMMLType" packages - so it is necessary to invoke the (PMML)AssemblerService to wrap the content of the (jar) packages inside correct PMMLType packages and put them in the knowledge base
The following snippet is a temporary workaround (inside CanonicalKieModule.createKieBase(KieBaseModelImpl, KieProject, ResultsImpl, KieBaseConfiguration))
{code:java}
for (KiePackage pk : pkgs) {
// Workaround to "mark" already compiled packages (as found inside the kjar and retrieved by createKiePackages(kieProject, kBaseModel, messages, kBaseConf))
// as "PMML" packages
boolean isInternalKnowldgePackage = pk instanceof InternalKnowledgePackage;
final InternalKnowledgePackage originalPackage = kieBase.getPackage(pk.getName());
if (originalPackage != null && isInternalKnowldgePackage && ((InternalKnowledgePackage) pk).getResourceTypePackages().get(ResourceType.PMML) != null) {
originalPackage.getResourceTypePackages().put(ResourceType.PMML, ((InternalKnowledgePackage) pk).getResourceTypePackages().get(ResourceType.PMML));
} else if (originalPackage == null) {
kieBase.addPackages(pkgs);
}
}
{code}
The idea is to get the "type" information from newly compiled package and put it in the existing one (that also contains al the other compiled classes).
Ideally, we should be able to completely skip the (PMML)AssemblerService invocation (that recreate new packages)
was:
Step to reproduce
1) create a project with multiple pmml files, each in its own package (eg. resources/package_name/file.pmml)
2) create a kmodule xml and define one kiebase for each package
3) compile the kjar
4) in the kjar the files/classes are all in the proper place (i.e. in the expected package)
5) add the kjar in a new project
6) in the new project invoke
KieServices.get().newKieClasspathContainer().getKieBase(kbaseName);
The jar packages are inside the kieBase.getPackages(), but they are not marked as "PMMLType" packages - so it is necessary to invoke the (PMML)AssemblerService to wrap the content of the (jar) packages inside correct PMMLType packages and put them in the knowledge base
> Add a way to define ResourceType inside kiebase
> -----------------------------------------------
>
> Key: DROOLS-5358
> URL: https://issues.redhat.com/browse/DROOLS-5358
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Mario Fusco
> Priority: Major
>
> Step to reproduce
> 1) create a project with multiple pmml files, each in its own package (eg. resources/package_name/file.pmml)
> 2) create a kmodule xml and define one kiebase for each package
> 3) compile the kjar
> 4) in the kjar the files/classes are all in the proper place (i.e. in the expected package)
> 5) add the kjar in a new project
> 6) in the new project invoke
> KieServices.get().newKieClasspathContainer().getKieBase(kbaseName);
> The jar packages are inside the kieBase.getPackages(), but they are not marked as "PMMLType" packages - so it is necessary to invoke the (PMML)AssemblerService to wrap the content of the (jar) packages inside correct PMMLType packages and put them in the knowledge base
> The following snippet is a temporary workaround (inside CanonicalKieModule.createKieBase(KieBaseModelImpl, KieProject, ResultsImpl, KieBaseConfiguration))
> {code:java}
> for (KiePackage pk : pkgs) {
> // Workaround to "mark" already compiled packages (as found inside the kjar and retrieved by createKiePackages(kieProject, kBaseModel, messages, kBaseConf))
> // as "PMML" packages
> boolean isInternalKnowldgePackage = pk instanceof InternalKnowledgePackage;
> final InternalKnowledgePackage originalPackage = kieBase.getPackage(pk.getName());
> if (originalPackage != null && isInternalKnowldgePackage && ((InternalKnowledgePackage) pk).getResourceTypePackages().get(ResourceType.PMML) != null) {
> originalPackage.getResourceTypePackages().put(ResourceType.PMML, ((InternalKnowledgePackage) pk).getResourceTypePackages().get(ResourceType.PMML));
> } else if (originalPackage == null) {
> kieBase.addPackages(pkgs);
> }
> }
> {code}
> The idea is to get the "type" information from newly compiled package and put it in the existing one (that also contains al the other compiled classes).
> Ideally, we should be able to completely skip the (PMML)AssemblerService invocation (that recreate new packages)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month