March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6332) HHH-10563: Significant String use/duplication associated with subselect fetch

by Stephen Fikes (JIRA)

[ https://issues.jboss.org/browse/WFLY-6332?page=com.atlassian.jira.plugin.... ] Stephen Fikes updated WFLY-6332: -------------------------------- Description: The use of @Fetch(FetchMode.SUBSELECT) results in a significant level of string duplication for SQL and SQL fragments. When loading large datasets and/or higher numbers of associations with multiple associations using SUBSELECT the memory can accumulate significantly (e.g. on the order of multiple GB for string space associated with the duplicate SQL fragments alone). > HHH-10563: Significant String use/duplication associated with subselect fetch > ----------------------------------------------------------------------------- > > Key: WFLY-6332 > URL: https://issues.jboss.org/browse/WFLY-6332 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Stephen Fikes > Assignee: Gail Badner > > The use of @Fetch(FetchMode.SUBSELECT) results in a significant level of string duplication for SQL and SQL fragments. When loading large datasets and/or higher numbers of associations with multiple associations using SUBSELECT the memory can accumulate significantly (e.g. on the order of multiple GB for string space associated with the duplicate SQL fragments alone). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6332) HHH-10563: Significant String use/duplication associated with subselect fetch

by Stephen Fikes (JIRA)

[ https://issues.jboss.org/browse/WFLY-6332?page=com.atlassian.jira.plugin.... ] Stephen Fikes reassigned WFLY-6332: ----------------------------------- Assignee: Gail Badner (was: Scott Marlow) > HHH-10563: Significant String use/duplication associated with subselect fetch > ----------------------------------------------------------------------------- > > Key: WFLY-6332 > URL: https://issues.jboss.org/browse/WFLY-6332 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Stephen Fikes > Assignee: Gail Badner > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6332) HHH-10563: Significant String use/duplication associated with subselect fetch

by Stephen Fikes (JIRA)

Stephen Fikes created WFLY-6332: ----------------------------------- Summary: HHH-10563: Significant String use/duplication associated with subselect fetch Key: WFLY-6332 URL: https://issues.jboss.org/browse/WFLY-6332 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Affects Versions: 10.0.0.Final Reporter: Stephen Fikes Assignee: Scott Marlow -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1106) Better handling of subsequent changes once the server is placed into reload-required

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1106?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1106: ------------------------------------------ Another question: should the reload op fail when the server is restart-required? A main result of this work is we can begin deferring further runtime changes until a reload occurs in order to ensure that the runtime state is consistent with a coherent configuration state. But a reload when the server is restart-required does not achieve this. It results in runtime state being consistent with the current configuration, except for whatever bits of runtime state aren't updated with only a reload. One (bad) option is, during a reload boot, to only apply runtime changes that are not directly or transitively associated with the restart-required capabilities. But that is liable to leave the server in a very odd state, and one the user will very likely not expect. For example the transactions subsystem has restart-required attributes, and that means a very broad array of runtime services will not execute. > Better handling of subsequent changes once the server is placed into reload-required > ------------------------------------------------------------------------------------ > > Key: WFCORE-1106 > URL: https://issues.jboss.org/browse/WFCORE-1106 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > When the handler for a configuration change operation determines that it cannot effect the change to the current runtime services, it places the process into "reload-required" state. From the moment this occurs until the reload is performed, the configuration model is inconsistent with the runtime services. > This can lead to problems when, prior to reload, the user makes further configuration changes. Those changes can succeed in Stage.MODEL, since the change is valid given the current state of the configuration model, but then when the handler attempts to update the runtime the changes fail because the runtime services are in a different state. Some common scenarios: > 1) User removes a resource, triggering reload required. Then they re-add the resource, which fails with a DuplicateServiceException since the service from the original version of the resource hasn't been removed yet. > 2) User makes some other config change to a resource which can't be effected immediately, so the server is put into reload-required. The user then adds another resource that depends on the services from the first resource, and that add fails because the runtime service from the first resource is not in the expected state. > A naive fix for this would be once the process goes into reload-required state to stop making any further runtime changes for steps that alter the persistent config. (Runtime changes for ops that don't touch persistent config would be ok, e.g. reload itself, or runtime-only ops like popping a message off a JMS queue.) > The problem with the naive approach is config changes that could take immediate effect no longer will. This could break existing scripts, or just be annoying in general. For example, a server is in reload-required state but is still running. Then the user wants to add a logger category or change the level of an existing one in order to get some diagnostic info. The logging change would not affect the runtime until the reload is done, forcing a reload to get the diagnostic data. > Stuart Douglas had an excellent suggestion today of looking into tying this in to capabilities and requirements. So, for example: > 1) An op targeted at resource foo=bar causes the process to go into reload-required. > 2) The kernel detects this and finds the registration for the foo=bar resource type, and sees that the resource provides capability org.wildfly.foo.bar. > 3) The kernel records in the capability registry that org.wildfly.foo.bar is now "reload-required". > 4) Thereafter, for any op that changes the model and then adds a runtime step, the kernel: > a) finds the registration for the resource type associated with that op's target address > b) finds any capabilities provided by the resource type > c) looks for direct or transitive requirements for those capabilites that are "reload-required" > d) if found, the runtime step is not executed, and instead the "server-requires-reload" response-header is added. > The effect here is the granularity of what ops have their runtime changes skipped is reduced to those associated with capabilities that put the server into reload-required. Unrelated ops, e.g. the logging changes mentioned above, are unaffected. > Some fine points: > 1) The restart-required and reload-required states need to be tracked separately. The information regarding any restart-required capabilities needs to survive a reload. > 2) The information that a capability is reload/restart-required needs to survive the removal of the capability. This allows the remove+add scenario to work. The remove op removes the capability, but the fact it is still present in the runtime is tracked, so when the add comes in no runtime changes are made. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1082) Querying for objects before any have been inserted prevents Class Aware Object Store from working properly

