April 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBWEB-91) AJP implementation broken : ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message

by Michal Borowiecki (JIRA)

AJP implementation broken : ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message ------------------------------------------------------------------------------------------------ Key: JBWEB-91 URL: http://jira.jboss.com/jira/browse/JBWEB-91 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Environment: Linux 2.6.20-gentoo-r8 #1 SMP jbossweb-1.0.1.GA-linux2-i686.tar.gz sun-jdk-1.5.0.11 and sun-jdk-1.6.0.01 Apache: Apache/1.3.37 JK: mod_jk/1.2.18 Reporter: Michal Borowiecki Assigned To: Mladen Turk Fix For: JBoss Web Server 1.0.1 GA When response is greater than abount 225 kB and error is detected on Apache side in mod_jK: last normal log entry: [Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0 75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72 - ult=document.for then error: [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139 [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client [Wed Aug 29 11:24:57 2007] [97923:0000] [info] ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1 [Wed Aug 29 11:24:57 2007] [97923:0000] [info] ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed, recoverable operation attempt=2 [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed At another time the error message said: [Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263 or [Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c JBoss logs show a normal response sent: [29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004 [29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579 Apache logs show an error: [29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265 [29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265 The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1135) Interceptor's tutorial page contains outdated XML

by Galder Zamarreno (JIRA)

Interceptor's tutorial page contains outdated XML ------------------------------------------------- Key: EJBTHREE-1135 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1135 Project: EJB 3.0 Issue Type: Bug Components: Documentation Affects Versions: AS 4.2.2.GA, AS 5.0.0.Beta3 Reporter: Galder Zamarreno ejb3/docs/tutorial/interceptor/interceptor.html contains outdated XML, i.e: <interceptor-binding> <ejb-name>org.jboss.tutorial.interceptor.bean.EmailSystemBean</ejb-name> <interceptor-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</interceptor-class> <method-name>sendBookingCancellationMessage</method-name> </interceptor-binding> should be: <interceptor-binding> <ejb-name>org.jboss.tutorial.interceptor.bean.EmailSystemBean</ejb-name> <interceptor-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</interceptor-class> <method> <method-name>sendBookingCancellationMessage</method-name> </method> </interceptor-binding> i.e.2: <interceptor-binding> <ejb-name>MyBean</ejb-name> <interceptor-class>SomeInterceptor</interceptor-class> <method-name>overLoadedMethod</method-name> <method-params> <method-param>int</method-param> <method-param>java.lang.String[][]</method-param> </method-params> </interceptor-binding> should be: <interceptor-binding> <ejb-name>MyBean</ejb-name> <interceptor-class>SomeInterceptor</interceptor-class> <method> <method-name>overLoadedMethod</method-name> <method-params> <method-param>int</method-param> <method-param>java.lang.String[][]</method-param> </method-params> </method> </interceptor-binding> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-757) getMessageContext Not Implemented

by ppc (JIRA)

getMessageContext Not Implemented --------------------------------- Key: EJBTHREE-757 URL: http://jira.jboss.com/jira/browse/EJBTHREE-757 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - FD Reporter: ppc jboss-4.0.4.GA with EJB3-RC9FD thows a NOT IMPLEMENTED Exception when form the SessionContext he method getMessageContext is called. Form this version with the new JbossWS stack as far i know i not anymore possible to retreive a SOAP attachement . With the old ws4ee was possible calling the org.jboss.axis.MessageContext.getCurrentContext(); without calling SessionContext but now all the axis stuff has been removed :( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

4
17
0 / 0

[JBoss JIRA] Created: (EJBTHREE-989) Can't inject resources of type URL

by Carlo de Wolf (JIRA)

Can't inject resources of type URL ---------------------------------- Key: EJBTHREE-989 URL: http://jira.jboss.com/jira/browse/EJBTHREE-989 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Fix For: EJB 3.0 RC11 - FD -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (JGRP-659) Merge and UNICAST sequencing problem

by Vladimir Blagojevic (JIRA)

Merge and UNICAST sequencing problem ------------------------------------ Key: JGRP-659 URL: http://jira.jboss.com/jira/browse/JGRP-659 Project: JGroups Issue Type: Bug Affects Versions: 2.6, 2.5, 2.4 Reporter: Vladimir Blagojevic Assigned To: Bela Ban The problem is related to trashing of connection table in UNICAST during merge. Consider following scenario: There are 4 nodes in a cluster A,B,C, and D. After network split we have two islands A,B and C,D. When the network healing starts eventually MergeView gets installed in both islands. MergeView installation causes trashing of UNICAST connection table [1]. However if we have a scenario where MergeView gets installed in A,B island at time T and it gets installed in island C,D at time T+N msec and a node from island A,B sends a unicast message in this N msec time window then we'll run into problems with unicast sequencing at C and D. Why? Because next message coming from island A,B into C,D will be will with sequence number > 1 and sequencing in UNICAST of C,D after connection trashing (from merge) expects starting sequence of 1. This causes UNICAST in C and/or D to wait forever for missing messages. Final outcome is thus that no more unicast message coming from A and/or B will ever be delivered at C and/or D! [1]http://jira.jboss.com/jira/browse/JGRP-348 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

