[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown
by Scott Marlow (JIRA)
Scott Marlow created WFLY-7108:
----------------------------------
Summary: UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown
Key: WFLY-7108
URL: https://issues.jboss.org/browse/WFLY-7108
Project: WildFly
Issue Type: Feature Request
Components: JPA / Hibernate
Affects Versions: 10.1.0.Final
Environment: *AppServer:* WildFly 10.1.0.Final
*WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
Reporter: Scott Marlow
Assignee: Scott Marlow
As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
*The obtained defect:*
A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
*FIX:*
We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
_Changes_: The method getSynchronizationType returns declared synchronization type.
*Consequences:*
We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
It requires a declaration of synchronize persistence context.
We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
*Our actions:*
We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
_Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
*Example for reproduction:*
I modified quickstart example: [^kitchensink-ear.rar]
MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
MemberRepository also perform join Transaction.
Questions from [~smarlow]:
- whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
We decided to use Container-managed EntityManager, because
- Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
- The container makes our job
We want to use the existing mechanism
*In Addition:*
Formally, this is out of JPA SPEC, but we have the following reasons:
- In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
- We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1199) Memory leak in KieScanner
by Mrunali Patil (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1199?page=com.atlassian.jira.plugi... ]
Mrunali Patil commented on DROOLS-1199:
---------------------------------------
How we can apply this patch to 6.4.Final version. Please can you suggest? As we are getting the OOM errors.
> Memory leak in KieScanner
> -------------------------
>
> Key: DROOLS-1199
> URL: https://issues.jboss.org/browse/DROOLS-1199
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Viacheslav Krot
> Assignee: Mario Fusco
> Fix For: 7.0.0.Beta1
>
>
> I'm not sure, but it seems there is a memory leak in KieScanner, not in scanner directly, but somewhere in plexus used internally.
> If you start KieScanner with version = LATEST, start it with interval say 1 second and sample memory with visualvm (or any other), you can watch number of instances org.eclipse.sisu.plexus.* growing over time. And they cannot be garbage collected - memory root is timer thread. This happens in drools 6.4.0, in 6.3.0 this issue was absent.
> Eventually application fails with OOM.
> As a workaround we call KieScanner#scan manually in a separate thread pool that is recreated from time to time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1796) read-attribute on non existing logger under /deployment throws NPE
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1796?page=com.atlassian.jira.plugi... ]
James Perkins moved JBEAP-6010 to WFCORE-1796:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1796 (was: JBEAP-6010)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Logging
(was: Logging)
Affects Version/s: (was: 7.1.0.DR4)
> read-attribute on non existing logger under /deployment throws NPE
> ------------------------------------------------------------------
>
> Key: WFCORE-1796
> URL: https://issues.jboss.org/browse/WFCORE-1796
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> {noformat}
> [standalone@localhost:9990 /] /deployment=testwebapplication.war/subsystem=logging/configuration=default/logger=unknown:read-attribute(name=level
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {noformat}
> Output:
> {noformat}
> 17:11:30,742 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "testwebapplication.war"),
> ("subsystem" => "logging"),
> ("configuration" => "default"),
> ("logger" => "unknown")
> ]): java.lang.NullPointerException
> at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$1.updateModel(LoggerResourceDefinition.java:77)
> at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$LoggerConfigurationReadStepHandler.updateModel(LoggerResourceDefinition.java:105)
> at org.jboss.as.logging.deployments.resources.LoggingConfigurationReadStepHandler.execute(LoggingConfigurationReadStepHandler.java:51)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:133)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:230)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> {noformat}
> it should print some better error messsage, like:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=logging/logger=unknown:read-attribute(name=level
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"logging\"),
> (\"logger\" => \"unknown\")
> ]' not found",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2092:
------------------------------------
That is correct -- the issue was only seen during merges. It is exacerbated with a significant quantity of hosts across bandwidth limited routed network. More specifically, if there are hosts on a 1G network that are connected by lower bandwidth lines -- like 256k.
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.txt
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1791:
-------------------------------------
Issue Type: Task (was: Bug)
Priority: Minor (was: Major)
I've changed this from a Bug to a Task because a debugging sessions shows that this operation-id passing works correctly. The task is to understand how. :) And perhaps add some more comments so it's less mysterious.
> Strange operation-id handling in domain server reload execution
> ---------------------------------------------------------------
>
> Key: WFCORE-1791
> URL: https://issues.jboss.org/browse/WFCORE-1791
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
>
> When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don’t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing.
> https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df... is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete.
> Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock.
> Task here is to
> 1) Confirm the above and then
> 2) Either
> a) get the operation-id propagated
> b) or rip the operation-id bit out of reload because investigation showed it was not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7106) Reject distributed web sessions with missing attribute cache entries
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-7106:
----------------------------------
Summary: Reject distributed web sessions with missing attribute cache entries
Key: WFLY-7106
URL: https://issues.jboss.org/browse/WFLY-7106
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 11.0.0.Alpha1
If we detect cache entry integrity constraint violations, then the session is invalid, and we should report it as not found and purge the orphaned entries.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7107) Reject distributed web sessions with missing attribute cache entries
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-7107:
----------------------------------
Summary: Reject distributed web sessions with missing attribute cache entries
Key: WFLY-7107
URL: https://issues.jboss.org/browse/WFLY-7107
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 11.0.0.Alpha1
If we detect cache entry integrity constraint violations, then the session is invalid, and we should report it as not found and purge the orphaned entries.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1742:
------------------------------------------
"showing runtime resources requires sending HTTP PUT (not GET)"
That's interesting. That may just be a result of the basic management API continuing to evolve after the HTTP code was written so parameters to read-resource/read-attribute are not picked up. [~dlofthouse] can you think of any security reason for that behavior?
> Allow registering a custom handler for management interface
> -----------------------------------------------------------
>
> Key: WFCORE-1742
> URL: https://issues.jboss.org/browse/WFCORE-1742
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Sebastian Łaskawiec
>
> When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users):
> {noformat}
> curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> HTTP/1.1 200 OK
> Connection: keep-alive
> Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 1927
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> {
> "cache-health" : "GREEN",
> "cluster-health" : ["test"],
> "cluster-name" : "clustered",
> "free-memory" : 96778,
> "log-tail" : [
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222",
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211",
> "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container",
> "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container",
> "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest",
> "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)"
> ],
> "number-of-cpus" : 8,
> "number-of-nodes" : 1,
> "total-memory" : 235520
> }%
> {noformat}
> It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months