March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11808) Unable to do jndi lookup when starting batch job from web console

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-11808?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-11808: ------------------------------ Attachment: (was: Screen Shot 2019-03-20 at 7.28.49 PM.png) > Unable to do jndi lookup when starting batch job from web console > ----------------------------------------------------------------- > > Key: WFLY-11808 > URL: https://issues.jboss.org/browse/WFLY-11808 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 16.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: External Management Request Thread.png, Screen Shot 2019-03-04 at 10.38.47 PM.png > > > when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11808) Unable to do jndi lookup when starting batch job from web console

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-11808?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-11808: ------------------------------ Attachment: External Management Request Thread.png > Unable to do jndi lookup when starting batch job from web console > ----------------------------------------------------------------- > > Key: WFLY-11808 > URL: https://issues.jboss.org/browse/WFLY-11808 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 16.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: External Management Request Thread.png, Screen Shot 2019-03-04 at 10.38.47 PM.png > > > when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11808) Unable to do jndi lookup when starting batch job from web console

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-11808?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-11808: ------------------------------ Attachment: Default Task Thread.png > Unable to do jndi lookup when starting batch job from web console > ----------------------------------------------------------------- > > Key: WFLY-11808 > URL: https://issues.jboss.org/browse/WFLY-11808 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 16.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: Default Task Thread.png, External Management Request Thread.png, Screen Shot 2019-03-04 at 10.38.47 PM.png > > > when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11808) Unable to do jndi lookup when starting batch job from web console

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-11808?page=com.atlassian.jira.plugin... ] Cheng Fang commented on WFLY-11808: ----------------------------------- The batch subsystem chose the name context for the batch job execution as follows: {code:java} org.jboss.as.naming.context.NamespaceContextSelector.getCurrentSelector(); {code} So for a job execution request from the management console or CLI, the current thread is "External Management Threads - 1", and its associated name context is used for batch job execution, but this name context has no knowlege of the deployment that contains the batch job. Any lookup of application resources done from any batch artifacts during the batch job execution will simply fail. > Unable to do jndi lookup when starting batch job from web console > ----------------------------------------------------------------- > > Key: WFLY-11808 > URL: https://issues.jboss.org/browse/WFLY-11808 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 16.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: Screen Shot 2019-03-04 at 10.38.47 PM.png, Screen Shot 2019-03-20 at 7.28.49 PM.png > > > when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11808) Unable to do jndi lookup when starting batch job from web console

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-11808?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-11808: ------------------------------ Attachment: Screen Shot 2019-03-20 at 7.28.49 PM.png > Unable to do jndi lookup when starting batch job from web console > ----------------------------------------------------------------- > > Key: WFLY-11808 > URL: https://issues.jboss.org/browse/WFLY-11808 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 16.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: Screen Shot 2019-03-04 at 10.38.47 PM.png, Screen Shot 2019-03-20 at 7.28.49 PM.png > > > when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11872) Overhaul infinispan subsystem transformer tests to improve coverage

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11872?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11872: ---------------------------------- Summary: Overhaul infinispan subsystem transformer tests to improve coverage (was: Overhaul infinispan subsystem transformers to improve test coverage) > Overhaul infinispan subsystem transformer tests to improve coverage > ------------------------------------------------------------------- > > Key: WFLY-11872 > URL: https://issues.jboss.org/browse/WFLY-11872 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > The typical way subsystems test transformers is with a single transform xml file which contains all *transformable* attributes and resources to the oldest version (EAP 6.4 at the moment). However, as subsystems evolve certain attributes are not transformable *but* are missing from subsequent test coverage. For instance, attribute not present in EAP 6.4, but available since 7.0: the tests for EAP 7.1 could still test the transformation to EAP 7.0 but this is typically missed in the subsystems test coverage. > The solution is to use a specific file for *each* EAP controller version we are transforming to. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11886) Mutations following HttpSession.setAttribute(...) lost on failover when using ATTRIBUTE granularity distributed web session with a non-transactional cache

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-11886: ----------------------------------- Summary: Mutations following HttpSession.setAttribute(...) lost on failover when using ATTRIBUTE granularity distributed web session with a non-transactional cache Key: WFLY-11886 URL: https://issues.jboss.org/browse/WFLY-11886 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 16.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Consider the following code: AtomicInteger value = new AtomicInteger(1); session.setAttribute("a", value); value.incrementAndGet(); On failover, the value of attribute "a" will still be 1. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11885) Mutable getAttribute(...) and setAttribute(...) combination triggers redundant cache operation when using ATTRIBUTE granularity distributed web sessions with a transactional cache

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-11885: ----------------------------------- Summary: Mutable getAttribute(...) and setAttribute(...) combination triggers redundant cache operation when using ATTRIBUTE granularity distributed web sessions with a transactional cache Key: WFLY-11885 URL: https://issues.jboss.org/browse/WFLY-11885 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 16.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro When using a transactional cache with ATTRIBUTE granularity, the following code will trigger a redundant cache operation upon request completion: [1] AtomicInteger value = (AtomicInteger) session.getAttribute("a"); value.incrementAndGet(); session.setAttribute("a", value); [2] session.setAttribute("a", new AtomicInteger()); AtomicInteger value = (AtomicInteger) session.getAttribute("a"); value.incrementAndGet(); In case [1], the initial mutable getAttribute(...) triggers an eager mutate, which becomes redundant by the subsequent setAttribute(...). In case [2], the subsequent mutable getAttribute(...) does not need to trigger a mutation, as the previous setAttribute(...) already has. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11884) Mutations following HttpSession.setAttribute(...) lost on failover when using ATTRIBUTE granularity distributed web session with a non-transactional cache

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-11884: ----------------------------------- Summary: Mutations following HttpSession.setAttribute(...) lost on failover when using ATTRIBUTE granularity distributed web session with a non-transactional cache Key: WFLY-11884 URL: https://issues.jboss.org/browse/WFLY-11884 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 16.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Consider the following code: AtomicInteger value = new AtomicInteger(1); session.setAttribute("a", value); value.incrementAndGet(); On failover, the value of attribute "a" will still be 1. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11882) Mutable getAttribute(...) and setAttribute(...) combination triggers redundant cache operation when using ATTRIBUTE granularity distributed web sessions with a transactional cache

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11882?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-11882: -------------------------------- Description: When using a transactional cache with ATTRIBUTE granularity, the following code will trigger a redundant cache operation upon request completion: [1] AtomicInteger value = (AtomicInteger) session.getAttribute("a"); value.incrementAndGet(); session.setAttribute("a", value); [2] session.setAttribute("a", new AtomicInteger()); AtomicInteger value = (AtomicInteger) session.getAttribute("a"); value.incrementAndGet(); In case [1], the initial mutable getAttribute(...) triggers an eager mutate, which becomes redundant by the subsequent setAttribute(...). In case [2], the subsequent mutable getAttribute(...) does not need to trigger a mutation, as the previous setAttribute(...) already has. was: When using a transactional cache with ATTRIBUTE granularity, the following code triggers a redundant cache operation upon request completion: session.getAttribute("a"); session.setAttribute("a", new AtomicInteger()); or session.setAttribute("a", new AtomicInteger()); session.getAttribute("a"); > Mutable getAttribute(...) and setAttribute(...) combination triggers redundant cache operation when using ATTRIBUTE granularity distributed web sessions with a transactional cache > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11882 > URL: https://issues.jboss.org/browse/WFLY-11882 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > When using a transactional cache with ATTRIBUTE granularity, the following code will trigger a redundant cache operation upon request completion: > [1] > AtomicInteger value = (AtomicInteger) session.getAttribute("a"); > value.incrementAndGet(); > session.setAttribute("a", value); > [2] > session.setAttribute("a", new AtomicInteger()); > AtomicInteger value = (AtomicInteger) session.getAttribute("a"); > value.incrementAndGet(); > In case [1], the initial mutable getAttribute(...) triggers an eager mutate, which becomes redundant by the subsequent setAttribute(...). > In case [2], the subsequent mutable getAttribute(...) does not need to trigger a mutation, as the previous setAttribute(...) already has. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

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 2019