[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException
by John Mazzitelli (JIRA)
cannot init cause of ClassCastException
---------------------------------------
Key: JBREM-552
URL: http://jira.jboss.com/jira/browse/JBREM-552
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.Beta2 (Boon)
Reporter: John Mazzitelli
Assigned To: Tom Elrod
Priority: Minor
Fix For: 2.0.0.CR1 (Boon)
I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown:
java.lang.IllegalStateException: Can't overwrite cause
at java.lang.Throwable.initCause(Throwable.java:320)
at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447)
at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324)
at org.jboss.remoting.Client.connect(Client.java:385)
at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470)
at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430)
at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167)
at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820)
at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102)
Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written).
The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor.
e.g.:
new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e);
(notice the ", e" parameter).
There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here.
--
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
14 years
[JBoss JIRA] Created: (JGRP-809) Copyless stack
by Bela Ban (JIRA)
Copyless stack
--------------
Key: JGRP-809
URL: https://jira.jboss.org/jira/browse/JGRP-809
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can
- have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to)
- pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return
- each thread in the pool has its own buffer into which the buffer is read from the socket
Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (JBREM-857) transporterclient not thread-safe for failover
by craig bordelon (JIRA)
transporterclient not thread-safe for failover
----------------------------------------------
Key: JBREM-857
URL: http://jira.jboss.com/jira/browse/JBREM-857
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transporter
Affects Versions: 1.4.6.GA
Environment: solaris 10 and java 5
Reporter: craig bordelon
Fix For: 2.2.2.GA_CP02
the jboss 1.4.1 transporterclient used by multithreaded program was giving strange results on a clustered server when failing over so i found lack of synchronization in the code.
I made these changes and seems to be helping.
changes to TransporterClient.java.
I would like this fixed in the 2.x and 3.x versions (hello developers). I think i know how to fix the 2.x version of this code too as it has some new stuff but is likewise broken. (developers send me an email to bord(a)iscp.telcordia.com if you need it. thx
Craig)
@@ -93,11 +93,12 @@
/**
* Disconnects the remoting client
*/
- private void disconnect()
+ private synchronized void disconnect()
{
if(remotingClient != null)
{
remotingClient.disconnect();
+ remotingClient = null;
}
}
@@ -232,14 +233,18 @@
do
{
+ Client rcl = null;
+ synchronized(this) { rcl = remotingClient; }
+ if (rcl == null) throw new CannotConnectException("Client has been dis
connected.");
try
{
failOver = false;
- response = remotingClient.invoke(request);
+ response = rcl.invoke(request);
}
catch(CannotConnectException cnc)
{
- failOver = findAlternativeTarget();
+ failOver = findAlternativeTarget(rcl);
+ if (log.isDebugEnabled()) log.error("on CannotConnectException failO
ver is "+failOver+" for "+rcl.getInvoker().getLocator());
if(!failOver)
{
throw cnc;
@@ -264,7 +269,7 @@
*
* @return
*/
- private boolean findAlternativeTarget()
+ private boolean findAlternativeTarget(Client rcl)
{
boolean failover = false;
@@ -287,12 +292,19 @@
{
// finally found server with target handler
InvokerLocator newLocator = data.getInvokerLocator();
- if(!remotingClient.getInvoker().getLocator().equals(new
Locator))
+ if(!rcl.getInvoker().getLocator().equals(newLocator))
{
try
{
- remotingClient = new Client(newLocator);
- remotingClient.connect();
+ synchronized(this) {
+ if (rcl == remotingClient) {
+ disconnect();
+ remotingClient = new Client(newLocator);
+ }
+ //otherwise have to assume some other thread
+ //has meanwhile changed it
+ //including even disconnecting
+ }
return true;
}
catch(Exception e)
@@ -300,6 +312,8 @@
log.warn("Problem connecting to newly found alter
nate target.", e);
}
}
+ else if (log.isDebugEnabled())
+ log.error(rcl.getInvoker().getLocator()+" == "+newLoc
ator);
}
}
}
@@ -333,4 +347,4 @@
}
--
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
14 years, 1 month
[JBoss JIRA] Created: (JBREM-906) NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker
by John Reynolds (JIRA)
NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker
-----------------------------------------------------------------------------
Key: JBREM-906
URL: http://jira.jboss.com/jira/browse/JBREM-906
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: unifiedinvoker
Affects Versions: 2.2.2.GA
Environment: Server Running Windows XP or Redhat - Swing Client on Windows XP
Reporter: John Reynolds
Using a Swing client to connect to the JBoss server, configured with RMI Transport Connector and Unified Invoker, I receive the following StackTrace when, after successfully connecting to the server and executing a few EJB transactions, I shut the server down and then bring it back up. Upon attempting to do any further invocations, it appears cached information is causing the client to fail.
-------------
(rmi.RMIClientInvoker 272 ) java.rmi.NoSuchObjectException: no such object in table
galaxy.framework.model.domain.services.util.SLCommunicationException: Error making invocation in RMI client invoker.
at galaxy.framework.model.domain.services.util.ServiceLocator.authenticateUser(ServiceLocator.java:738)
at galaxy.framework.model.domain.services.util.ServiceLocator.initializeWithLDAP(ServiceLocator.java:435)
at galaxy.application.view.swing.presentation.util.ClientConnectionManager$1.run(ClientConnectionManager.java:51)
Caused by: org.jboss.remoting.CannotConnectException: Error making invocation in RMI client invoker.
at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:273)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1550)
at org.jboss.remoting.Client.invoke(Client.java:530)
at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:183)
at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
at $Proxy1.authenticateSwingUserWithLDAP(Unknown Source)
at galaxy.framework.model.domain.services.util.ServiceLocator.authenticateUser(ServiceLocator.java:725)
... 2 more
Caused by: java.rmi.NoSuchObjectException: no such object in table
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
at org.jboss.remoting.transport.rmi.RMIServerInvoker_Stub.transport(Unknown Source)
at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:238)
... 14 more
------------
Seems potentially similar to this issue fixed in 4.0.5 in non-remoting-RMI code:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116027
--
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
14 years, 1 month
[JBoss JIRA] Created: (JBREM-808) Remove dependencies on ObjectNameFactory from JBoss JMX
by Julien Viet (JIRA)
Remove dependencies on ObjectNameFactory from JBoss JMX
-------------------------------------------------------
Key: JBREM-808
URL: http://jira.jboss.com/jira/browse/JBREM-808
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Julien Viet
It happens when my POJO has not been bound on the transporter server, it looks like the transporter client is trying to do some fail over.
This make JBoss Remoting depends on the JBoss JMX implementation. That makes JBoss Remoting more difficult to embed and reuse.
I think that the ObjectNameFactory class could be easily ported to JBoss Remoting without any harm done. However perhaps JBoss Remoting has more dependencies on JBoss JMX that I don't know that would prevent to remove such dependency.
[junit_] Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/mx/util/ObjectNameFactory
[junit_] at org.jboss.remoting.transporter.InternalTransporterServices.<clinit>(InternalTransporterServices.java:41)
[junit_] at org.jboss.remoting.transporter.TransporterClient.findAlternativeTarget(TransporterClient.java:330)
[junit_] at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:301)
[junit_] at $Proxy0.getInfo(Unknown Source)
[junit_] at org.jboss.portal.test.framework.driver.remote.RemoteTestDriverClient.getInfo(RemoteTestDriverClient.java:107)
--
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
14 years, 1 month