[JBoss JIRA] (JBTM-1303) WS-AT client can return from commit before all participants have committed
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1303?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1303:
-------------------------------------
I'm not seeing this happen when I try to reproduce the behaviour. I need to check with Andrew that I've not misunderstood this when he explained the issue to me.
> WS-AT client can return from commit before all participants have committed
> --------------------------------------------------------------------------
>
> Key: JBTM-1303
> URL: https://issues.jboss.org/browse/JBTM-1303
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Paul Robinson
>
> Normally, when a WS-AT client calls commit, the coordinator will wait until all participants are committed before returning to the client. This ensures that the Client doesn't continue processing until all changes have been made permanent and visible.
> If the participant takes longer than 30s to return the 'committed' message, the participant logs the fact and then returns to the client. The recovery mechanism will then handle the sending of the commit message to the participant. As WS-AT doesn't support heuristics, the participant is guaranteed to commit eventually, but after at least one recovery scan. This means that the client may think that the work done, in the transaction, is now visible when in actual fact it is not quite yet.
> h3. Potential solutions
> h4. Return CommittingException
> As a JBoss only solution (it would break the standard), we could throw a CommittingException when the coordinator returns control to the client after delegating to the recovery manager to commit the outstanding participant(s). The client then know that the work will commit, but it's not completed yet. Handling of this exception could be to either ignore it, or poll the resource until the change is visible. This could work for both synchronous and asynchronous clients.
> h4. Delay the return until participants really have committed.
> This is unlikely to work for the (JBoss only) synchronous client as the connection is unlikely to stay open long enough. However, it could work for the asynchronous scenario, but would require the client to increase the timeout to include the amount of time it takes for the coordinator to give up waiting for committed and delegate to the recovery manager, plus enough time for the recovery scan to occur and receive the committed message. Also, the client endpoint information would need to be stored in the recovery log, so that the recovery manager can attempt notification (which would also need implementing).
> h4. Document the issue for now
> ... and implement a solution if/when we get a user with this problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1303) WS-AT client can return from commit before all participants have committed
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1303?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1303:
--------------------------------
Component/s: XTS
> WS-AT client can return from commit before all participants have committed
> --------------------------------------------------------------------------
>
> Key: JBTM-1303
> URL: https://issues.jboss.org/browse/JBTM-1303
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Paul Robinson
>
> Normally, when a WS-AT client calls commit, the coordinator will wait until all participants are committed before returning to the client. This ensures that the Client doesn't continue processing until all changes have been made permanent and visible.
> If the participant takes longer than 30s to return the 'committed' message, the participant logs the fact and then returns to the client. The recovery mechanism will then handle the sending of the commit message to the participant. As WS-AT doesn't support heuristics, the participant is guaranteed to commit eventually, but after at least one recovery scan. This means that the client may think that the work done, in the transaction, is now visible when in actual fact it is not quite yet.
> h3. Potential solutions
> h4. Return CommittingException
> As a JBoss only solution (it would break the standard), we could throw a CommittingException when the coordinator returns control to the client after delegating to the recovery manager to commit the outstanding participant(s). The client then know that the work will commit, but it's not completed yet. Handling of this exception could be to either ignore it, or poll the resource until the change is visible. This could work for both synchronous and asynchronous clients.
> h4. Delay the return until participants really have committed.
> This is unlikely to work for the (JBoss only) synchronous client as the connection is unlikely to stay open long enough. However, it could work for the asynchronous scenario, but would require the client to increase the timeout to include the amount of time it takes for the coordinator to give up waiting for committed and delegate to the recovery manager, plus enough time for the recovery scan to occur and receive the committed message. Also, the client endpoint information would need to be stored in the recovery log, so that the recovery manager can attempt notification (which would also need implementing).
> h4. Document the issue for now
> ... and implement a solution if/when we get a user with this problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1450) Transaction processing in javascript
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1450?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1450:
--------------------------------
Description:
Student project that we are not currently offering:
{quote}
Increasingly sophisticated applications are being implemented using the javascript language. Initially popular for browser based environments, the language is also gaining traction on the server side (NodeJS, etc). A single threaded model promotes use of callbacks and asynchronous I/O operations. Ongoing standardization work is starting to provide APIs for enterprise functionality (commonJS, IndexedDB, etc). The Rhino javascript engine allows javascript to run on any JVM. These factors lead to situations where distributed business applications may be written wholly or partially in javascript and may need to interact with existing business logic or services implemented in Java. In this project you will consider how to provide transaction management capabilities to such applications.
This project will require a good knowledge of javascript programming, ideally encompassing a server side javascript environment. Candidates should also possess some knowledge of Java and transaction concepts. The work will be open source.
{quote}
was:
Student project that we are not currently offering:
{quote}
Recent developments in web standards (HTML5, specifically Web Storage a.k.a. DOM Storage) indicates a move towards widespread availability of client (i.e. web browser) side persistent storage accessible by web applications. Initially useful for making content and applications available offline, this also open up the possibility of object replication between client and server. In this project you will explore the applicability of transaction concepts to applications built on this model. In particular, you will focus on identifying and exploiting new opportunities made available by the existence of persistent storage on the browser, a vital pre-requisite for recoverable transactions.
To undertake this project you should have a strong interest in web based applications, some javascript programming experience and a basic understanding of transactions concepts. Previous experience of at least one javascript framework would be an advantage. The work will be open source.
{quote}
> Transaction processing in javascript
> ------------------------------------
>
> Key: JBTM-1450
> URL: https://issues.jboss.org/browse/JBTM-1450
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Paul Robinson
> Labels: student
>
> Student project that we are not currently offering:
> {quote}
> Increasingly sophisticated applications are being implemented using the javascript language. Initially popular for browser based environments, the language is also gaining traction on the server side (NodeJS, etc). A single threaded model promotes use of callbacks and asynchronous I/O operations. Ongoing standardization work is starting to provide APIs for enterprise functionality (commonJS, IndexedDB, etc). The Rhino javascript engine allows javascript to run on any JVM. These factors lead to situations where distributed business applications may be written wholly or partially in javascript and may need to interact with existing business logic or services implemented in Java. In this project you will consider how to provide transaction management capabilities to such applications.
> This project will require a good knowledge of javascript programming, ideally encompassing a server side javascript environment. Candidates should also possess some knowledge of Java and transaction concepts. The work will be open source.
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1451) Transactional cloud storage
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1451:
-----------------------------------
Summary: Transactional cloud storage
Key: JBTM-1451
URL: https://issues.jboss.org/browse/JBTM-1451
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Paul Robinson
Student project that we are not currently offering:
{quote}
Increasingly sophisticated applications are being implemented using the javascript language. Initially popular for browser based environments, the language is also gaining traction on the server side (NodeJS, etc). A single threaded model promotes use of callbacks and asynchronous I/O operations. Ongoing standardization work is starting to provide APIs for enterprise functionality (commonJS, IndexedDB, etc). The Rhino javascript engine allows javascript to run on any JVM. These factors lead to situations where distributed business applications may be written wholly or partially in javascript and may need to interact with existing business logic or services implemented in Java. In this project you will consider how to provide transaction management capabilities to such applications.
This project will require a good knowledge of javascript programming, ideally encompassing a server side javascript environment. Candidates should also possess some knowledge of Java and transaction concepts. The work will be open source.
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1451) Transactional cloud storage
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1451?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1451:
--------------------------------
Description:
Student project that we are not currently offering:
{quote}
Many cloud based data storage systems, including the menagerie of NoSQL databases that are currently evolving, lack any significant transaction management capability and universally reject the formerly ubiquitous XA standard for classic 2PC ACID transactions. Whilst there are sound reasons for concluding that ACID transactions are not appropriate in such context, this nonetheless leaves a significant shortfall in capabilities compared to mature SQL based storage solutions. As a result, users are forced to roll their own transaction solutions in the business logic layer, an undesirable situation that cries out for a storage vendor or middleware based solution.
In this project you will examine the transaction handling needs of business systems operating on very large quantities of data, compare it with the capabilities provided by the new generation of storage systems used for handling such quantities, and provide solutions to bridge the gap. This may include investigating e.g. the scope for new transaction management standards and APIs that are appropriate or adaptable to more than one storage system; the use of non-ACID transaction models such as compensations; the interoperability issues that arise in an environment that encompasses not only multiple client and server languages (vis. CORBA) but also multiple transports (REST, thrift, ...); the extension of an existing NoSQL solution with additional transaction capabilities, or the provision of equivalent functionality by integration with 3rd party tools e.g. a distributed lock manager.
This project will require a good understanding of Java and optionally one or more additional languages if you wish to extend a storage system built in a non-Java language. Note that languages targeting the JVM are preferred. You should also have a basic understanding of the NoSQL movement and cloud computing concepts such as elasticity. Some knowledge of relevant concepts such as the CAP theorem and BASE model are preferable but not essential. The work will be open source.
{quote}
was:
Student project that we are not currently offering:
{quote}
Increasingly sophisticated applications are being implemented using the javascript language. Initially popular for browser based environments, the language is also gaining traction on the server side (NodeJS, etc). A single threaded model promotes use of callbacks and asynchronous I/O operations. Ongoing standardization work is starting to provide APIs for enterprise functionality (commonJS, IndexedDB, etc). The Rhino javascript engine allows javascript to run on any JVM. These factors lead to situations where distributed business applications may be written wholly or partially in javascript and may need to interact with existing business logic or services implemented in Java. In this project you will consider how to provide transaction management capabilities to such applications.
This project will require a good knowledge of javascript programming, ideally encompassing a server side javascript environment. Candidates should also possess some knowledge of Java and transaction concepts. The work will be open source.
{quote}
> Transactional cloud storage
> ---------------------------
>
> Key: JBTM-1451
> URL: https://issues.jboss.org/browse/JBTM-1451
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Paul Robinson
> Labels: student
>
> Student project that we are not currently offering:
> {quote}
> Many cloud based data storage systems, including the menagerie of NoSQL databases that are currently evolving, lack any significant transaction management capability and universally reject the formerly ubiquitous XA standard for classic 2PC ACID transactions. Whilst there are sound reasons for concluding that ACID transactions are not appropriate in such context, this nonetheless leaves a significant shortfall in capabilities compared to mature SQL based storage solutions. As a result, users are forced to roll their own transaction solutions in the business logic layer, an undesirable situation that cries out for a storage vendor or middleware based solution.
> In this project you will examine the transaction handling needs of business systems operating on very large quantities of data, compare it with the capabilities provided by the new generation of storage systems used for handling such quantities, and provide solutions to bridge the gap. This may include investigating e.g. the scope for new transaction management standards and APIs that are appropriate or adaptable to more than one storage system; the use of non-ACID transaction models such as compensations; the interoperability issues that arise in an environment that encompasses not only multiple client and server languages (vis. CORBA) but also multiple transports (REST, thrift, ...); the extension of an existing NoSQL solution with additional transaction capabilities, or the provision of equivalent functionality by integration with 3rd party tools e.g. a distributed lock manager.
> This project will require a good understanding of Java and optionally one or more additional languages if you wish to extend a storage system built in a non-Java language. Note that languages targeting the JVM are preferred. You should also have a basic understanding of the NoSQL movement and cloud computing concepts such as elasticity. Some knowledge of relevant concepts such as the CAP theorem and BASE model are preferable but not essential. The work will be open source.
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1449) Transactions in the browser
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1449:
-----------------------------------
Summary: Transactions in the browser
Key: JBTM-1449
URL: https://issues.jboss.org/browse/JBTM-1449
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Paul Robinson
Student project that we are not currently offering:
{quote}
Recent developments in web standards (HTML5, specifically Web Storage a.k.a. DOM Storage) indicates a move towards widespread availability of client (i.e. web browser) side persistent storage accessible by web applications. Initially useful for making content and applications available offline, this also open up the possibility of object replication between client and server. In this project you will explore the applicability of transaction concepts to applications built on this model. In particular, you will focus on identifying and exploiting new opportunities made available by the existence of persistent storage on the browser, a vital pre-requisite for recoverable transactions.
To undertake this project you should have a strong interest in web based applications, some javascript programming experience and a basic understanding of transactions concepts. Previous experience of at least one javascript framework would be an advantage. The work will be open source.
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1450) Transaction processing in javascript
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1450:
-----------------------------------
Summary: Transaction processing in javascript
Key: JBTM-1450
URL: https://issues.jboss.org/browse/JBTM-1450
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Paul Robinson
Student project that we are not currently offering:
{quote}
Recent developments in web standards (HTML5, specifically Web Storage a.k.a. DOM Storage) indicates a move towards widespread availability of client (i.e. web browser) side persistent storage accessible by web applications. Initially useful for making content and applications available offline, this also open up the possibility of object replication between client and server. In this project you will explore the applicability of transaction concepts to applications built on this model. In particular, you will focus on identifying and exploiting new opportunities made available by the existence of persistent storage on the browser, a vital pre-requisite for recoverable transactions.
To undertake this project you should have a strong interest in web based applications, some javascript programming experience and a basic understanding of transactions concepts. Previous experience of at least one javascript framework would be an advantage. The work will be open source.
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1448) Failed to submit/remove Byteman script, because of refused connection
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1448?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1448:
----------------------------------
Description:
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP601/312
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP601/313
{noformat}
Tests in error:
org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase: Failed to submit Byteman script
org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase: Failed to remove Byteman script
{noformat}
{noformat}
java.lang.RuntimeException: Failed to submit Byteman script
at org.jboss.as.test.xts.simple.BMScript.submit(BMScript.java:43)
at org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase.submitBytemanScript(WSBAParticipantCompletionTestCase.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:797)
at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:735)
at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:574)
at org.jboss.byteman.agent.submit.Submit.addRulesFromFiles(Submit.java:547)
at org.jboss.as.test.xts.simple.BMScript.submit(BMScript.java:41)
... 54 more
{noformat}
{noformat}
java.lang.RuntimeException: Failed to remove Byteman script
at org.jboss.as.test.xts.simple.BMScript.remove(BMScript.java:53)
at org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase.removeBytemanScript(WSBAParticipantCompletionTestCase.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.afterClass(EventTestRunnerAdaptor.java:87)
at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:204)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:797)
at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:735)
at org.jboss.byteman.agent.submit.Submit.deleteScripts(Submit.java:646)
at org.jboss.byteman.agent.submit.Submit.deleteRulesFromFiles(Submit.java:619)
at org.jboss.as.test.xts.simple.BMScript.remove(BMScript.java:51)
... 54 more
{noformat}
was:
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP601/312
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP601/313
{noformat}
Tests in error:
org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase: Failed to submit Byteman script
org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase: Failed to remove Byteman script
{noformat}
{noformat}
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:797)
at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:735)
at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:574)
at org.jboss.byteman.agent.submit.Submit.addRulesFromFiles(Submit.java:547)
at org.jboss.as.test.xts.simple.BMScript.submit(BMScript.java:41)
{noformat}
> Failed to submit/remove Byteman script, because of refused connection
> ---------------------------------------------------------------------
>
> Key: JBTM-1448
> URL: https://issues.jboss.org/browse/JBTM-1448
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Fix For: 4.16.7
>
>
> See:
> http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP601/312
> http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP601/313
> {noformat}
> Tests in error:
> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase: Failed to submit Byteman script
> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase: Failed to remove Byteman script
> {noformat}
> {noformat}
> java.lang.RuntimeException: Failed to submit Byteman script
> at org.jboss.as.test.xts.simple.BMScript.submit(BMScript.java:43)
> at org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase.submitBytemanScript(WSBAParticipantCompletionTestCase.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
> at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:529)
> at java.net.Socket.connect(Socket.java:478)
> at java.net.Socket.<init>(Socket.java:375)
> at java.net.Socket.<init>(Socket.java:189)
> at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:797)
> at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:735)
> at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:574)
> at org.jboss.byteman.agent.submit.Submit.addRulesFromFiles(Submit.java:547)
> at org.jboss.as.test.xts.simple.BMScript.submit(BMScript.java:41)
> ... 54 more
> {noformat}
> {noformat}
> java.lang.RuntimeException: Failed to remove Byteman script
> at org.jboss.as.test.xts.simple.BMScript.remove(BMScript.java:53)
> at org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase.removeBytemanScript(WSBAParticipantCompletionTestCase.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
> at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.afterClass(EventTestRunnerAdaptor.java:87)
> at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:529)
> at java.net.Socket.connect(Socket.java:478)
> at java.net.Socket.<init>(Socket.java:375)
> at java.net.Socket.<init>(Socket.java:189)
> at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:797)
> at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:735)
> at org.jboss.byteman.agent.submit.Submit.deleteScripts(Submit.java:646)
> at org.jboss.byteman.agent.submit.Submit.deleteRulesFromFiles(Submit.java:619)
> at org.jboss.as.test.xts.simple.BMScript.remove(BMScript.java:51)
> ... 54 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBTM-1448) Failed to submit/remove Byteman script, because of refused connection
by Gytis Trikleris (JIRA)
Gytis Trikleris created JBTM-1448:
-------------------------------------
Summary: Failed to submit/remove Byteman script, because of refused connection
Key: JBTM-1448
URL: https://issues.jboss.org/browse/JBTM-1448
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Testing, XTS
Reporter: Gytis Trikleris
Assignee: Paul Robinson
Fix For: 4.16.7
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP601/312
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP601/313
{noformat}
Tests in error:
org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase: Failed to submit Byteman script
org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase: Failed to remove Byteman script
{noformat}
{noformat}
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:797)
at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:735)
at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:574)
at org.jboss.byteman.agent.submit.Submit.addRulesFromFiles(Submit.java:547)
at org.jboss.as.test.xts.simple.BMScript.submit(BMScript.java:41)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months