August 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ] Tom Jenkinson commented on JBJCA-1329: -------------------------------------- Hi Ondra, I guess you did some more analysis and determined the cause was JCA? Do you have a link to the spec where it says you should get an error message rather than allow the multiple work units? Also, does https://issues.jboss.org/browse/JBEAP-5732 need some work to align it with the upstream issue now? > 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: Jesper Pedersen > > 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}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[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 updated JBJCA-1329: ----------------------------------- Attachment: (was: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log) > 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: Jesper Pedersen > > 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}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7001) CLI 'deployment-info --headers' throws errors in standalone mode

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created WFLY-7001: ---------------------------------------- Summary: CLI 'deployment-info --headers' throws errors in standalone mode Key: WFLY-7001 URL: https://issues.jboss.org/browse/WFLY-7001 Project: WildFly Issue Type: Bug Reporter: Bartosz Baranowski Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7000) Batch jobs from installed modules should be detected for non-batch app

by Mincong Huang (JIRA)

Mincong Huang created WFLY-7000: ----------------------------------- Summary: Batch jobs from installed modules should be detected for non-batch app Key: WFLY-7000 URL: https://issues.jboss.org/browse/WFLY-7000 Project: WildFly Issue Type: Bug Components: Batch Affects Versions: 10.0.0.Final Reporter: Mincong Huang Assignee: Cheng Fang Hibernate Search is creating a batch job which embedded in a WildFly module. Any user of Hibernate Search should be able to the launch this batch job, no matter if they're using a batch-app. However, it seems that jobs are only resolvable for batch-app. More explicitly, WildFly requires deployed web-app to have the below structure to enable the job resolver: META-INF/batch-jobs For those who don't have this batch folder in their webapp, they cannot use the jobs from installed module. And an error "JBERET000601: Failed to get job xml file for job" will be raised. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1731) Exception generated from command "connection-info"

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1731?page=com.atlassian.jira.plugi... ] Petr Kremensky updated WFCORE-1731: ----------------------------------- Component/s: Domain Management Security > Exception generated from command "connection-info" > -------------------------------------------------- > > Key: WFCORE-1731 > URL: https://issues.jboss.org/browse/WFCORE-1731 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management, Security > Affects Versions: 3.0.0.Alpha5 > Environment: JBoss Admin Command-line Interface > JBOSS_HOME: C:\dev\jboss-eap-7.0.1 > JBoss AS release: 2.1.6.Final-redhat-1 "Kenny" > JBoss AS product: JBoss EAP 7.0.1.GA > JAVA_HOME: c:\java\jdk1.8.0_45 > java.version: 1.8.0_45 > java.vm.vendor: Oracle Corporation > java.vm.version: 25.45-b02 > os.name: Windows 7 > os.version: 6.1 > Reporter: Petr Kremensky > Assignee: Alexey Loubyansky > Priority: Minor > > I started the embedded server and tried to obtain the connection information. An exception occurred: > {code} > [standalone@embedded /] connection-info > 13:14:59,095 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 32) WFLYCTL0013: Operation ("whoami") failed - address: ([]): java.lang.IllegalArgumentException: newValue is null > at org.jboss.dmr.ModelNode.set(ModelNode.java:499) > at org.jboss.as.domain.management.security.WhoAmIOperation.execute(WhoAmIOperation.java:95) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204) > at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659) > at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649) > at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63) > at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59) > at org.jboss.as.cli.handlers.ConnectionInfoHandler.doHandle(ConnectionInfoHandler.java:74) > at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88) > at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:776) > at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:799) > at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:412) > at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53) > 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) > WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null > Failed to handle 'connection-info': java.lang.NullPointerException > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1731) Exception generated from command "connection-info"

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1731?page=com.atlassian.jira.plugi... ] Petr Kremensky moved JBEAP-5753 to WFCORE-1731: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1731 (was: JBEAP-5753) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: Domain Management) (was: Security) Affects Version/s: 3.0.0.Alpha5 (was: 7.0.0.GA) (was: 7.0.1.GA) > Exception generated from command "connection-info" > -------------------------------------------------- > > Key: WFCORE-1731 > URL: https://issues.jboss.org/browse/WFCORE-1731 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha5 > Environment: JBoss Admin Command-line Interface > JBOSS_HOME: C:\dev\jboss-eap-7.0.1 > JBoss AS release: 2.1.6.Final-redhat-1 "Kenny" > JBoss AS product: JBoss EAP 7.0.1.GA > JAVA_HOME: c:\java\jdk1.8.0_45 > java.version: 1.8.0_45 > java.vm.vendor: Oracle Corporation > java.vm.version: 25.45-b02 > os.name: Windows 7 > os.version: 6.1 > Reporter: Petr Kremensky > Assignee: Alexey Loubyansky > Priority: Minor > > I started the embedded server and tried to obtain the connection information. An exception occurred: > {code} > [standalone@embedded /] connection-info > 13:14:59,095 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 32) WFLYCTL0013: Operation ("whoami") failed - address: ([]): java.lang.IllegalArgumentException: newValue is null > at org.jboss.dmr.ModelNode.set(ModelNode.java:499) > at org.jboss.as.domain.management.security.WhoAmIOperation.execute(WhoAmIOperation.java:95) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204) > at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659) > at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649) > at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63) > at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59) > at org.jboss.as.cli.handlers.ConnectionInfoHandler.doHandle(ConnectionInfoHandler.java:74) > at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88) > at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:776) > at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:799) > at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:412) > at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53) > 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) > WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null > Failed to handle 'connection-info': java.lang.NullPointerException > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6998) problem with lazy relationship and eclipselink 2.6.3 on wildfly 10 final

by Christopher Willems (JIRA)

[ https://issues.jboss.org/browse/WFLY-6998?page=com.atlassian.jira.plugin.... ] Christopher Willems commented on WFLY-6998: ------------------------------------------- new log uploaded > problem with lazy relationship and eclipselink 2.6.3 on wildfly 10 final > ------------------------------------------------------------------------ > > Key: WFLY-6998 > URL: https://issues.jboss.org/browse/WFLY-6998 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Christopher Willems > Assignee: Scott Marlow > Attachments: server.zip, server.zip > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6998) problem with lazy relationship and eclipselink 2.6.3 on wildfly 10 final

by Christopher Willems (JIRA)

[ https://issues.jboss.org/browse/WFLY-6998?page=com.atlassian.jira.plugin.... ] Christopher Willems updated WFLY-6998: -------------------------------------- Attachment: server.zip > problem with lazy relationship and eclipselink 2.6.3 on wildfly 10 final > ------------------------------------------------------------------------ > > Key: WFLY-6998 > URL: https://issues.jboss.org/browse/WFLY-6998 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Christopher Willems > Assignee: Scott Marlow > Attachments: server.zip, server.zip > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[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 reassigned JBJCA-1329: -------------------------------------- Assignee: Jesper Pedersen (was: Tom Jenkinson) > 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: Jesper Pedersen > > 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}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[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 updated JBJCA-1329: ----------------------------------- Attachment: (was: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log) > 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: Jesper Pedersen > > 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}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 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 August 2016