[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 10:48 AM:
-----------------------------------------------------------------------
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components.
And see where I might be bale to override functionality to what you suggest.
Let us see how the fishing goes.
Many thanks.
was (Author: nuno.godinhomatos):
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
Many thanks.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
Many thanks.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-1349) Incorrect doPrivileged usage causes AccessControlException (FilePermission) in Elytron's ServiceLoaderSupplier
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1349?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reassigned ELY-1349:
-------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Incorrect doPrivileged usage causes AccessControlException (FilePermission) in Elytron's ServiceLoaderSupplier
> --------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1349
> URL: https://issues.jboss.org/browse/ELY-1349
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.1.Final
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
>
> When application server is running with Security Manager then using Elytron API (ElytronXmlParser.parseAuthenticationClientConfiguration()) from deployment leads to AccessControlException. The ServiceLoaderSupplier incorrectly uses doPrivileged, so the FilePermission check during accessing Elytron JAR fails.
> Workaround could be adding this FilePermission to each such deployment, but this is neither safe nor practical as the JAR name and location can change (e.g. version upgrade with patches applied).
> It seems the problem is caused by passing AccessControlContext as second parameter of {{doPrivileged}} method [1]. {{ServiceLoaderSupplier}} does not require this permission when second paramater is removed from {{doPrivileged}} method. This privileged block has been added as fix of JBEAP-12111 - {{doPrivileged}} call has been added into {{org.wildfly.security.util.ServiceLoaderSupplier}}.
> For example this is stacktrace for calling {{ElytronXmlParser.parseAuthenticationClientConfiguration}} method from Servlet in war application:
> {code}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/user/jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron-private/main/wildfly-elytron-1.1.1.Final-redhat-1.jar" "read")" in code source "(vfs:/content/wildfly-config-xml-dep.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.wildfly-config-xml-dep.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350)
> at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1038)
> at java.util.ServiceLoader.parse(ServiceLoader.java:304)
> at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
> at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
> at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at org.wildfly.security.util.ServiceLoaderSupplier.loadServices(ServiceLoaderSupplier.java:73)
> at org.wildfly.security.util.ServiceLoaderSupplier.lambda$get$0(ServiceLoaderSupplier.java:58)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.util.ServiceLoaderSupplier.get(ServiceLoaderSupplier.java:58)
> at org.wildfly.security.util.ServiceLoaderSupplier.get(ServiceLoaderSupplier.java:39)
> at org.wildfly.security.auth.client.ElytronXmlParser$DeferredSupplier.get(ElytronXmlParser.java:2433)
> at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:115)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseClearPassword$40(ElytronXmlParser.java:2001)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$27(ElytronXmlParser.java:918)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$23(ElytronXmlParser.java:895)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$33(ElytronXmlParser.java:953)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$18(ElytronXmlParser.java:691)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$23(ElytronXmlParser.java:895)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$23(ElytronXmlParser.java:895)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$22(ElytronXmlParser.java:739)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$7(ElytronXmlParser.java:575)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:599)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:299)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:176)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:137)
> ...
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/8c033958d78fcb1c...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JGRP-815) Scatter/Gather to avoid copying
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-815?page=com.atlassian.jira.plugin.s... ]
Bela Ban edited comment on JGRP-815 at 8/31/17 7:41 AM:
--------------------------------------------------------
bla10: sender
bla9: receiver
was (Author: belaban):
bla10: receiver
bla9: sender
> Scatter/Gather to avoid copying
> -------------------------------
>
> Key: JGRP-815
> URL: https://issues.jboss.org/browse/JGRP-815
> Project: JGroups
> Issue Type: Sub-task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
> Attachments: bla10.java, bla9.java
>
>
> When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
> We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
> We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
> 1: Src and dest address plus flags, plus possibly size
> 2: The marshalled headers
> 3: The buffer passed to JGroups by the user
> We can obtain a gathering-write channel as follows:
> ByteBuffer[] buffers; // contains the 3 byte buffers above
> DatagramSocket sock;
> DatagramChannel ch=sock.getChannel();
> ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
> This is supported by a GatheringByteChannel.
> I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9284) git wildfly build.bat pointing to none existent maven script
by Nuno Godinho de Matos (JIRA)
Nuno Godinho de Matos created WFLY-9284:
-------------------------------------------
Summary: git wildfly build.bat pointing to none existent maven script
Key: WFLY-9284
URL: https://issues.jboss.org/browse/WFLY-9284
Project: WildFly
Issue Type: Bug
Components: Scripts
Reporter: Nuno Godinho de Matos
Assignee: Tomaz Cerar
Priority: Trivial
Trying to build the current wildfly master by calling upon build.bat has failed due to missing mvn.cmd file.
In order to be able to trigger the build process, the build.bat script had to be corrected on the following line:
{panel}
set DIRNAME=%~p0
set MVN=%DIRNAME%\mvnw.cmd
{panel}
The script that is found on my current wildfly\ directory is called:
mvnw.cmd and not mvn.cmd
I would also suggest that in some documentation people are recommended to tune their maven settings and add in the repository:
{code}
<repository>
<id>jboss-public</id>
<url>https://repository.jboss.org/nexus/content/groups/public/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
{code}
Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JGRP-1911) Use consensus for some subsystems
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1911?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1911:
--------------------------------
Note that {{CounterService}} does exist in the jgroups-raft project.
> Use consensus for some subsystems
> ---------------------------------
>
> Key: JGRP-1911
> URL: https://issues.jboss.org/browse/JGRP-1911
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> Provide options for several subsystems to run with consensus, e.g.
> * {{SEQUENCER}}
> * {{CENTRAL_LOCK}}
> * {{COUNTER}}
> * {{TOA}}
> * Clustered singletons etc
> For example, with the current impl of distributed counters ({{COUNTER}}), the same counter can be available multiple times if we have a split brain. It is currently up to the user to merge counters with different values after a split brain heals.
> This is OK, but we should provide a second implementation, based on jgroups-raft, which uses consensus to determine the counter maintainer in a split brain scenario. This will forfeit availability in favor of consistency.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months