[JBoss JIRA] (WFLY-6596) WrongClassException when using remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff updated WFLY-6596:
-------------------------------------------
Steps to Reproduce:
* Application
> unzip sample-10.1.0.Final.zip
> cd sample
> mvn clean install
> ls -la sample-ear/target/sample-ear.ear
* Infinispan
- Version 8.2.4.Final
- start:
> infinispan-server-8.2.4.Final/bin/standalone.sh --server-config=clustered.sample.xml -Djboss.socket.binding.port-offset=100
* Wildfly
- Version 10.1.0.Final
- start:
> wildfly-10.1.0.Final/bin/standalone.sh --server-config=standalone.sample.ha.xml
deploy: sample-ear.ear
Call in web browser: http://localhost:2680/sample-web/rest/members/listAll throws:
{{monospaced text}}
was:
* Application
> unzip sample.zip
> cd sample
> mvn clean install
> l sample-ear/target/sample-ear.ear
* Infinispan
- Version 8.1.2.Final
- starten:
> infinispan-server-8.1.2.Final/bin/standalone.sh --server-config=clustered.sample.xml -Djboss.socket.binding.port-offset=100
* Wildfly
- Version 10.0.0.Final
- fix Modules to manage successful start of Hotrod-Client unsinf infinispan.zip
concerned modul configuration (see also WFLY-6571):
./modules/system/layers/base/org/infinispan/main/module.xml
./modules/system/layers/base/org/infinispan/commons/main/module.xml
./modules/system/layers/base/org/infinispan/client/hotrod/main/module.xml
- start:
wildfly-10.0.0.Final/bin/standalone.sh --server-config=standalone.sample.ha.xml
deploy: sample-ear.ear
Call in web browser: http://localhost:2680/sample-web/rest/members/listAll throws:
Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> WrongClassException when using remote-store for hibernate entity cache
> ----------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 10.0.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample.zip, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1132) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2611) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2594) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2423) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2418) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.7.Final.jar:5.0.7.Final]
> ... 47 more
> This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-119) Add resolve-expressions param to operation read-resource
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-119?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-119:
------------------------------------------------
Miroslav Sochurek <msochure(a)redhat.com> changed the Status of [bug 1079197|https://bugzilla.redhat.com/show_bug.cgi?id=1079197] from ASSIGNED to NEW
> Add resolve-expressions param to operation read-resource
> --------------------------------------------------------
>
> Key: WFCORE-119
> URL: https://issues.jboss.org/browse/WFCORE-119
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Michael Voegele
> Assignee: Joe Wertz
> Labels: expression, read-resource
> Fix For: 1.0.0.Alpha9
>
>
> When reading a resource remotely, it would be nice to have the possibility to have expressions resolved.
> Following does of course not work, as the code runs in a separate jvm.
> {code:java}
> private void readRecursive(ModelNode modelNode, String modelNodeName, Map<String, Object> map) {
> switch (modelNode.getType()) {
> ...
> case EXPRESSION:
> // this would be great but won't work as it runs in a different jvm
> // ModelNode expression = modelNode.resolve();
> // readRecursive(expression, modelNodeName, map);
> map.put(modelNodeName, modelNode.asString());
> break;
> ...
> }
> {code}
> Therefore a param resolve-expressions for the read-resource operation would be good.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1634) Wrong cursor position after deleting all characters in second line
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1634?page=com.atlassian.jira.plugi... ]
Tomas Hofman updated WFCORE-1634:
---------------------------------
Description:
In CLI, when typing expression that stretches more then one line, and then deleting all characters in the last line (using backspace), cursor appears on wrong position on the previous line (should be on last column, but is on column before the last).
Further editing messes up the displayed expression, which doesn't reflect the real content of the buffer.
*Reproducing:*
* Terminal width is 80 characters.
* [] marks a cursor position.
Step 1. - I have expression spreading over two lines like this:
{code}
[standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection-
factory[]
{code}
Step 2. - Delete "factory" word using backspace:
{code}
[standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection-
[]
{code}
Step 3. - Another backspace:
{code}
[standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connectio[n]
{code}
while expected is:
{code}
[standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection[]
{code}
Step 4. - Another backspace:
{code}
[standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connecti[]n
{code}
while expected is:
{code}
[standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connectio[]
{code}
was:
In CLI, when typing expression that stretches more then one line, and then deleting all characters in the last line (using backspace), cursor appears on wrong position on the previous line (should be on last column, but is on column before the last).
Further editing messes up the displayed expression, which doesn't reflect the real content of the buffer.
Example:
* Terminal width is 80 characters.
* [] marks a cursor position.
Step 1. - I have expression spreading over two lines like this:
{code}
[standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection-
factory[]
{code}
Step 2. - Delete "factory" word using backspace:
{code}
[standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection-
[]
{code}
Step 3. - Another backspace:
{code}
[standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connectio[n]
{code}
while expected is:
{code}
[standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection[]
{code}
> Wrong cursor position after deleting all characters in second line
> ------------------------------------------------------------------
>
> Key: WFCORE-1634
> URL: https://issues.jboss.org/browse/WFCORE-1634
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha3
> Environment: Fedora 24
> Gnome Terminal 3.20
> Bash 4.3.42
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> In CLI, when typing expression that stretches more then one line, and then deleting all characters in the last line (using backspace), cursor appears on wrong position on the previous line (should be on last column, but is on column before the last).
> Further editing messes up the displayed expression, which doesn't reflect the real content of the buffer.
> *Reproducing:*
> * Terminal width is 80 characters.
> * [] marks a cursor position.
> Step 1. - I have expression spreading over two lines like this:
> {code}
> [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection-
> factory[]
> {code}
> Step 2. - Delete "factory" word using backspace:
> {code}
> [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection-
> []
> {code}
> Step 3. - Another backspace:
> {code}
> [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connectio[n]
> {code}
> while expected is:
> {code}
> [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection[]
> {code}
> Step 4. - Another backspace:
> {code}
> [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connecti[]n
> {code}
> while expected is:
> {code}
> [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connectio[]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-7019) [11.0.x] Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-7019?page=com.atlassian.jira.plugin.... ]
Richard Janík updated WFLY-7019:
--------------------------------
Tester: Richard Janík
Description:
This issue has resurfaced with 11.0.0.Alpha1-SNAPSHOT. It has been previously reported and fixed in 10.1.0.Final.
See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect. This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. I'm adding our security team members as watchers.
I'm trying to create a test in the WildFly integration testsuite, but I'm currently failing ([1]). The test I have written is currently passing. I don't know why yet, but either the test is bad or there might be something specific about the issue. The reproducer from JBEAP-1282 still works (in other words, it is failing now that the issue has appeared again).
[1]: https://github.com/LittleJohnII/wildfly/blob/sso-logout/testsuite/integra... see testLogoutWithClusteredSSO
was:
See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
Fix Version/s: (was: 10.1.0.CR1)
(was: 10.1.0.Final)
Priority: Major (was: Blocker)
Affects Version/s: 11.0.0.Alpha1
> [11.0.x] Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-7019
> URL: https://issues.jboss.org/browse/WFLY-7019
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Richard Janík
> Assignee: Stuart Douglas
>
> This issue has resurfaced with 11.0.0.Alpha1-SNAPSHOT. It has been previously reported and fixed in 10.1.0.Final.
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect. This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. I'm adding our security team members as watchers.
> I'm trying to create a test in the WildFly integration testsuite, but I'm currently failing ([1]). The test I have written is currently passing. I don't know why yet, but either the test is bad or there might be something specific about the issue. The reproducer from JBEAP-1282 still works (in other words, it is failing now that the issue has appeared again).
> [1]: https://github.com/LittleJohnII/wildfly/blob/sso-logout/testsuite/integra... see testLogoutWithClusteredSSO
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1379) service.bat points user to wrong directory
by stephan schärli (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1379?page=com.atlassian.jira.plugi... ]
stephan schärli commented on WFCORE-1379:
-----------------------------------------
I can install wildfly 10.1.0.Final as a windows service but I cannot start it without an error. But if I copy the service directory from my wildfly 8.1.0.Final installation to the bin directory of wildfly 10.1.0 it works.
> service.bat points user to wrong directory
> ------------------------------------------
>
> Key: WFCORE-1379
> URL: https://issues.jboss.org/browse/WFCORE-1379
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 2.0.10.Final
> Reporter: Nicklas Karlsson
> Assignee: Tomaz Cerar
> Priority: Trivial
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> Running service.bat from the docs/contrib/scripts/service dir tells user to run the script under bin/service*s* but the binary paths to the services expects bin/service, resulting in service install failure with file not found
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-7019) [11.0.x] Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Richard Janík (JIRA)
Richard Janík created WFLY-7019:
-----------------------------------
Summary: [11.0.x] Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
Key: WFLY-7019
URL: https://issues.jboss.org/browse/WFLY-7019
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Richard Janík
Assignee: Stuart Douglas
Priority: Blocker
Fix For: 10.1.0.CR1, 10.1.0.Final
See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-7016) Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7016?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-7016:
------------------------------------
Assignee: Paul Ferraro (was: Stuart Douglas)
> Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-7016
> URL: https://issues.jboss.org/browse/WFLY-7016
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Matthew Casperson
> Assignee: Paul Ferraro
>
> We have the following code in a ServletRequestListener:
> {code}
> final HttpSession httpSession = httpRequest.getSession(false);
> {code}
> This code is the line:
> {code}
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94)
> {code}
> in the stack trace below.
> We have been running applications with this listener in WildFly 10 for months without any issues, but when we migrated to WildFly 10.1, Infinispan started throwing exceptions when opening the app for the first time. The exception doesn't always happen, but often enough to make WildFly 10.1 unusable.
> The configuration was copied directly from WildFly 10 to WildFly 10.1, so there are no configuration changes between the two versions.
> {code}
> [Server:main-server] 2016-08-26 15:03:10+1000 ERROR [[io.undertow.request]] [[default task-32]] UT005023: Exception handling request to /app/retrieve_quote.jsp: java.lang.IllegalStateException: Transaction TransactionImple < ac, BasicAction: 0:ffff0a1617d4:6cdfa442:57bfb3cd:31b status: ActionStatus.COMMITTED > is not in a valid state to be invoking cache operations on.
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:351)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:177)
> [Server:main-server] at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:154)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> [Server:main-server] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> [Server:main-server] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> [Server:main-server] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> [Server:main-server] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [Server:main-server] at org.wildfly.clustering.server.registry.CacheRegistry.getEntry(CacheRegistry.java:128)
> [Server:main-server] at org.wildfly.clustering.web.infinispan.session.InfinispanRouteLocator.locate(InfinispanRouteLocator.java:58)
> [Server:main-server] at org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodec.encode(DistributableSessionIdentifierCodec.java:48)
> [Server:main-server] at org.wildfly.extension.undertow.session.CodecSessionConfig.findSessionId(CodecSessionConfig.java:60)
> [Server:main-server] at io.undertow.servlet.spec.ServletContextImpl$ServletContextSessionConfig.findSessionId(ServletContextImpl.java:1084)
> [Server:main-server] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:778)
> [Server:main-server] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> [Server:main-server] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:375)
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94)
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.requestInitialized(SessionInvalidatorListener.java:52)
> [Server:main-server] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [Server:main-server] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [Server:main-server] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [Server:main-server] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> [Server:main-server] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on JBJCA-1329:
----------------------------------------
Ok. Thank you guys for verification and help in understanding of this issue. By my understanding that current behaviour is expected and my tests do not show any other problem. I think that this issue could be marked as resolved when ironjacamar PR pull/564 will be merged. Is that ok from your point of view [~maeste]?
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages.
> If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3].
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> [2]
> {code}
> 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]
> {code}
> [3]
> {quote}
> The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months