3
16
0 / 0

[JBoss JIRA] Created: (JBAS-5146) com.sun.faces.serializeServerState , java.lang.ClassNotFoundException: boolean

by Dave Chen (JIRA)

com.sun.faces.serializeServerState , java.lang.ClassNotFoundException: boolean ------------------------------------------------------------------------------- Key: JBAS-5146 URL: http://jira.jboss.com/jira/browse/JBAS-5146 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JSF Affects Versions: JBossAS-4.2.2.GA Environment: JBoss 4.2.2.GA, using JSF RI with Tomahawk. Reporter: Dave Chen Assigned To: Stan Silvert Priority: Critical I am using <t:saveState>, and set com.sun.faces.serializeServerState to true in web.xml. <context-param> <param-name>javax.faces.STATE_SAVING_METHOD</param-name> <param-value>server</param-value> </context-param> <context-param> <param-name>com.sun.faces.serializeServerState</param-name> <param-value>true</param-value> </context-param> I got the following exception. java.lang.ClassNotFoundException: boolean at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1358) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at com.sun.faces.renderkit.ApplicationObjectInputStream.resolveClass(ApplicationObjectInputStream.java:74) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1433) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1288) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.ArrayList.readObject(ArrayList.java:591) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1186) maxBatchTime stops working after the connection between source and target servers is lost

by Maurice Zeijen (JIRA)

maxBatchTime stops working after the connection between source and target servers is lost ----------------------------------------------------------------------------------------- Key: JBMESSAGING-1186 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1186 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP1 Environment: Windows XP 64 Java 6 JBoss 4.2.2 Reporter: Maurice Zeijen Assigned To: Tim Fox We have the following Situation: A bridge MBean is setup to bridge between a local source and a remote target. The MaxBatchSize attribute is set to 5 and the MaxBatchTime is set to 10000. So the configuration looks like this: <mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.messaging:service=Bridge,name=wai_sync_customer_bridge" xmbean-dd="xmdesc/Bridge-xmbean.xml"> <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends> <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=RemoteJMSProvider</depends> <attribute name="SourceDestinationLookup">/queue/local</attribute> <attribute name="TargetDestinationLookup">/queue/remote</attribute> <attribute name="QualityOfServiceMode">0</attribute> <attribute name="MaxBatchSize">5</attribute> <attribute name="MaxBatchTime">10000</attribute> <attribute name="FailureRetryInterval">5000</attribute> <attribute name="MaxRetries">-1</attribute> <attribute name="AddMessageIDInHeader">false</attribute> <depends>jboss.messaging.destination:name=local,service=Queue</depends> </mbean> If the connection between the two servers is available then the MaxBatchTime works fine. After 10 seconds all messages are moved from local queue to remote queue if there are less then 5 messages in the queue. But when for some reason the connection is lost and after a while restored again then the MaxBatchTime doesn't work any more. Luckily the MaxBatchSize still works. Also the MaxBatchSize doesn't work when the remote server isn't available when the bridge on the local server is started. Restarting the bridge makes the MaxBatchTime work again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1219) Using DSL and accumulate in Drools BRMS leads to unexpected results

by Cristiano Giuffrida (JIRA)

Using DSL and accumulate in Drools BRMS leads to unexpected results ------------------------------------------------------------------- Key: JBRULES-1219 URL: http://jira.jboss.com/jira/browse/JBRULES-1219 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.1 Environment: HP-UX java version "1.5.0.05" Reporter: Cristiano Giuffrida Assigned To: Mark Proctor Details of this problem are described in the following thread: http://www.nabble.com/Using-DSL-and-accumulate-in-Drools-BRMS-leads-to-un... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

5
7
0 / 0

[JBoss JIRA] Created: (JBAOP-567) Default constructors are not handled

by Flavia Rainone (JIRA)

Default constructors are not handled ------------------------------------ Key: JBAOP-567 URL: http://jira.jboss.com/jira/browse/JBAOP-567 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR8 Reporter: Flavia Rainone Fix For: 2.1.0.GA Pointcut expressions don't match default constructors. To reproduce this error, comment out the empty default constructors present in the following classes: org.jboss.test.aop.rebuildingchain.ConstructorExecutionSyncThread org.jboss.test.aop.rebuildingchain.ConstructionExecutionSyncThread -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
9
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1056) Redo NestedBeanUnitTestCase.testConsistentPassivatedState()

by Brian Stansberry (JIRA)

Redo NestedBeanUnitTestCase.testConsistentPassivatedState() ----------------------------------------------------------- Key: EJBTHREE-1056 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1056 Project: EJB 3.0 Issue Type: Sub-task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor NestedBeanUnitTestCase.testConsistentPassivatedState() is a pretty weak test for the EJBTHREE-1053 condition; when the parent issue is fixed, replace this test with something better. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2008