[
https://issues.jboss.org/browse/JBTM-1674?page=com.atlassian.jira.plugin....
]
Tom Jenkinson edited comment on JBTM-1674 at 9/9/13 11:19 AM:
--------------------------------------------------------------
13:06:48,626 DEBUG [org.jboss.narayana.blacktie.jatmibroker.core.server.Client]
(Thread-1057) size is 1
13:06:48,626 DEBUG [org.jboss.narayana.blacktie.jatmibroker.core.server.Client]
(Thread-1057) sid is 1
I think the problem is with the sending side. Why would it send a 1 length buffer with a
content of a single integer: 1.
Presumably the connection was from:
13:06:48,408 DEBUG [org.jboss.narayana.blacktie.jatmibroker.core.server.SocketServer]
(Thread-102) connection from Socket[addr=/127.0.0.1,port=44874,localport=12340]
Unfortunately I can't seem to find the corresponding logging on the service where it
has connected back to the caller to return the result. This is because the C++ side does
not seem to log the port number of the connection to the SocketServer (i.e. the C++ side
socket port number) when it connects back. Please can you confirm this is the case, update
the code with some additional debug and then mark this as incomplete description.
Alternatively, if you think the C++ side is logging the port number when it connects back
to a caller, please can you work out where the log is from this job and if it wasn't
created, update the job config to capture the log next time and then again mark this one
as incomplete?
My guess is it is this code that needs to debug the port it is connected to:
HybridSocketEndpointQueue::HybridSocketEndpointQueue(HybridSocketSessionImpl* session,
apr_pool_t* pool, client_ctx_t* ctx,
void(*messagesAvailableCallback)(int, bool)) {
LOG4CXX_DEBUG(logger, (char*) "Creating socket endpoint queue with
client_ctx_t");
shutdown = false;
_connected = true;
this->pool = pool;
this->ctx = ctx;
this->socket = ctx->sock;
this->addr = NULL;
this->id = ctx->sid;
LOG4CXX_TRACE(logger, (char*) "create id from ctx->sid is " << id);
this->session = session;
this->messagesAvailableCallback = messagesAvailableCallback;
}
It would also be useful to add debug code on the sending size to print out the size of the
data it is about to send and the socket number it is going to send it on.
I think the client side when it is debugging should print out when it enters run() in the
Client thread the port that it is listening on to be certain of the port that thread is
listening on.
This debugging of the port should be on the Java and C++ side, so SocketSender
SocketReceiver, SocketServer and HybridSocketEndpointQueue by the look of it?
was (Author: tomjenkinson):
13:06:48,626 DEBUG [org.jboss.narayana.blacktie.jatmibroker.core.server.Client]
(Thread-1057) size is 1
13:06:48,626 DEBUG [org.jboss.narayana.blacktie.jatmibroker.core.server.Client]
(Thread-1057) sid is 1
I think the problem is with the sending side. Why would it send a 1 length buffer with a
size of 1.
Presumably the connection was from:
13:06:48,408 DEBUG [org.jboss.narayana.blacktie.jatmibroker.core.server.SocketServer]
(Thread-102) connection from Socket[addr=/127.0.0.1,port=44874,localport=12340]
Unfortunately I can't seem to find the corresponding logging on the service where it
has connected back to the caller to return the result. This is because the C++ side does
not seem to log the port number of the connection to the SocketServer (i.e. the C++ side
socket port number) when it connects back. Please can you confirm this is the case, update
the code with some additional debug and then mark this as incomplete description.
Alternatively, if you think the C++ side is logging the port number when it connects back
to a caller, please can you work out where the log is from this job and if it wasn't
created, update the job config to capture the log next time and then again mark this one
as incomplete?
My guess is it is this code that needs to debug the port it is connected to:
HybridSocketEndpointQueue::HybridSocketEndpointQueue(HybridSocketSessionImpl* session,
apr_pool_t* pool, client_ctx_t* ctx,
void(*messagesAvailableCallback)(int, bool)) {
LOG4CXX_DEBUG(logger, (char*) "Creating socket endpoint queue with
client_ctx_t");
shutdown = false;
_connected = true;
this->pool = pool;
this->ctx = ctx;
this->socket = ctx->sock;
this->addr = NULL;
this->id = ctx->sid;
LOG4CXX_TRACE(logger, (char*) "create id from ctx->sid is " << id);
this->session = session;
this->messagesAvailableCallback = messagesAvailableCallback;
}
It would also be useful to add debug code on the sending size to print out the size of the
data it is about to send and the socket number it is going to send it on.
I think the client side when it is debugging should print out when it enters run() in the
Client thread the port that it is listening on to be certain of the port that thread is
listening on.
btadmin.PauseDomainTest failed with command failure
---------------------------------------------------
Key: JBTM-1674
URL:
https://issues.jboss.org/browse/JBTM-1674
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: BlackTie
Reporter: Amos Feng
Assignee: Amos Feng
Priority: Minor
Fix For: 6.0.0.Final
http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64-el5/1501
{noformat}
-------------------------------------------------------------------------------
Test set: org.jboss.narayana.blacktie.btadmin.PauseDomainTest
-------------------------------------------------------------------------------
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 83.154 sec <<<
FAILURE!
testPauseDomainWithArg(org.jboss.narayana.blacktie.btadmin.PauseDomainTest) Time
elapsed: 53.947 sec <<< FAILURE!
junit.framework.AssertionFailedError: Command failed
at junit.framework.Assert.fail(Assert.java:47)
at org.jboss.narayana.blacktie.btadmin.PauseDomainTest.setUp(PauseDomainTest.java:48)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:98)
at
org.apache.maven.surefire.junit.JUnit3Provider.executeTestSet(JUnit3Provider.java:107)
at org.apache.maven.surefire.junit.JUnit3Provider.invoke(JUnit3Provider.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at com.sun.proxy.$Proxy0.invoke(Unknown Source)
at
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
{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