[GLASSFISH-8655] 3 LazyConnectionEnlistment connector tests with Tx fail Created: 06/Jul/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: sqe-test
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: shaline Assignee: shaline
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File run.log     Text File server.log    
Issuezilla Id: 8,655

 Description   

Build used: v3 b53 promoted:

3 LazyConnectionEnlistment connector tests with Tx are failing on V3 and there
are no Exceptions in the server.log.
Tests location:
appserver-sqe/pe/connector/lazyenlist
do " ant test-with-tx" to run the tests on V3.

Here are the tests that are failing:
tx:MyPool1_jmsID, tx:MyPool1_MyPool3ID, and tx:MyPool2_jmsID

Attached run.log from the ant process and server.log file fro reference.



 Comments   
Comment by shaline [ 06/Jul/09 ]

Created an attachment (id=2951)
log from ant proecess.

Comment by shaline [ 06/Jul/09 ]

Created an attachment (id=2952)
server.log file

Comment by Jagadish [ 19/Jul/09 ]

This issue should be same as 8598 :

Somehow the resources registered to the component-during
"TransactionManager.registerComponentResource" are not found during
"TransactionManger.enlistComponentResources" (similar to the case in 8598 where
it was not found during "TransactionManager.unregisterComponentResource")

ie., getExistingResourceList(instance, inv) in transactionManagerSimplified does
not return the resource that was registered to the component.

As a result of this, when a transaction is started in the component, already
registered resources in the component are not enlisted in the transaction and
hence they are not part of the transaction causing the test to fail. The test
expects the transaction to be GLOBAL. Since the jms-resource is not enlisted, it
turns out to be LOCAL.

Transferring to Marina for further investigation.

Comment by marina vatkina [ 24/Jul/09 ]

Closing as a duplicate. Please reopen when the other one is fixed, but this test
stil fails

      • This issue has been marked as a duplicate of 8598 ***
Comment by shaline [ 28/Jul/09 ]

On build57 nightly dated 7/28, the issue still exists and the tests are failing.

Comment by marina vatkina [ 29/Jul/09 ]

Why does this test need the FailureInducer to sleep 20 and then check that it
tool longer than 20 seconds to run the test? And if it tests the FailureInducer,
why is it called LazyConnectionEnlistment?

The FailureInducer is not working currently, but the test should be changed (or
renamed - but then FailureInducer doesn't set breakpoints outside an active XA
transaction...).

Comment by shaline [ 01/Oct/09 ]

Changed the tests according to bug, since Failure Inducer is not avialble..
Hence closing the bug.

Comment by Jagadish [ 13/Oct/09 ]

I am not sure why the test is disabled here. Reopening the bug.

===================================================================
RCS file: /m/jws/appserver-sqe/pe/connector/lazyenlist/build.xml,v
retrieving revision 1.5
retrieving revision 1.4
diff -r1.5 -r1.4
13,15c13
< <target name="all" depends="test-with-no-tx"/>
< <!--
< <target name="all" depends="test-with-tx, test-with-no-tx"/> -->

> <target name="all" depends="test-with-tx, test-with-no-tx"/>

Comment by kumara [ 28/Oct/09 ]

Lowering all test issues to P3.

Comment by shaline [ 17/Nov/09 ]

lowering priority to P4.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-3090] glassfish with ModJK config: Servlet 2.3 tests failed Created: 30/May/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: sqe-test
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: shaline Assignee: shaline
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Issuezilla Id: 3,090

 Description   

Hi,
I used the glassfish 9.1 EE build 44 on redhat linux 4.0, and configured the
Apache+mod_JK using the blog below:
http://blogs.sun.com/dadelhardt/entry/loadbalancing_with_mod_jk_and_glassfish

I executed the tomcat tests in the appserver-sqe workspace on this config.
2 of the Servlet 2_3 tests failed in the mod_jk config which have passed in
the regular runs... Here is the details of the testcase and how to reproduce.

1) Deploy the below war file:
/net/nimitz.red.iplanet.com/export2/mod_jk/BUGS/servlet2_3/product_test_servlet2_3.war

