[JBoss JIRA] Created: (JBREM-675) Problems with Servlet invoker
by Tom Elrod (JIRA)
Problems with Servlet invoker
-----------------------------
Key: JBREM-675
URL: http://jira.jboss.com/jira/browse/JBREM-675
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 1.4.6.GA, 2.0.0.GA (Boon)
Reporter: Tom Elrod
Assigned To: Tom Elrod
Fix For: 2.2.0.Beta1 (Bluto)
Attachments: ServletServerInvoker.java
Several problems with servlet invoker:
1) There can't be two servlet invokers (it's necessary, for example, if you want to use them for JBoss Messagning and for EJBs - they require separate connectors) because ObjectName is hard-coded in ServletServerInvoker.java
2) Null returns from invokers are sent to client as empty 204 responses and custom marshallers have no change to process return value. This breaks JBoss Messaging which expects that EVERY message contains at least two bytes (version tag and format tag).
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBMESSAGING-835) Simple test suite configuration
by Tim Fox (JIRA)
Simple test suite configuration
-------------------------------
Key: JBMESSAGING-835
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-835
Project: JBoss Messaging
Issue Type: Task
Affects Versions: 1.2.0.Beta2
Reporter: Tim Fox
Assigned To: Ovidiu Feodorov
Fix For: 1.2.0.GA
The test suite configuration needs to be simplified.
Currently, the same settings can be specified in enrvironment variables, properties file, build.xml, system properties, and in container.xml, with a complex precedence hierarchy determining which setting overrides another setting.
Also some settings are specified redundantly - e.g. test database is inferred from the jdbc connection url but is already specified in the container.xml.
We should have one place and one place only where configuration settings are specified.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JGRP-465) Deadlock in FC if RPC response blocks
by Brian Stansberry (JIRA)
Deadlock in FC if RPC response blocks
-------------------------------------
Key: JGRP-465
URL: http://jira.jboss.com/jira/browse/JGRP-465
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1 SP1
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.4.1 SP2
In 2.4.1.SP1 (and probably earlier) FC can deadlock if all up/down threads are set to false at and above FC and an incoming RPC loops back down the channel with its response.
Following stack trace shows a deadlock situation (note the line numbers in FC are off from the cvs code; this occured with a patched FC version, but the patch is not relevant to this error):
"IncomingPacketHandler (channel=Tomcat-Cluster)" daemon prio=1 tid=0xc8a68b60 nid=0x1ece in Object.wait() [0xc94d1000..0xc94d1f30]
at java.lang.Object.wait(Native Method)
at EDU.oswego.cs.dl.util.concurrent.CondVar.timedwait(CondVar.java:222)
- locked <0xd187e398> (a EDU.oswego.cs.dl.util.concurrent.CondVar)
at org.jgroups.protocols.FC.handleDownMessage(FC.java:394)
at org.jgroups.protocols.FC.down(FC.java:336)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
at org.jgroups.protocols.FC.receiveDownEvent(FC.java:330)
at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
at org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:294)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
at org.jgroups.JChannel.down(JChannel.java:1231)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:790)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:767)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:693)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:377)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:393)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:197)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FC.up(FC.java:377)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:768)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:788)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:260)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:476)
- locked <0xd1eec6d8> (a org.jgroups.protocols.UNICAST$Entry)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:206)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:569)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:170)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FD.up(FD.java:300)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:162)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.Discovery.up(Discovery.java:225)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:908)
at org.jgroups.protocols.TP.handleIncomingPacket(TP.java:850)
at org.jgroups.protocols.TP.access$400(TP.java:45)
at org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1296)
at java.lang.Thread.run(Thread.java:595)
The thread carried an RPC up to RpcDispatcher and is waiting in FC.handleDownMessage() for credits to become available to send the RPC response. Those credits will never arrive, as the thread that is blocking is the one that would need to deliver the credits.
This is less of an issue in 2.5. This is because 2.5. uses the concurrent stack and credit replenishments are sent as OOB messages on a separate thread. (Would still be an issue in 2.5 if the concurrent stack were disabled via configuration.)
Hacky solution is to somehow flag the up thread and in handleDownMessage() check for the flag before blocking the thread. If the flag is set, don't block the thread -- just let it through, i.e. let it exceed max_credits.
In cases like recent JBC releases where the vast majority of RPC responses are lightweight "null" responses, this is pretty safe. Need to add a config flag to disable the workaround though for use in applications where RPC responses frequently return large amounts of data.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBAS-3704) Add a notion of available interfaces to org.jboss.test.util.server.*
by Scott M Stark (JIRA)
Add a notion of available interfaces to org.jboss.test.util.server.*
--------------------------------------------------------------------
Key: JBAS-3704
URL: http://jira.jboss.com/jira/browse/JBAS-3704
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-4.0.4.GA
Reporter: Scott M Stark
Fix For: JBossAS-4.0.6.CR1
An issue with automating testing involving binding to specific addresses is that there is no predefined set of properties a testsuite descriptor can reference. The qa env has MYTESTIP_1 type of env vars set, and java 1.4.2+ has java.net.NetworkInterface, that could be used as the basis for defining jboss.server.iface.0..N system properties that configurations could rely on for setting one or more bind interfaces.
We need to add this functionality to the server startup tasks.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBREM-736) [org.jboss.remoting.transport.socket.SocketClientInvoker] Got marshalling exception, exiting java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
by Ravi Alagappan (JIRA)
[org.jboss.remoting.transport.socket.SocketClientInvoker] Got marshalling exception, exiting java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBREM-736
URL: http://jira.jboss.com/jira/browse/JBREM-736
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: marshall
Affects Versions: 1.4.3.GA
Environment: Jboss 4.0.4.GA/EJB3/JDK1.6
Reporter: Ravi Alagappan
Assigned To: Tom Elrod
I am throwing custom application exception from bean and trying to catch that in client. But I am getting
2007-04-17 09:57:15,480 DEBUG [org.jboss.remoting.transport.socket.SocketClientInvoker] connect called for: org.jboss.remoting.transport.socket.SocketClientInvoker@16a38b5
2007-04-17 09:57:15,558 ERROR [org.jboss.remoting.transport.socket.SocketClientInvoker] Got marshalling exception, exiting
java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:50)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:139)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279)
at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
at org.jboss.remoting.Client.invoke(Client.java:525)
at org.jboss.remoting.Client.invoke(Client.java:488)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
at $Proxy0.save(Unknown Source)
at linc.document.service.RepositoryClient.save(RepositoryClient.java:109)
at linc.document.service.DocumentService.save(DocumentService.java:35)
at linc.document.service.DocumentService.main(DocumentService.java:184)
2007-04-17 09:57:15,573 ERROR [org.jboss.remoting.transport.socket.SocketClientInvoker] Error loading classes from remote call result.
java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:50)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:139)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279)
at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
at org.jboss.remoting.Client.invoke(Client.java:525)
at org.jboss.remoting.Client.invoke(Client.java:488)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
at $Proxy0.save(Unknown Source)
at linc.document.service.RepositoryClient.save(RepositoryClient.java:109)
at linc.document.service.DocumentService.save(DocumentService.java:35)
at linc.document.service.DocumentService.main(DocumentService.java:184)
But no exception with jdk1.5. With JDK1.5 client able to catch custom exception.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBREM-718) Support for more message-based protocols
by Mark Little (JIRA)
Support for more message-based protocols
----------------------------------------
Key: JBREM-718
URL: http://jira.jboss.com/jira/browse/JBREM-718
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Mark Little
Assigned To: Tom Elrod
It would be good if Remoting supported more message-oriented protocols, such as JMS, FTP, email etc. RPC semantics could be layered on those, or simply say that the one-way approach is all that is supported. One slight worry might be if a supported plugin implementation for JBoss Remoting itself used JBoss Remoting (e.g., plugging JBoss Messaging into JBoss Remoting). This may set up some interesting circularities.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBAOP-366) Ability to attach a .aop deployment to a particular scoped classloader
by Kabir Khan (JIRA)
Ability to attach a .aop deployment to a particular scoped classloader
----------------------------------------------------------------------
Key: JBAOP-366
URL: http://jira.jboss.com/jira/browse/JBAOP-366
Project: JBoss AOP
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.alpha2
Reporter: Kabir Khan
Assigned To: Kabir Khan
Fix For: 2.0.0.alpha3, 1.5.4.GA
e.g. if an .ear file has been scoped with:
<jboss-app>
<loader-repository>
dot.com:loader=ear1test
</loader-repository>
</jboss-app>
It should be possible to deploy at a later time a .aop file like:
<aop>
<attach-scoped-loader>dot.com:loader=ear1test</attach-scoped-loader>
<!-- aspects, bindings etc. -->
</aop>
The classloader for the scoped repository "dot.com:loader=ear1test" should be used to deploy the contents of the .aop file in the same way as if the .aop file had been deployed as part of the .ear.
--
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
18 years, 9 months