[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, 3 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, 3 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, 3 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, 3 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, 3 months
[JBoss JIRA] (ELY-1350) Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1350?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1350:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1350
> URL: https://issues.jboss.org/browse/ELY-1350
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
> There is problem with getting value of environment variable ELYTRON_TOOL_ADDONS.
> *How to reproduce:*
> * run powershell and set work directory JBOSS_HOME/bin
> * set env variable for custom credential store implementation jar like this:
> {code}
> $env:ELYTRON_TOOL_ADDONS="C:\custom.jar"
> {code}
> * run this command
> {code}
> PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l 001.jceks --type CustomTestCredentialStore --debug
> Exception encountered executing the command:
> java.security.NoSuchAlgorithmException
> at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:80)
> at
> org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:188
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
> {code}
> *Suggestion to improve:*
> For me works one of these changes in elytron-tool.ps1 script
> # if (Test-Path env:ELYTRON_TOOL_ADDONS) { $ELYTRON_TOOL_ADDONS=(Get-ChildItem Env:ELYTRON_TOOL_ADDONS).value }
> # $ELYTRON_TOOL_ADDONS=$env:ELYTRON_TOOL_ADDONS
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-9278) EJB Acces Timeout is ignored on SFSBs when using distributed caches
by Bernhard Hablesreiter (JIRA)
[ https://issues.jboss.org/browse/WFLY-9278?page=com.atlassian.jira.plugin.... ]
Bernhard Hablesreiter commented on WFLY-9278:
---------------------------------------------
Just an update, not directly linked to this issue, but we found out that a change in "org.jboss.as.ejb3.tx.OwnableReentrantLock" caused the different behaviour in accessing SFSBs (see https://github.com/wildfly/wildfly/commit/8403b6b7afbb1d38c6410bde81ece0d...). Maybe this is also related.
> EJB Acces Timeout is ignored on SFSBs when using distributed caches
> -------------------------------------------------------------------
>
> Key: WFLY-9278
> URL: https://issues.jboss.org/browse/WFLY-9278
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Bernhard Hablesreiter
> Attachments: wildfly-request-test.zip
>
>
> When using distributed caches on Stateful Session Beans, the configured access timeout is ignored. However, the caches acquire-timeout is used instead, leading to a "org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after x seconds".
> The configuration:
> {code:xml}
> <session-bean>
> <stateless>
> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
> </stateless>
> <stateful default-access-timeout="2000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> <singleton default-access-timeout="2000"/>
> </session-bean>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> <caches>
> <cache name="simple"/>
> <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
> </caches>
> ...
> <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
> ...
> <cache-container name="ejb" aliases="sfsb" default-cache="passivation" module="org.wildfly.clustering.ejb.infinispan">
> <local-cache name="passivation">
> <locking isolation="REPEATABLE_READ" acquire-timeout="10000"/>
> <transaction mode="BATCH" />
> <file-store passivation="true" purge="true"/>
> </local-cache>
> </cache-container>
> ...
> </subsystem>
> {code}
> With the above configuration, any access to a @Stateful-component does not timeout after 2 seconds, but the 10 seconds configured on the infinispan-cache.
> I have attached a simple JSF web application as an eclipse project to reproduce the problem. The application calls a method on a sfsb, increments a counter and waits for 300ms. If one sends multiple request at the same time (e.g. by pressing F5 repeatedly), the problem can easily be reproduced after a few seconds.
> If the cache-ref is set to "simple" the configured access timeout works as exptected, however the access to the stateful bean does not appear to be in sync with the requests the client sent. We came around this issue when trying to migrate vom WF9 to WF10 (see also this forum post: https://developer.jboss.org/thread/266303). When the cache-ref is set to "distrubted", the requests are handled correctly/in correct order (in WF9 this was also the case with cache-ref "simple"), but the access timeout is ignored.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months