Issue the below URLs':
a) "Test the HttpServlet doTrace() method"
URL: http://localhost:80/product_test_servlet2_3/Test17
On a non-mod_jk setup, the HttpServlet.doTrace() returned its content as below

<HTML>
<HEAD>
<TITLE>TestDoTraceMethodServlet : Test the HttpServlet doTrace() method </TITLE>
</HEAD>
<BODY BGCOLOR=white>
<CENTER>
<FONT COLOR=BLUE>
<STRONG>Test Output</STRONG>
</FONT>
</CENTER>
<HR>
I am doTrace method of Test17. You are PASSED
<HR>
</BODY>
</HTML>

However, on a mod_jk setup, its content was just blank

b) " Check the default behavior of ServletRequestWrapper methods"
URL: http://localhost:80/product_test_servlet2_3/Test85?year=2003
On a non-mod_jk setup, the HttpServletRequest.getContentLength() returned -1,
however, on a mod_jk setup,
HttpServletRequest.getContentLength() returned 0. The mismatch caused the test
to fail since "-1" is the
expected value

-Shaline.



 Comments   
Comment by gfbugbridge [ 30/May/07 ]

<BT6563759>

Comment by jfarcand [ 31/May/07 ]

Re-assign to Amy to investigate. Shaline, can you run the same test on Tomcat
and see if the test pass? If it doesn't pass in Tomcat, it means there is a
configuration error somewhere. Also since we don't have control over mod_jk
source, if the bug occurs also in Tomcat then we should file the bug in Tomcat,
not in GlassFish to get help from the Tomcat community.

Thanks!

Comment by Amy Roh [ 20/Jun/07 ]

Lowering to P4 for further evaluation after discussing with the bug reporter.

Comment by jluehe [ 27/Jun/07 ]

I was able to reproduce the issue with TRACE. It looks like httpd intercepts any
TRACE requests and responds to them directly, instead of forwarding the TRACE
request to the servlet and invoking its implementation of doTrace().

I have been unable to figure out if httpd can be configured to forward TRACE
requests via AJP. I'll see if I can find an answer from the Apache folks.

Comment by jluehe [ 29/Jun/07 ]

The TRACE scenario, where the test case expects to see the output of the
servlet's impl of doTrace() in the response, cannot be supported if GlassFish is
front-ended by httpd, according to the following email exchange I've had on the
httpd user forum:

>----Original Message----
>> From: Jan.Luehe@Sun.COM Jan.Luehe@Sun.COM
>> Sent: Thursday, June 28, 2007 9:56 PM
>> To: users@httpd.apache.org
>> Subject: [users@httpd] Possible to configure httpd to forward
>> TRACE requests to backend?
>>
>> Is it possible to configure httpd in such a way that, with TRACE being
>> enabled, it forwards a TRACE request (via mod_jk) to a
>> backend servlet?

Apparently not... I was going to suggest that this might actually be a
bona fide use-case for the <Limit> container, until I read the docs
(http://httpd.apache.org/docs/2.2/mod/core.html#limit) where it
specifically states: "The TRACE method cannot be limited."

Rgds,
Owen Boyle

>>
>> Right now, httpd seems to intercept any such request and reply to it
>> directly.
>>
>> Thanks,
>>
>>
>> Jan

I'll investigate the "Check the default behavior of ServletRequestWrapper
methods" test failure that was also reported as part of this issue next.

Comment by jluehe [ 09/Jul/07 ]

I have an update on the 2nd aspect reported in this issue:

> b) " Check the default behavior of ServletRequestWrapper methods"

Turns out that Apache's httpd adds a Content-Length header with a value of "0"
to the request. This explains why ServletRequest.getContentLength() returns "0"
in this case.

There is no such request header present when GlassFish is accessed directly,
which means that ServletRequest.getContentLength() must (and does!) return "-1",
according to the Servlet spec:

Returns the length, in bytes, of the request body [...], or -1 if the
length is not known.

Please update the test so that it passes in either environment.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





Generated at Tue Jul 07 22:01:48 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.