[JBoss JIRA] Created: (JBMESSAGING-1869) Got Marshalling Exception when JMSWire Format writes object to Socket
by Nordine B (JIRA)
Got Marshalling Exception when JMSWire Format writes object to Socket
---------------------------------------------------------------------
Key: JBMESSAGING-1869
URL: https://issues.jboss.org/browse/JBMESSAGING-1869
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Destination Manager, JMS Remoting
Affects Versions: 1.4.0.SP3.CP10
Environment: Windows, JBoss EAP 4.3.0.CP08
Reporter: Nordine B
We are using Spring's Message Driven Pojo to consume messages.
At startup when the MDP is lauched, we have the following exception:
12:09:43,656 INFO [STDOUT] 12:09:43.656 [MOMWorkManagerThreadPool(3)-8]]
INFO fr.msa.agora.socle.g2.mom.internal.MDPContainerListenerImpl - Successfully refreshed JMS Connection
12:09:43,687 ERROR [SocketClientInvoker] Got marshalling exception, exiting
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:375)
at org.jboss.jms.wireformat.JMSWireFormat.read(JMSWireFormat.java:288)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1036)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:694)
at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:458)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:141)
at org.jboss.remoting.Client.invoke(Client.java:1935)
at org.jboss.remoting.Client.invoke(Client.java:788)
at org.jboss.remoting.Client.invoke(Client.java:776)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
at org.jboss.jms.client.delegate.ClientConsumerDelegate.org$jboss$jms$client$delegate$ClientConsumerDelegate$closing$aop(ClientConsumerDelegate.java:129)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_2473194355759371067.invokeNext(ClientConsumerDelegate$closing_2473194355759371067.java)
at org.jboss.jms.client.container.ConsumerAspect.handleClosing(ConsumerAspect.java:144)
at org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect36.invoke(ConsumerAspect36.java)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_2473194355759371067.invokeNext(ClientConsumerDelegate$closing_2473194355759371067.java)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_2473194355759371067.invokeNext(ClientConsumerDelegate$closing_2473194355759371067.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_2473194355759371067.invokeNext(ClientConsumerDelegate$closing_2473194355759371067.java)
at org.jboss.jms.client.delegate.ClientConsumerDelegate.closing(ClientConsumerDelegate.java)
at org.jboss.jms.client.JBossMessageConsumer.close(JBossMessageConsumer.java:96)
at org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.physicalClose(CachingConnectionFactory.java:418)
at org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.invoke(CachingConnectionFactory.java:305)
at $Proxy133.close(Unknown Source)
at org.springframework.jms.connection.JmsResourceHolder.closeAll(JmsResourceHolder.java:195)
at org.springframework.jms.connection.JmsTransactionManager.doCleanupAfterCompletion(JmsTransactionManager.java:264)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.cleanupAfterCompletion(AbstractPlatformTransactionManager.java:1011)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:804)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:723)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:255)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1056)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:952)
at org.springframework.jca.work.DelegatingWork.run(DelegatingWork.java:57)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:213)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:756)
at java.lang.Thread.run(Thread.java:662)
The exception repeats while MDP try to refresh the connection.
0
The strange thing is that if we replace jboss-messaging-client.jar 1.4.0.SP10 by the 1.4.0.SP08 version, everything works perfectly.
You may know that we have applied Slimming on our JBoss EAP 4.3CP08 (http://community.jboss.org/wiki/JBoss4xSlimming)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (JBWEB-200) REGRESSION: JSP generation uses TomcatInjectionContainer unsafely, leading to race condition
by Richard Kennard (JIRA)
REGRESSION: JSP generation uses TomcatInjectionContainer unsafely, leading to race condition
--------------------------------------------------------------------------------------------
Key: JBWEB-200
URL: https://issues.jboss.org/browse/JBWEB-200
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tomcat
Affects Versions: JBossWeb-3.0.0.CR1
Environment: JBoss AS 6.0.0.Final
Reporter: Richard Kennard
Assignee: Remy Maucherat
Priority: Critical
Hi guys,
Thanks for the great work you do on JBoss Web! We've been using it in production for years and it's a really solid product.
We are just upgrading from JBoss 5.1.0.GA to JBoss AS 6.0.0.Final. There appears to have been a serious regression in the JSP compilation. In JBoss 5.1.0.GA our JSP page compiled to this (looking in the /work folder)...
PageContext pageContext = _jspx_page_context;
JspWriter out = _jspx_page_context.getOut();
// tags:page-loggedIn
org.apache.jsp.tag.web.page_002dloggedIn_tag _jspx_th_tags_005fpage_002dloggedIn_005f0 = (new org.apache.jsp.tag.web.page_002dloggedIn_tag());
_jsp_instancemanager.newInstance(_jspx_th_tags_005fpage_002dloggedIn_005f0);
_jspx_th_tags_005fpage_002dloggedIn_005f0.setJspContext(_jspx_page_context);
...but in JBoss AS 6.0.0.Final it compiles to this...
PageContext pageContext = _jspx_page_context;
JspWriter out = _jspx_page_context.getOut();
// tags:page-loggedIn
org.apache.jsp.tag.web.page_002dloggedIn_tag _jspx_th_tags_005fpage_002dloggedIn_005f0 = (org.apache.jsp.tag.web.page_002dloggedIn_tag)_jsp_instancemanager.newInstance("org.apache.jsp.tag.web.page_002dloggedIn_tag", this.getClass().getClassLoader());
_jspx_th_tags_005fpage_002dloggedIn_005f0.setJspContext(_jspx_page_context);
There is a slight difference in which _jsp_instancemanager method is being called. The new JSP is calling the version of the method which takes a String. The old JSP was using the version which takes an Object.
Behind the scenes _jsp_instance maps to TomcatInjectionContainer, which uses a ClassLoader implemented by JasperLoader. However, JasperLoader.loadClass(name, resolve) is NOT THREAD SAFE. Even though it probably should be (java.lang.ClassLoader.loadClass(name, resolve) *is* Thread-safe, but JasperLoader overrides it and neglects to use 'synchronized'). So there may be 2 bugs here?
Anyway, regardless of whether the bug is in the JSP compilation or JasperLoader, under concurrent load we see this:
Caused by: java.lang.IllegalArgumentException: org.apache.jsp.tag.web
at java.lang.ClassLoader.definePackage(ClassLoader.java:1452)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:135)
at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:67)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:278)
at org.apache.jsp.platforms.platforms_jsp._jspx_meth_tags_005fpage_002dloggedIn_005f0(platforms_jsp.java:113)
Which is caused by this:
2011-05-23 13:53:11,874 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/].[jsp]] (http-116.50.21.248-8443-7) Servlet.service() for servlet jsp threw exception: java.lang.LinkageError: loader (instance of org/apache/jasper/servlet/JasperLoader): attempted duplicate class definition for name: "org/apache/jsp/tag/web/page_002dloggedIn_tag"
at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_24]
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [:1.6.0_24]
at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_24]
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_24]
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) [:1.6.0_24]
at java.net.URLClassLoader.access$000(URLClassLoader.java:58) [:1.6.0_24]
at java.net.URLClassLoader$1.run(URLClassLoader.java:197) [:1.6.0_24]
at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_24]
at java.net.URLClassLoader.findClass(URLClassLoader.java:190) [:1.6.0_24]
at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:135) [:6.0.0.Final]
at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:67) [:6.0.0.Final]
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:278) [:6.0.0.Final]
This is a regression from JBoss AS 5.1.0, which could handle building JSPs concurrently (and under load) without problem. Note we are using a shared JSP tagfile here (in /WEB-INF/tags).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (AS7-834) Implement a deterministic way of adding interceptors and configurators to a view and component
by jaikiran pai (JIRA)
Implement a deterministic way of adding interceptors and configurators to a view and component
----------------------------------------------------------------------------------------------
Key: AS7-834
URL: https://issues.jboss.org/browse/AS7-834
Project: Application Server 7
Issue Type: Task
Components: EE
Reporter: jaikiran pai
Assignee: Jason Greene
Fix For: 7.0.0.CR1
In the new EE framework, adding view/component configurators and interceptors to the view/component isn't deterministic and is very brittle. This needs to be re-implemented in a better way to provide a deterministic and more robust ordering of the configurators and interceptors.
I'm not assigning this to myself (yet) since I'm currently trying to get the EJB3 TCK related fixes done first. Once I finish that and if no one comes to this before me, then I'll pick this up.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month