[JBoss JIRA] (WFWIP-118) Transaction remained in prepared state
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFWIP-118?page=com.atlassian.jira.plugin.... ]
Clebert Suconic commented on WFWIP-118:
---------------------------------------
The auto-registry expects a cluster, this is not clustered.
both artemis 1.x, master and
2.6.x are the same...
last change into
https://github.com/rh-messaging/artemis-wildfly-integration.git was back in 2015. The integration here did not need to be changed.
What happens:
MDB connects with a connectionFactory(initialConnectors=server1,server2);
Recovery registers a connectionFactory(initialConnectors=server1, server2);
The Serverlocator will randomly choose one of the 2 connectors. But the topology will return a single node.
Only one will be used for recovery.
The MDBs may connect to a different node. I'm not sure they will
ballance or not now. (I believe they won't, I believe they will stick
to a single node).
You could either register recovery manually to both servers. or we
could improve the Recovery Discovery to also register the connections
on the initialConnectors... but this would be an improvement and it
would be far away from the upgrade.
> Transaction remained in prepared state
> --------------------------------------
>
> Key: WFWIP-118
> URL: https://issues.jboss.org/browse/WFWIP-118
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Erich Duda
> Assignee: Kabir Khan
> Priority: Blocker
>
> *Scenario*
> * Start group A of two servers (node-1 and node-3) Servers are not in cluster.
> * Send messages to queue on node-1.
> * Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
> * Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
> * Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
> * Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
> After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
> Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
> *Investigation of issue is in progress. It is not known what component causes it.*
> Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
> {quote}I looked at the output from the clients, and filtered the processing
> for one XA that's never commited..
> I looked for the XID on
> base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
> and filtered the onMessage that generated it (attached the log as
> processingOneMessage.txt):
> This XID was never commited simply because the TM never did it.
> Probably because of some issue on the JDBC.. but there are no errors,
> no exceptions.. totally clean on artemis side.
> There are no logging for TM or the MDB itself to correlate other
> failures. With the information I have I am certain there were nothing
> from Artemis side that would have caused it.
> In any case.. this is not replicated at all.. and not related to 87.
> This is simply the TM getting confused for some issue on the JDBC.
> As far as I am concerned I have fixed the replicated shutdown case.
> and i will send PRs upstream now.{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10903) Review documentation for outbound LDAP connections used by legacy security realms.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-10903:
---------------------------------------
Summary: Review documentation for outbound LDAP connections used by legacy security realms.
Key: WFLY-10903
URL: https://issues.jboss.org/browse/WFLY-10903
Project: WildFly
Issue Type: Task
Components: Documentation
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 14.0.0.CR1
WFCORE-2647 added a new option to always send the servers certificate on all connections.
Additionally reviewing the current documentation it does not appear to mention LDAPS at all and I dont' see a security-realm reference.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10897) Inefficient read of the entire resource tree in messaging subsystem socket binding analysis
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-10897?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFLY-10897:
------------------------------------------
This work has been integrated into WFLY-10518_artemis-2.x branch so it should we closed with the RFE integration
> Inefficient read of the entire resource tree in messaging subsystem socket binding analysis
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-10897
> URL: https://issues.jboss.org/browse/WFLY-10897
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
>
> The isOutBoundSocketBinding utility method is performing a read of the entire model. Worse, it gets called inside a loop.
> Just non-recursively read the s-b-g names, and then non-recursively read each s-b-g (in reality there will only be one) to find the children.
> For bonus points, pass in the entire list of a names and return a LinkedHashMap<String, Boolean> and process everything with one pair of reads instead of repeating for each name.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-90) Undelivered messages in remote jca topology after restart
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-90?page=com.atlassian.jira.plugin.s... ]
Erich Duda updated WFWIP-90:
----------------------------
Summary: Undelivered messages in remote jca topology after restart (was: [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart)
> Undelivered messages in remote jca topology after restart
> ---------------------------------------------------------
>
> Key: WFWIP-90
> URL: https://issues.jboss.org/browse/WFWIP-90
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, Clustering
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
>
> There are undelivered messages in scenario with where servers in remote JCA topology are restarted. There are undelivered message after test.
> Test scenario:
> * Start 2 server in Artemis cluster
> * Start 2 servers with MDB connected to Artemis cluster
> ** MDB resends messages from InQueue to OutQueue from/to remote cluster
> * Send messages to InQueue
> * Restart all server (one by one)
> * Consumes messages from OutQueue
> Results:
> After the test there are missing messages in OutQueue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2888) Data Type UX - dialog enhancements: Add and Reorder
by Guilherme Carreiro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2888?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro commented on DROOLS-2888:
--------------------------------------------
Ok! Thank you [~uxdlc] :)
> Data Type UX - dialog enhancements: Add and Reorder
> ----------------------------------------------------
>
> Key: DROOLS-2888
> URL: https://issues.jboss.org/browse/DROOLS-2888
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: Screen Shot 2018-08-17 at 4.29.29 PM.png, previous.gif, viewMoreLess.gif
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * Add fields first to last, not last to first, in an ordered list to support the "reading" order of the fields so that I can simplify my workflow.
> * Reorder the list of Custom data types so that I can arrange data types in a logical order.
> * Add list items in such a way that added Fields will be presented at the bottom of a structured list by default.
> Functional considerations/ pre conditions:
> * Fields will be presented at the bottom of a structured list by default.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> * Drag-n-drop be evaluated with regard to accessibility.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-118) Transaction remained in prepared state
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFWIP-118?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka commented on WFWIP-118:
---------------------------------------
I investigated the logs with Narayana tracing. I chose one specific transaction id for which the artemis id is {{AAAAAAAAAAAAAP__ChBkGhsIAclbe72lAAAGqwAAAAIAAAAAAAAAAAAAAAAAAP__ChBkGhsIAclbe72lAAAGgjY3MzgHAgIA}}.
This belongs to Narayana global id {{0:ffff0a10641a:1b0801c9:5b7bbda5:682}} and this branch id is {{0:ffff0a10641a:1b0801c9:5b7bbda5:6ab}}. The snippet from log is
{code}
TRACE [com.arjuna.ats.jta] (Thread-26 (ActiveMQ-client-global-threads)) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:6ab, subordinatenodename=null, eis_name=java:/JmsXA NodeId:c180112b-a512-11e8-856b-0015178e70d2 >, XAResourceWrapperImpl@3beb35f7[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)efa9a8c pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:c180112b-a512-11e8-856b-0015178e70d2] ), record id=0:ffff0a10641a:1b0801c9:5b7bbda5:6ac
TRACE [org.apache.activemq.artemis.ra] (Thread-26 (ActiveMQ-client-global-threads)) start(< formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:6ab, subordinatenodename=null, eis_name=java:/JmsXA NodeId:c180112b-a512-11e8-856b-0015178e70d2 >, 0)
TRACE [org.apache.activemq.artemis.ra] (Thread-26 (ActiveMQ-client-global-threads)) lock()
TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Thread-26 (ActiveMQ-client-global-threads)) Calling start:: xid=XidImpl (1453388228 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.10.16.100.26.27.8.1.-55.91.123.-67.-91.0.0.6.-85.0.0.0.2.0.0.0.0 formatID:131077 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.10.16.100.26.27.8.1.-55.91.123.-67.-91.0.0.6.-126.54.55.51.56 base64:AAAAAAAAAAAAAP__ChBkGhsIAclbe72lAAAGqwAAAAIAAAAAAAAAAAAAAAAAAP__ChBkGhsIAclbe72lAAAGgjY3MzgHAgIA,clientXID=< formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:6ab, subordinatenodename=null, eis_name=java:/JmsXA NodeId:c180112b-a512-11e8-856b-0015178e70d2 > clientXID=< formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:6ab, subordinatenodename=null, eis_name=java:/JmsXA NodeId:c180112b-a512-11e8-856b-0015178e70d2 > flags = TMNOFLAGS
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-26 (ActiveMQ-client-global-threads)) RemotingConnectionID=f3f899da Sending blocking PACKET(SessionXAStartMessage)[type=51, channelID=11, packetObject=SessionXAStartMessage, xid=< formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:6ab, subordinatenodename=null, eis_name=java:/JmsXA NodeId:c180112b-a512-11e8-856b-0015178e70d2 >]
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-3 (ActiveMQ-client-netty-threads)) RemotingConnectionID=f3f899da handling packet PACKET(SessionXAResponseMessage)[type=55, channelID=11, packetObject=SessionXAResponseMessage, error=false, message=null, responseCode=0]
{code}
The participants of this transacitons are
* in-VM messaging {{java:/LocalJmsXA}}
* remote messaging {{java:/JmsXA}}
* database {{java:/jdbc/lodhDS}}
The scenario for these transactions is that the server is killed at time when prepare phase was not completely finished. It means they are considered by periodic recovery for roll-back. Observing other transactions which were hit by the 'server kill' at time the prepare phase already finished and they should be committed by recovery they are correctly committed.
The issue here seems to be with *not* getting information about in-doubt transactions from the remote JMS server. It seems the [XAResource#recover|https://docs.oracle.com/javaee/7/api/javax/transaction...] returns no records for them being rolled-back.
In case of the remote jms server where issue seems to be {{java:/JmsXA}} the output of the recover call is {{(Periodic Recovery) Found 0 xids in doubt}}
{code}
DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl] (Periodic Recovery) ClientSessionFactoryImpl received backup update for live/backup pair = TransportConfiguration(name=, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=11080&localAddress=127-0-0-1&host=127-0-0-1 / null but it didn't belong to TransportConfiguration(name=, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=11080&localAddress=127-0-0-1&host=127-0-0-1
TRACE [org.apache.activemq.artemis.logs] (Periodic Recovery) Saving string with utfSize=36 stringSize=36
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) RemotingConnectionID=d036646a Sending blocking PACKET(CreateSessionMessage)[type=30, channelID=1, packetObject=CreateSessionMessage, autoCommitAcks=false, autoCommitSends=false, defaultAddress=null, minLargeMessageSize=102400, name=6a2ee590-a513-11e8-887d-001b217d6d93, password=****, preAcknowledge=false, sessionChannelID=10, username=null, version=129, windowSize=-1, xa=true]
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-16 (ActiveMQ-client-netty-threads)) RemotingConnectionID=d036646a handling packet PACKET(CreateSessionResponseMessage)[type=31, channelID=1, packetObject=CreateSessionResponseMessage, serverVersion=129]
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) RemotingConnectionID=d036646a Setting handler on Channel[id=USER, RemotingConnectionID=d036646a, handler=null] as org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext$ClientSessionPacketHandler@77db1ee4
DEBUG [org.apache.activemq.artemis.service.extensions.xa.recovery] (Periodic Recovery) looking for recover at ClientSessionImpl [name=6a2ee590-a513-11e8-887d-001b217d6d93, username=null, closed=false, factory = org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@1e875326, metaData=()]@1e35f8e0 configuration [XARecoveryConfig [transportConfiguration=[TransportConfiguration(name=, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=11080&localAddress=127-0-0-1&host=127-0-0-1], discoveryConfiguration=null, username=null, password=****, JNDI_NAME=java:/JmsXA]]
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) RemotingConnectionID=d036646a Sending blocking PACKET(PacketImpl)[type=61, channelID=10, packetObject=PacketImpl]
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-2 (ActiveMQ-client-global-scheduled-threads)) RemotingConnectionID=d036646a Sending packet nonblocking PACKET(Ping)[type=10, channelID=0, packetObject=Ping, connectionTTL=60000] on channelID=0
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-2 (ActiveMQ-client-global-scheduled-threads)) RemotingConnectionID=d036646a Writing buffer for channelID=0
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-16 (ActiveMQ-client-netty-threads)) RemotingConnectionID=d036646a handling packet PACKET(Ping)[type=10, channelID=0, packetObject=Ping, connectionTTL=60000]
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-16 (ActiveMQ-client-netty-threads)) RemotingConnectionID=d036646a handling packet PACKET(SessionXAGetInDoubtXidsResponseMessage)[type=62, channelID=10, packetObject=SessionXAGetInDoubtXidsResponseMessage, xids=[]]
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Found 0 xids in doubt
{code}
When checking the other two participants (database and in-VM messaging) they responses with list of the in-doubt transactions to the periodic recovery and the transactions are then correctly rolled-back
{code}
TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff0a10641a:1b0801c9:5b7bbda5:682, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL)
TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff0a10641a:1b0801c9:5b7bbda5:682, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 11)
TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff0a10641a:1b0801c9:5b7bbda5:682, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) - returning StateStatus.OS_UNKNOWN
TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state could not find committed or uncommitted state for 0:ffff0a10641a:1b0801c9:5b7bbda5:682 instead found state StateStatus.OS_UNKNOWN
TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff0a10641a:1b0801c9:5b7bbda5:682, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW)
TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff0a10641a:1b0801c9:5b7bbda5:682, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10)
TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff0a10641a:1b0801c9:5b7bbda5:682, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff0a10641a:1b0801c9:5b7bbda5:682, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11)
TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff0a10641a:1b0801c9:5b7bbda5:682, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_UNKNOWN
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:686, subordinatenodename=null, eis_name=java:/LocalJmsXA NodeId:b5847054-a512-11e8-b703-0015178e70d2 >
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted ABSTAIN
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:686, subordinatenodename=null, eis_name=java:/LocalJmsXA NodeId:b5847054-a512-11e8-b703-0015178e70d2 > is 6738
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:686, subordinatenodename=null, eis_name=java:/LocalJmsXA NodeId:b5847054-a512-11e8-b703-0015178e70d2 > is null
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateJTAXAResourceOrphanFilter voted ABSTAIN
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:686, subordinatenodename=null, eis_name=java:/LocalJmsXA NodeId:b5847054-a512-11e8-b703-0015178e70d2 > is null
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinationManagerXAResourceOrphanFilter voted ABSTAIN
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:686, subordinatenodename=null, eis_name=java:/LocalJmsXA NodeId:b5847054-a512-11e8-b703-0015178e70d2 > is 6738
DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTAActionStatusServiceXAResourceOrphanFilter voted ABSTAIN
INFO [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016013: Rolling back < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:686, subordinatenodename=null, eis_name=java:/LocalJmsXA NodeId:b5847054-a512-11e8-b703-0015178e70d2 >
DEBUG [org.apache.activemq.artemis.service.extensions.xa.recovery] (Periodic Recovery) Rollback ClientSessionImpl [name=6a29192d-a513-11e8-887d-001b217d6d93, username=null, closed=false, factory = org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@1649da86, metaData=()]@39a1f4be xid
TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Periodic Recovery) Calling rollback:: xid=XidImpl (766297512 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.10.16.100.26.27.8.1.-55.91.123.-67.-91.0.0.6.-122.0.0.0.1.0.0.0.0 formatID:131077 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.10.16.100.26.27.8.1.-55.91.123.-67.-91.0.0.6.-126.54.55.51.56 base64:AAAAAAAAAAAAAP__ChBkGhsIAclbe72lAAAGhgAAAAEAAAAAAAAAAAAAAAAAAP__ChBkGhsIAclbe72lAAAGgjY3MzgHAgIA,clientXID=< formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:686, subordinatenodename=null, eis_name=java:/LocalJmsXA NodeId:b5847054-a512-11e8-b703-0015178e70d2 >
TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) RemotingConnectionID=6a282ecb-a513-11e8-887d-001b217d6d93 Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage, xid=< formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:682, node_name=6738, branch_uid=0:ffff0a10641a:1b0801c9:5b7bbda5:686, subordinatenodename=null, eis_name=java:/LocalJmsXA NodeId:b5847054-a512-11e8-b703-0015178e70d2 >]
{code}
> Transaction remained in prepared state
> --------------------------------------
>
> Key: WFWIP-118
> URL: https://issues.jboss.org/browse/WFWIP-118
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Erich Duda
> Assignee: Kabir Khan
> Priority: Blocker
>
> *Scenario*
> * Start group A of two servers (node-1 and node-3) Servers are not in cluster.
> * Send messages to queue on node-1.
> * Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
> * Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
> * Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
> * Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
> After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
> Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
> *Investigation of issue is in progress. It is not known what component causes it.*
> Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
> {quote}I looked at the output from the clients, and filtered the processing
> for one XA that's never commited..
> I looked for the XID on
> base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
> and filtered the onMessage that generated it (attached the log as
> processingOneMessage.txt):
> This XID was never commited simply because the TM never did it.
> Probably because of some issue on the JDBC.. but there are no errors,
> no exceptions.. totally clean on artemis side.
> There are no logging for TM or the MDB itself to correlate other
> failures. With the information I have I am certain there were nothing
> from Artemis side that would have caused it.
> In any case.. this is not replicated at all.. and not related to 87.
> This is simply the TM getting confused for some issue on the JDBC.
> As far as I am concerned I have fixed the replicated shutdown case.
> and i will send PRs upstream now.{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-21) [Artemis 2.x upgrade] Lost message when MDB is resending messages under high load
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-21?page=com.atlassian.jira.plugin.s... ]
Erich Duda commented on WFWIP-21:
---------------------------------
Sure [~martyn-taylor] Here is the link: https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
> [Artemis 2.x upgrade] Lost message when MDB is resending messages under high load
> ---------------------------------------------------------------------------------
>
> Key: WFWIP-21
> URL: https://issues.jboss.org/browse/WFWIP-21
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Test scenario:
> * Start cluster A of nodes node-1, node-3
> * Start cluster B of nodes node-2, node-4
> * Send messages to queue on node-1
> * Deploy mdbs to servers in cluster A. This mdb reads messages from local queue, sends them to remote queue on cluster B and inserts them into database
> * Deploy mdbs to servers in cluster B. This mdb reads messages from local queue and inserts them into database
> * Cause CPU overload (for 5 min) on server node-2 when mdbs on cluster1 and 2 are processing mesages
> * Restart failed server
> * Let MDBs to process remaining messages
> Pass Criteria: Number of sent message is equal number of records(lines) in database and messages in
> Actual Result:
> Sometimes happens that one record is missing in database which means that one message was not processed be MDB in cluster 2.
> This looks like broker related regression against Artemis 1.5.
> Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis tag 2.5.0.Final
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months