by James Elford (JIRA)

James Elford created DROOLS-1082: ------------------------------------ Summary: Querying for objects before any have been inserted prevents Class Aware Object Store from working properly Key: DROOLS-1082 URL: https://issues.jboss.org/browse/DROOLS-1082 Project: Drools Issue Type: Bug Affects Versions: 6.3.0.Final Reporter: James Elford Assignee: Mark Proctor In the presence of a class heirarchy, the {{ClassAwareObjectStore}} doesn't properly manage the relationships between {{SingleClassStores}} - specifically, it can become permanently corrupt if the following order of events occurs: * Insert object of type {{BaseClass}} * Query for objects of type {{SubClass}} ** Note that it's important this query is fully evaluated (e.g. copy it into a list) * Insert object of type {{SubClass}} Subsequent queries for objects of type {{BaseClass}} will _not_ return objects of type {{SubClass}}. If the intervening query for {{SubClass}} is left out, they would. The problem's in {{ClassAwareObjectStore#getOrCreateConcreteClass}}, where it tries to concretize an existing (non-concrete) store. It should go through the same "linking" process that gets done in the {{existingStore == null}} case (and half of which is done already in {{#getOrCreateClassStore}}). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-49) Limit deployment scanner to a list of deployments

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-49?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-49: ----------------------------------- Component/s: Deployment Scanner > Limit deployment scanner to a list of deployments > ------------------------------------------------- > > Key: WFCORE-49 > URL: https://issues.jboss.org/browse/WFCORE-49 > Project: WildFly Core > Issue Type: Feature Request > Components: Deployment Scanner, Domain Management > Reporter: Brian Stansberry > Priority: Minor > > The basic scenario here is there's a file /some/path/to/foo.war that users want deployed via a scanner, but /some/path/to includes other files that can't be moved and that should not be scanned. There's no way to limit the scanner to foo.war and related marker files. > Allowing configuration of an explicit white list of (non-marker) files to consider, and/or a black list of ones to ignore, would allow this use case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-405) Filesystem deployment scanner for a managed domain

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-405?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-405: ------------------------------------ Component/s: Deployment Scanner > Filesystem deployment scanner for a managed domain > -------------------------------------------------- > > Key: WFCORE-405 > URL: https://issues.jboss.org/browse/WFCORE-405 > Project: WildFly Core > Issue Type: Enhancement > Components: Deployment Scanner, Domain Management > Environment: Ubuntu 12.04 Os , JBOSS As 7.1.0 final > Reporter: hitesh yadav > Original Estimate: 1 day, 4 hours > Remaining Estimate: 1 day, 4 hours > > Is there any folder or path at which if any .war is put, in such a way that when JBOSS AS 7.1.0 start in domain mode the .war file deploy in Master node and it's related slave Node. > For Example......... In standalone mode if we put .war file in /jboss-as-7.1.0.Final/standalone/deployments/ folder and start the JBOSS AS 7.1.0 in standalone mode ,the .war deploy properly.......i want same thing domain mode, in other-server-group ..... > Means the requirement is that the .war file should put in one folder and when JBOSS AS 7.1.0 start in domain mode the .war file should deploy in other-server-group ............. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-331) Configurable location for deployment scanner marker files

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-331?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-331: ------------------------------------ Component/s: Deployment Scanner > Configurable location for deployment scanner marker files > --------------------------------------------------------- > > Key: WFCORE-331 > URL: https://issues.jboss.org/browse/WFCORE-331 > Project: WildFly Core > Issue Type: Feature Request > Components: Deployment Scanner, Domain Management > Reporter: Brian Stansberry > > Add marker-dir and marker-dir-relative-to attributes to the deployment scanner resource. These control where the marker files are written, with the default being the dir being scanned itself. > The idea here is to allow sharing of a deployments/ dir by letting users redirect the markers to some other location. > To store in a server-specific subdir of deployments (making the markers still fairly accessible the user): > {code} > <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" > marker-dir="deployments/${jboss.node.name}" > marker-dir-relative-to="jboss.server.base.dir" > /> > {code} > To store the markers in the data dir, out of sight, out of mind: > {code} > <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" > marker-dir="deployment-scanner-markers" > marker-dir-relative-to="jboss.server.data.dir" > /> > {code} > This all sounds simple enough, but anyone looking into it *must* assume this will be a highly complex task, as the scanner itself is very complex and assumes that the deployments and the markers are in the same dir. Extremely extensive test coverage will be required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1333) Editing of default deployment scanner's relative-to attribute can cause server crash

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1333?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1333: ------------------------------------- Component/s: Deployment Scanner > Editing of default deployment scanner's relative-to attribute can cause server crash > ------------------------------------------------------------------------------------ > > Key: WFCORE-1333 > URL: https://issues.jboss.org/browse/WFCORE-1333 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Domain Management > Affects Versions: 2.0.7.Final > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Critical > > Setting value of {{relative-to}} attribute of default deployment scanner on standalone server to a path which does not exists in file system causes server crash. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6329) Deployment scanner logs ERROR when server is shutting down

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6329?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-6329: ----------------------------------- Component/s: (was: Server) > Deployment scanner logs ERROR when server is shutting down > ---------------------------------------------------------- > > Key: WFLY-6329 > URL: https://issues.jboss.org/browse/WFLY-6329 > Project: WildFly > Issue Type: Bug > Affects Versions: 2.1.0.CR1 > Reporter: Ondřej Chaloupka > Assignee: ehsavoie Hugonnet > > It happens time to time that deployment scanner can throw and log error [1] when server is shutting down. > It's in case of clean startup and clean shutdown when error messages should not be shown. I can hit it when unbounding a datasource takes a bit longer and scan of deployment scanner hits that time. > [1] > {code} > ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /mnt/hudson_workspace/workspace/eap-70-jbossts-crashrec-tests-mssql2014/90fac01f/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/deployments threw Exception: java.lang.RuntimeException: WFLYDS0036: Deployment model operation failed. WFLYCTL0271: Operation cancelled > at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:83) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1614) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1563) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:568) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:489) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:250) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016