[JBoss JIRA] (JBTM-1831) org.jboss.jbossts.txbridge.tests.outbound.junit.EnabledContextPropagationTests hangs
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1831?page=com.atlassian.jira.plugin.... ]
Paul Robinson resolved JBTM-1831.
---------------------------------
Resolution: Cannot Reproduce Bug
> org.jboss.jbossts.txbridge.tests.outbound.junit.EnabledContextPropagationTests hangs
> ------------------------------------------------------------------------------------
>
> Key: JBTM-1831
> URL: https://issues.jboss.org/browse/JBTM-1831
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TxBridge
> Reporter: Gytis Trikleris
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.0.M4
>
>
> http://172.17.131.2/view/Narayana+BlackTie/job/narayana/171/TESTS=XTS,jdk...
> {code}
> Running org.jboss.jbossts.txbridge.tests.outbound.junit.EnabledContextPropagationTests
> Build was aborted
> Archiving artifacts
> ERROR: Failed to archive artifacts: **/target/*surefire-reports*/**,qa/*.zip,XTS/localjunit/crash-recovery-tests/target/log/*,jboss-as/build/target/wildfly-*/**,rest-tx/webservice/target/restat-web-*.war,jboss-as/dist/target/wildfly-*.zip,**/*.tgz
> hudson.util.IOException2: hudson.util.IOException2: Failed to extract /home/hudson/workspace/narayana/TESTS/XTS/jdk/jdk7.latest/label/linux/**/target/*surefire-reports*/**,qa/*.zip,XTS/localjunit/crash-recovery-tests/target/log/*,jboss-as/build/target/wildfly-*/**,rest-tx/webservice/target/restat-web-*.war,jboss-as/dist/target/wildfly-*.zip,**/*.tgz
> at hudson.FilePath.readFromTar(FilePath.java:1975)
> at hudson.FilePath.copyRecursiveTo(FilePath.java:1887)
> at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:798)
> at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:770)
> at hudson.model.Build$BuildExecution.post2(Build.java:183)
> at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:720)
> at hudson.model.Run.execute(Run.java:1600)
> at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:237)
> Caused by: java.io.IOException
> at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:175)
> at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61)
> at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:238)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
> at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:116)
> at org.apache.tools.tar.TarBuffer.readBlock(TarBuffer.java:257)
> at org.apache.tools.tar.TarBuffer.readRecord(TarBuffer.java:223)
> at hudson.org.apache.tools.tar.TarInputStream.read(TarInputStream.java:345)
> at java.io.FilterInputStream.read(FilterInputStream.java:107)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:999)
> at hudson.util.IOUtils.copy(IOUtils.java:37)
> at hudson.FilePath.readFromTar(FilePath.java:1965)
> ... 11 more
> at hudson.FilePath.copyRecursiveTo(FilePath.java:1894)
> at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:798)
> at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:770)
> at hudson.model.Build$BuildExecution.post2(Build.java:183)
> at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:720)
> at hudson.model.Run.execute(Run.java:1600)
> at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:237)
> Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Pipe is already closed
> at hudson.remoting.Channel$4.adapt(Channel.java:705)
> at hudson.remoting.Channel$4.adapt(Channel.java:700)
> at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
> at hudson.FilePath.copyRecursiveTo(FilePath.java:1890)
> ... 10 more
> Caused by: java.io.IOException: Pipe is already closed
> at hudson.remoting.PipeWindow.checkDeath(PipeWindow.java:83)
> at hudson.remoting.PipeWindow$Real.get(PipeWindow.java:171)
> at hudson.remoting.ProxyOutputStream._write(ProxyOutputStream.java:118)
> at hudson.remoting.ProxyOutputStream.write(ProxyOutputStream.java:103)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
> at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)
> at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:211)
> at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:146)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122)
> at org.apache.tools.tar.TarBuffer.writeBlock(TarBuffer.java:410)
> at org.apache.tools.tar.TarBuffer.writeRecord(TarBuffer.java:351)
> at hudson.org.apache.tools.tar.TarOutputStream.writeEOFRecord(TarOutputStream.java:356)
> at hudson.org.apache.tools.tar.TarOutputStream.finish(TarOutputStream.java:137)
> at hudson.org.apache.tools.tar.TarOutputStream.close(TarOutputStream.java:149)
> at hudson.util.io.TarArchiver.close(TarArchiver.java:126)
> at hudson.FilePath.writeToTar(FilePath.java:1941)
> at hudson.FilePath.access$1000(FilePath.java:168)
> at hudson.FilePath$36.invoke(FilePath.java:1880)
> at hudson.FilePath$36.invoke(FilePath.java:1876)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.io.IOException: Pipe is already closed
> at hudson.remoting.FastPipedOutputStream.write(FastPipedOutputStream.java:147)
> at hudson.remoting.FastPipedOutputStream.write(FastPipedOutputStream.java:131)
> at hudson.remoting.ProxyOutputStream$Chunk$1.run(ProxyOutputStream.java:216)
> at hudson.remoting.PipeWriter$1.run(PipeWriter.java:152)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ... 5 more
> Caused by: hudson.remoting.FastPipedInputStream$ClosedBy: The pipe was closed at...
> at hudson.remoting.FastPipedInputStream.close(FastPipedInputStream.java:112)
> at java.io.FilterInputStream.close(FilterInputStream.java:181)
> at java.util.zip.InflaterInputStream.close(InflaterInputStream.java:227)
> at java.util.zip.GZIPInputStream.close(GZIPInputStream.java:135)
> at org.apache.tools.tar.TarBuffer.close(TarBuffer.java:456)
> at hudson.org.apache.tools.tar.TarInputStream.close(TarInputStream.java:110)
> at hudson.FilePath.readFromTar(FilePath.java:1982)
> at hudson.FilePath.copyRecursiveTo(FilePath.java:1887)
> at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:798)
> at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:770)
> at hudson.model.Build$BuildExecution.post2(Build.java:183)
> at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:720)
> at hudson.model.Run.execute(Run.java:1600)
> at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:237)
> Finished: ABORTED
> {code}
--
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, 5 months
[JBoss JIRA] (JBTM-1570) Allow both Non-XA and XA servers
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1570?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1570:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.0.0.M4
(was: 5.0.0.Final)
Resolution: Done
Thanks for the contribution :)
> Allow both Non-XA and XA servers
> --------------------------------
>
> Key: JBTM-1570
> URL: https://issues.jboss.org/browse/JBTM-1570
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Crispin Boylan
> Assignee: Crispin Boylan
> Fix For: 5.0.0.M4
>
>
> For our application we have a mixture of XA and non-XA servers, for performance and probably due to the fact that Informix (our main DB) only lets one datasource be used in XA mode.
> Unfortunately the blacktie servers do an implicit tx_open, so if you have any XA data sources defined these get used and Informix thinks its in XA mode.
> I currently have a workaround for this which is to have a duplicate btconfig.xml with the XA sources removed and the servers which are NonXA get passed this in the -c of the server args. Seems to work nice, but would be good not to have to do that.
--
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, 5 months
[JBoss JIRA] (JBTM-1569) Allow topics to be shared between servers
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1569?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1569:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.0.0.M4
(was: 5.0.0.Final)
Resolution: Done
Many thanks for the contribution :)
> Allow topics to be shared between servers
> -----------------------------------------
>
> Key: JBTM-1569
> URL: https://issues.jboss.org/browse/JBTM-1569
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Crispin Boylan
> Assignee: Crispin Boylan
> Fix For: 5.0.0.M4
>
>
> At the moment topics can only service one server with multiple instances. If you try to add a topic to 2 different servers the XSD parsing fails with a message that a service must be unique to one server.
> Agreed that generally this should be the case, but for topics it would be advantageous for all servers to be able to subscribe to a topic, as although the logic is mostly different some of ours share functionality, and being able to send the same info in one call to multiple servers is useful.
> eg current functionality is allowed:
> <server name='foo'>
> <machine-ref id='fooapp1'/>
> <machine-ref id='fooapp2' />
> <service id='topica' type='topic' />
> </server>
> but I would like this to be possible:
> <server name='foo'>
> <machine-ref id='fooapp1'/>
> <machine-ref id='fooapp2' />
> <service id='topica' type='topic' />
> </server>
> <server name='bar'>
> <machine-ref id='barapp1'/>
> <machine-ref id='barapp2' />
> <service id='topica' type='topic' />
> <service id='barsvc'/>
> </server>
--
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, 5 months
[JBoss JIRA] (JBTM-1565) Allow callback server to open on a random port and override from the system property
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1565?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1565:
--------------------------------
Fix Version/s: 5.0.0.M4
(was: 5.0.0.Final)
> Allow callback server to open on a random port and override from the system property
> ------------------------------------------------------------------------------------
>
> Key: JBTM-1565
> URL: https://issues.jboss.org/browse/JBTM-1565
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Amos Feng
> Assignee: Crispin Boylan
> Fix For: 5.0.0.M4
>
>
> currently the client can only use the port defined for <SOCKETSERVER> in the btconfig.xml and multi clients can not run together.
> we need to allow callback server to open the random port when <SOCKETSERVER PORT="0"> or a range <SOCKETSERVER "12340-12350"> and they could be overridden by socketserver_port and socketserver_host environment variables.
--
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, 5 months
[JBoss JIRA] (JBTM-1565) Allow callback server to open on a random port and override from the system property
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1565?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1565:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Allow callback server to open on a random port and override from the system property
> ------------------------------------------------------------------------------------
>
> Key: JBTM-1565
> URL: https://issues.jboss.org/browse/JBTM-1565
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Amos Feng
> Assignee: Crispin Boylan
> Fix For: 5.0.0.Final
>
>
> currently the client can only use the port defined for <SOCKETSERVER> in the btconfig.xml and multi clients can not run together.
> we need to allow callback server to open the random port when <SOCKETSERVER PORT="0"> or a range <SOCKETSERVER "12340-12350"> and they could be overridden by socketserver_port and socketserver_host environment variables.
--
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, 5 months
[JBoss JIRA] (JBTM-1565) Allow callback server to open on a random port and override from the system property
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1565?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1565:
-------------------------------------
Thanks for the contribution Cris, I added you as a contributor in Jira too so we can assign you issues now too ;)
I merged your fix so I will mark this as resolved - many thanks for the contribution :)
> Allow callback server to open on a random port and override from the system property
> ------------------------------------------------------------------------------------
>
> Key: JBTM-1565
> URL: https://issues.jboss.org/browse/JBTM-1565
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Amos Feng
> Assignee: Crispin Boylan
> Fix For: 5.0.0.Final
>
>
> currently the client can only use the port defined for <SOCKETSERVER> in the btconfig.xml and multi clients can not run together.
> we need to allow callback server to open the random port when <SOCKETSERVER PORT="0"> or a range <SOCKETSERVER "12340-12350"> and they could be overridden by socketserver_port and socketserver_host environment variables.
--
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, 5 months
[JBoss JIRA] (JBTM-1569) Allow topics to be shared between servers
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1569?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1569:
--------------------------------
Assignee: Crispin Boylan (was: Amos Feng)
> Allow topics to be shared between servers
> -----------------------------------------
>
> Key: JBTM-1569
> URL: https://issues.jboss.org/browse/JBTM-1569
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Crispin Boylan
> Assignee: Crispin Boylan
> Fix For: 5.0.0.Final
>
>
> At the moment topics can only service one server with multiple instances. If you try to add a topic to 2 different servers the XSD parsing fails with a message that a service must be unique to one server.
> Agreed that generally this should be the case, but for topics it would be advantageous for all servers to be able to subscribe to a topic, as although the logic is mostly different some of ours share functionality, and being able to send the same info in one call to multiple servers is useful.
> eg current functionality is allowed:
> <server name='foo'>
> <machine-ref id='fooapp1'/>
> <machine-ref id='fooapp2' />
> <service id='topica' type='topic' />
> </server>
> but I would like this to be possible:
> <server name='foo'>
> <machine-ref id='fooapp1'/>
> <machine-ref id='fooapp2' />
> <service id='topica' type='topic' />
> </server>
> <server name='bar'>
> <machine-ref id='barapp1'/>
> <machine-ref id='barapp2' />
> <service id='topica' type='topic' />
> <service id='barsvc'/>
> </server>
--
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, 5 months
[JBoss JIRA] (JBTM-1565) Allow callback server to open on a random port and override from the system property
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1565?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1565:
--------------------------------
Assignee: Crispin Boylan (was: Amos Feng)
> Allow callback server to open on a random port and override from the system property
> ------------------------------------------------------------------------------------
>
> Key: JBTM-1565
> URL: https://issues.jboss.org/browse/JBTM-1565
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Amos Feng
> Assignee: Crispin Boylan
> Fix For: 5.0.0.Final
>
>
> currently the client can only use the port defined for <SOCKETSERVER> in the btconfig.xml and multi clients can not run together.
> we need to allow callback server to open the random port when <SOCKETSERVER PORT="0"> or a range <SOCKETSERVER "12340-12350"> and they could be overridden by socketserver_port and socketserver_host environment variables.
--
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, 5 months
[JBoss JIRA] (JBTM-1570) Allow both Non-XA and XA servers
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1570?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1570:
--------------------------------
Assignee: Crispin Boylan (was: Amos Feng)
> Allow both Non-XA and XA servers
> --------------------------------
>
> Key: JBTM-1570
> URL: https://issues.jboss.org/browse/JBTM-1570
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Affects Versions: 5.0.0.M2
> Reporter: Crispin Boylan
> Assignee: Crispin Boylan
> Fix For: 5.0.0.Final
>
>
> For our application we have a mixture of XA and non-XA servers, for performance and probably due to the fact that Informix (our main DB) only lets one datasource be used in XA mode.
> Unfortunately the blacktie servers do an implicit tx_open, so if you have any XA data sources defined these get used and Informix thinks its in XA mode.
> I currently have a workaround for this which is to have a duplicate btconfig.xml with the XA sources removed and the servers which are NonXA get passed this in the -c of the server args. Seems to work nice, but would be good not to have to do that.
--
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, 5 months