[JBoss JIRA] (WFLY-12774) Upgrade Hibernate ORM from 5.3.13 to 5.3.14
by Gail Badner (Jira)
[ https://issues.jboss.org/browse/WFLY-12774?page=com.atlassian.jira.plugin... ]
Gail Badner updated WFLY-12774:
-------------------------------
Description:
This upgrade is intended for 19.0.0.Beta1.
was:
This upgrade is intended for EAP 7.3.0.
Please note that the Hibernate ORM tag may be taken from a product branch instead of a community release. Hence "5.3.?" in the description.
> Upgrade Hibernate ORM from 5.3.13 to 5.3.14
> -------------------------------------------
>
> Key: WFLY-12774
> URL: https://issues.jboss.org/browse/WFLY-12774
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Gail Badner
> Priority: Major
> Labels: downstream_dependency
> Fix For: 19.0.0.Beta1
>
>
> This upgrade is intended for 19.0.0.Beta1.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12774) Upgrade Hibernate ORM from 5.3.13 to 5.3.14
by Gail Badner (Jira)
[ https://issues.jboss.org/browse/WFLY-12774?page=com.atlassian.jira.plugin... ]
Gail Badner updated WFLY-12774:
-------------------------------
Summary: Upgrade Hibernate ORM from 5.3.13 to 5.3.14 (was: [GSS](7.3.z) Upgrade Hibernate ORM from 5.3.13 to 5.3.14)
> Upgrade Hibernate ORM from 5.3.13 to 5.3.14
> -------------------------------------------
>
> Key: WFLY-12774
> URL: https://issues.jboss.org/browse/WFLY-12774
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Gail Badner
> Priority: Major
> Labels: downstream_dependency
> Fix For: 19.0.0.Beta1
>
>
> This upgrade is intended for EAP 7.3.0.
> Please note that the Hibernate ORM tag may be taken from a product branch instead of a community release. Hence "5.3.?" in the description.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12774) [GSS](7.3.z) Upgrade Hibernate ORM from 5.3.13 to 5.3.14
by Gail Badner (Jira)
[ https://issues.jboss.org/browse/WFLY-12774?page=com.atlassian.jira.plugin... ]
Gail Badner moved JBEAP-17978 to WFLY-12774:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-12774 (was: JBEAP-17978)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JPA / Hibernate
(was: Hibernate)
Fix Version/s: 19.0.0.Beta1
(was: 7.3.0.GA)
> [GSS](7.3.z) Upgrade Hibernate ORM from 5.3.13 to 5.3.14
> --------------------------------------------------------
>
> Key: WFLY-12774
> URL: https://issues.jboss.org/browse/WFLY-12774
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Gail Badner
> Priority: Major
> Labels: downstream_dependency
> Fix For: 19.0.0.Beta1
>
>
> This upgrade is intended for EAP 7.3.0.
> Please note that the Hibernate ORM tag may be taken from a product branch instead of a community release. Hence "5.3.?" in the description.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4735) [DMN Designer] Grid performance is dire
by Michael Anstis (Jira)
Michael Anstis created DROOLS-4735:
--------------------------------------
Summary: [DMN Designer] Grid performance is dire
Key: DROOLS-4735
URL: https://issues.jboss.org/browse/DROOLS-4735
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.29.0.Final
Reporter: Michael Anstis
Assignee: Michael Anstis
There have been reports that the performance of the DMN editor's grids does not scale. On examination performance for anything other than simple examples is pretty dire.. something is seriously wrong.
On closer inspection the following issues were found:
- Multiple {{NodeMouseDownHandler}}, {{NodeMouseMoveHandler}} and {{NodeMouseUpHandler}} are registered because multiple {{DMNGridLayer}} are (incorrectly) instantiated due to a flaw in {{GridLienzoPanel}} and {{GridLienzoScrollHandler}}.
- Calls to {{GridWidget.getHeight()}} and {{GridRow.getHeight()}} can be _very_ expensive for due to the dynamic calculation in {{ExpressionEditorGridRow}} and {{LiteralExpressionGridRow}} rows.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2396) increasing networkdata, cpu and heap
by Rob van der Boom (Jira)
[ https://issues.jboss.org/browse/JGRP-2396?page=com.atlassian.jira.plugin.... ]
Rob van der Boom commented on JGRP-2396:
----------------------------------------
ok, but when system is idle, als cpu % is very high. actualy we normaly get high cpu load warning (> 1) during idle times.
You mean this is not unusual ? We are used to that 1 cpu cycle is only when heavy load and now it is when no user activity..
> increasing networkdata, cpu and heap
> ------------------------------------
>
> Key: JGRP-2396
> URL: https://issues.jboss.org/browse/JGRP-2396
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.19
> Reporter: Rob van der Boom
> Assignee: Bela Ban
> Priority: Major
> Attachments: Schermafbeelding 2019-11-08 om 15.43.04.png, Schermafbeelding 2019-11-08 om 15.44.52.png, Schermafbeelding 2019-11-08 om 16.00.48.png, standalone-ha.xml
>
>
> hey,
> we have an keycloak (sso) setup, version 7.0.1 running in kubernetes - aws.
> Its build on wildfly 17, infinispan 9.4 and jgroups 4.0.19.
> We have 3 pods running in standalone-ha with cache setup on distribution (all 3 nodes - so equivalent to replication)
> ISSUE:
> We see a slowly growing of networkstatistics, heap and cpu, while the number of sessions in keycloak (cached) remain almost stable.
> The cpu growth is caused by the TQbundler process, which explaines the networkdata growth. It looks like this is causing also a memory leakage..
> every 5 days we have to restart the pods and then every resets to a very low level including the heap. this while all sessions are still valid and cached.
> The only issue i could find maybe related to this is:
> https://issues.jboss.org/browse/JGRP-2382?jql=project%20%3D%20JGRP%20AND%...
> Could this be the same issue and does it also cause increasing network and cpu (since that is why we have to restart, the heap has much space left !).
> And if so how does this issue continue since for us its a major issue.
> We als had this issue already in keycloak 5 (wildfly 15), thats why we upgraded to the latest available version.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12773) BOMs is a separate component
by Eduardo Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-12773?page=com.atlassian.jira.plugin... ]
Eduardo Martins moved JBEAP-17976 to WFLY-12773:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-12773 (was: JBEAP-17976)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Build System
(was: BOM)
> BOMs is a separate component
> ----------------------------
>
> Key: WFLY-12773
> URL: https://issues.jboss.org/browse/WFLY-12773
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Environment: Patched Galleon to obey dependency management (issue forthcoming)
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
> Priority: Major
>
> {{wildfly-jms-client-bom}} is defined as having version {{${project.version}}}, but the main codebase does not produce this artifact.
> https://github.com/jbossas/jboss-eap7/blob/CD14/pom.xml#L819
> It is produced at https://github.com/wildfly/boms/blob/master/client/jms-client/pom.xml#L40
> If Galleon were to obey dependency management this leads to:
> {noformat}
> [ERROR] Failed to execute goal org.wildfly.galleon-plugins:wildfly-galleon-maven-plugin:2.0.1.Alpha1-SNAPSHOT:generate-feature-specs (feature-spec-build) on project wildfly-galleon-pack: Failed to resolve artifact org.jboss.eap:wildfly-jms-client-bom:pom:7.2.0.CD14-redhat-SNAPSHOT as a dependency of eap-cd-servlet@maven(org.jboss.universe:product-universe):current#7.2.0.CD14-redhat-SNAPSHOT (persisted as org.jboss.eap:wildfly-jms-client-bom:7.2.0.CD14-redhat-SNAPSHOT::pom): Couldn't resolve artifact: Failure to find org.jboss.eap:wildfly-jms-client-bom:pom:7.2.0.CD14-redhat-SNAPSHOT in http://repository.jboss.org/nexus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.wildfly.galleon-plugins:wildfly-galleon-maven-plugin:2.0.1.Alpha1-SNAPSHOT:generate-feature-specs (feature-spec-build) on project wildfly-galleon-pack: Failed to resolve artifact org.jboss.eap:wildfly-jms-client-bom:pom:7.2.0.CD14-redhat-SNAPSHOT as a dependency of eap-cd-servlet@maven(org.jboss.universe:product-universe):current#7.2.0.CD14-redhat-SNAPSHOT (persisted as org.jboss.eap:wildfly-jms-client-bom:7.2.0.CD14-redhat-SNAPSHOT::pom)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> 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)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> 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)
> at org.apache.maven.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:39)
> at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:122)
> at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:50)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to resolve artifact org.jboss.eap:wildfly-jms-client-bom:pom:7.2.0.CD14-redhat-SNAPSHOT as a dependency of eap-cd-servlet@maven(org.jboss.universe:product-universe):current#7.2.0.CD14-redhat-SNAPSHOT (persisted as org.jboss.eap:wildfly-jms-client-bom:7.2.0.CD14-redhat-SNAPSHOT::pom)
> at org.wildfly.galleon.maven.WfFeatureSpecBuildMojo.processFeaturePackDep(WfFeatureSpecBuildMojo.java:564)
> at org.wildfly.galleon.maven.WfFeatureSpecBuildMojo.processFeaturePackDeps(WfFeatureSpecBuildMojo.java:511)
> at org.wildfly.galleon.maven.WfFeatureSpecBuildMojo.doExecute(WfFeatureSpecBuildMojo.java:235)
> at org.wildfly.galleon.maven.WfFeatureSpecBuildMojo.execute(WfFeatureSpecBuildMojo.java:191)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 27 more
> Caused by: org.apache.maven.plugin.MojoExecutionException: Couldn't resolve artifact: Failure to find org.jboss.eap:wildfly-jms-client-bom:pom:7.2.0.CD14-redhat-SNAPSHOT in http://repository.jboss.org/nexus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced
> at org.wildfly.galleon.maven.WfFeatureSpecBuildMojo.findArtifact(WfFeatureSpecBuildMojo.java:716)
> at org.wildfly.galleon.maven.WfFeatureSpecBuildMojo.processFeaturePackDep(WfFeatureSpecBuildMojo.java:562)
> ... 32 more
> Caused by: org.apache.maven.shared.artifact.resolve.ArtifactResolverException: Failure to find org.jboss.eap:wildfly-jms-client-bom:pom:7.2.0.CD14-redhat-SNAPSHOT in http://repository.jboss.org/nexus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced
> at org.apache.maven.shared.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact(Maven31ArtifactResolver.java:116)
> at org.apache.maven.shared.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact(Maven31ArtifactResolver.java:80)
> at org.apache.maven.shared.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:73)
> at org.wildfly.galleon.maven.WfFeatureSpecBuildMojo.findArtifact(WfFeatureSpecBuildMojo.java:713)
> ... 33 more
> Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Failure to find org.jboss.eap:wildfly-jms-client-bom:pom:7.2.0.CD14-redhat-SNAPSHOT in http://repository.jboss.org/nexus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:444)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
> at org.apache.maven.shared.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact(Maven31ArtifactResolver.java:108)
> ... 36 more
> Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to find org.jboss.eap:wildfly-jms-client-bom:pom:7.2.0.CD14-redhat-SNAPSHOT in http://repository.jboss.org/nexus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.newException(DefaultUpdateCheckManager.java:231)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkArtifact(DefaultUpdateCheckManager.java:183)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.gatherDownloads(DefaultArtifactResolver.java:585)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:503)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
> ... 40 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12624) Return hostname instead of IP address when generating default client mapping
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-12624?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-12624 at 11/8/19 10:17 AM:
----------------------------------------------------------------------
The other problem here: we are passing an IPv4 address with an IPv6 netmask.
For user-specified client mappings, the user is responsible for sending out a netmask which is of the same type (IPv4, IPv6) as the client mapping destination address.
In the case of the default client mapping (this case), we should probably check the IP stack that the host's JVM was started with to determine what to send out with the host name.
was (Author: rachmato):
The other problem here: we are passing an IPv4 address with an IPv6 netmask.
For use -specified client mappings, the user is responsible for sending out a netmask which is of the same type (IPv4, IPv6) as the client mapping destination address. In the case of the default client mapping, we should probably check the IP stack that the host's JVM was started with to determine what to send out.
> Return hostname instead of IP address when generating default client mapping
> -----------------------------------------------------------------------------
>
> Key: WFLY-12624
> URL: https://issues.jboss.org/browse/WFLY-12624
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Environment: An EJB client application interacting with a cluster of Wildfly server nodes
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> When an EJB client application interacts with a clustered Wildfly deployment, it receives topology updates from cluster nodes describing the membership of the cluster.
> For each node in the cluster, a set of one or more client mappings is provided to indicate how the client may connect to the node, if it hasn't already. If the node is connected to a single network, there will be one client mapping; if the node is multi-homed and connected to two networks, there will be two client mappings, etc. Client mappings specify three things: a CIDR representation of the network the client may be on, a destination hostname or IP address and a destination port.
> Client mappings may be generated by default (if none are provided in the server profile) or may be specified by the user via client mappings defined in the socket binding of the Remoting connector. For example:
> {noformat}
> <socket-binding name="remoting" port="1099">
> <client-mapping source-network="135.121.1.0/24" destination-address="135.121.1.29" destination-port="1099"/>
> </socketbinding>
> {noformat}
> When the client mapping information is received by the EJB client application, it is added to the discovered node registry (DNR) in the Discovery component of the EJB client. The DNR represents all known information about nodes with which the client can interact which was received from nodes in one or more clusters.
> When an invocation is attempted, the Discovery component uses this information to generate a set of ServiceURLs which represent candidate targets (i.e. servers containing the deployment and module the client is invoking on) for the invocation. The Discovery component uses "an algorithm" to take the information in the DNR (and other places) and convert that information to a corresponding set of ServiceURLs representing available targets. The Discovery component will then select one such ServiceURL and return this as the target for the invocation. For example, in the above case, the service URL will look something like:
> {noformat}
> service:ejb.jboss:remote://135.121.1.29:1099;cluster=ejb;node=node1;ejb-module=my-foo-app/my-bar-module;source-ip=135.121.1.0/24"
> {noformat}
> This service URL describes a server with logical name "node1" which:
> * is a member of a cluster called "ejb"
> * has the EJB module "my-foo-app/my-bar-module" and all the beans that it contains deployed
> * can be connected to by the URL "remote://135.121.1.29:1099" as long as you are on network "135.121.1.0/24"
> Discovery obtains node information used in the algorithm from various sources: client mappings associated with cluster nodes, as described above, as well as Remoting endpoints associated with established connections to nodes. These pieces of information describe at a minimum a host and a port.
> The problem is that "the algorithm" used in Discovery to compute the set of ServiceURLs treats hostnames and IP addresses as simple strings. So "localhost" and "127.0.0.1" are treated as different hosts, even though they refer to the same host. If a mix of hostnames and IP addresses for the same node is received, this results in an incomplete/incorrect set of ServiceURLs being generated which in turn leads to incorrect Discovery failures.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months