Re: [JBoss-user] Exception creating connection to: 149.225.117.146
Hi Michael,
On Mon, 26 Mar 2001, Michael Bauschert (web.de) wrote:
> Hi there,
>
> Getting a reference of the InterestBean fails:
>
> i am doing the
> Object ref = jndiContext.lookup("Interest");
>
> and get the exception:
>
> javax.naming.CommunicationException [Root exception is
> java.rmi.ConnectIOException: Exception creating connection to:
> 149.225.117.146; nested exception is:
> java.net.NoRouteToHostException: Host unreachable: no further information]
>
>
> My Naming-Properties:
> System.setProperty("java.naming.factory.initial",
> "org.jnp.interfaces.NamingContextFactory");
> System.setProperty("java.naming.provider.url",
> "127.0.0.1:1099");
>
> Why ist JBoss trying to connect to 149.225.117.146 and not to my localHost ?
because the stub of the remote object that you became as a result of
lookup() contains it's 'home' address (adress and port where JVM of remote
object is accepting connections from stubs). that adress is determined
by JVM that is hosting remote object and is not the one that you were
using to lookup() the object because naming service must not be located on
a same host/jvm as remote object (for example client is on a
machine A, naming service is on B and remote objects are actually homed on
machine C but are registered on B). I hope that you were able to
understand anything i've written (sorry for my bad english ...)
Dragan
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] access modifiers lost in EJB programming ?
hi, On Mon, 5 Mar 2001, fractals wrote: > AFAIK, there's no way to make a method anything else than public in a remote > interface. Sad, because I *would* like to hide some of the methods I define > for some of my beans. > > Really, is there no way to get this cornerstone of OO programming back into > the EJB realm ? if you can afford the overhead you could make facade session beans that are hiding methods that you don't want to publish. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Some question regarding Jboss
Hello ricky, On Fri, 23 Mar 2001, Ricky wrote: > > Hi all , I am using Linux6.1 , jdk1.3 , postgresql7.0.2 and jboss2.1. > > I have a question regarding finder method code below : > > > Why in the line 2 , i do not need the PortableRemoteObject.narrow() ? > Cause why i tried to put the code in the IAS4.1.1 container , it > complained. > > Anybody any ideas why jboss do not need the PortableRemoteObject > method to get the remote reference ?? > jboss uses RMI and not corba as framework fo distributed objects, with corba you must narrow() the references and with RMI you don't have to .. Dragan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] JBoss and Java Web Start
Hello,
On Thu, 22 Mar 2001, Johan Nordin wrote:
> Hi,
>
> I just fixed the problem, it was not a JBoss problem (of course) =)
>
> It's a bugg in JWS,
> JWS does something wrong with the classloaders.
>
> Before creating any InitialContext,
> this code snipped must be included:
> (Found it on the discussion forum for JWS,
> http://forum.java.sun.com/read/56761/qAWFW4miqiQgAAY-i#LR).)
>
>
> try {
> final ClassLoader jnlpCL = this.getClass().getClassLoader();
> java.awt.EventQueue eq =
> java.awt.Toolkit.getDefaultToolkit().getSystemEventQueue();
> eq.invokeAndWait(new Runnable() {
> public void run() {
> Thread.currentThread().setContextClassLoader(jnlpCL);
> }
> });
> }
> catch (Exception e) {
> }
well - it is a jboss problem, jboss is not supplying bytecode for home and
remote interfaces at it's codebase (Webserver MBean) ... or for any other
class that is in .jars of deployed EJBs (please, correct me if i'm wrong!)
... the possible problem with that would be when implementation of
interface as result of EJB methods are returned, one such situation
would be:
interface that is returned:
public interface Test extends java.io.Serializable {
public String getName();
}
remote interface for ejb:
public interface Bean extends EJBObject {
Test getTest() throws RemoteException;
}
bean class:
public class BeanBean implements SessionBean {
...
public Test getTest() {
return new TestImpl();
}
...
public static class TestImpl implements Test {
public String getName() {return "just a test";}
}
}
in this case remote user must have BeanBean.TestImpl in its classpath and
that means that each change of Test implementation makes recompile of
client code necessary - if client could obtain bytecode from codebase via
RMIClassLoader recompile of it's code after change of Test Implementation
would be unnecessary ...
Dragan
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING
Hi,
On Wed, 21 Mar 2001, Alexander Kogan wrote:
> marc fleury wrote:
> >
> > Just out of curiousity Simone...
> >
> > when we benched at SUN one of the big difference under load was the thread
> > management.
> >
> > The best in terms of resource usage was put the thread to sleep (with a 5
> > sec timeout) and notify (1) and that REALLY flew and scaled REALLY well
> > because the usage of CPU and sync was really low.
>
> This would be very good idea. For now, especially on Tru64 with JDK 1.3-1
> LOKING-WAITING stuff eats a lot CPU and much more slow than on Sun.
>
> And why do we need timeout there? Is it possible to implement a sort
> of queue for that? Than you can put a new thread to the waiting list and
> when the current thread is done with the transaction it can call
> notify to release the tread from the waiting list.
> Am I talking junk?
i've developed fair queue (it maintains the order of requests) for
obtaining exclusive lock (token). Maybe it could help ...
Dragan
// Distributable under GPL License
// Author Dragan Milic ([EMAIL PROTECTED])
import java.lang.*;
import java.util.*;
public class FairThreadQueue {
LinkedList threadQueue=new LinkedList();
HashSet threadSet=new HashSet();
public FairThreadQueue() {
}
public void getToken() {
Lock lock=null;
Thread currentThread=Thread.currentThread();
synchronized (this) {
// sanity check, for reenterant beans
if (threadSet.contains(currentThread))
return;
threadSet.add(currentThread);
lock=new Lock();
threadQueue.add(lock);
// if there are no other threads in queue this one can have a token
if (threadQueue.size() == 1)
return;
}
// ok, there is some thread running ... just wait in queue
lock.waitForUnlock();
}
public synchronized void returnToken() {
Thread currentThread=Thread.currentThread();
// another sanity check
if (!threadSet.contains(currentThread))
return;
// if current thread is active it must be first in queue
threadQueue.removeFirst();
threadSet.remove(currentThread);
if (threadQueue.size() >0) {
Lock first=(Lock)threadQueue.getFirst();
first.unlock();
}
}
// because of possible lost wait there is necesarry to check
// if lock has been unlocked
public static class Lock {
boolean unlocked=false;
public void Lock() {
}
public synchronized void waitForUnlock() {
if (unlocked)
return;
else {
try {
wait();
} catch (InterruptedException ie) {
}
}
}
public synchronized void unlock() {
unlocked=true;
notify();
}
}
// below is only a test for functionality and fairness
public static void main(String argv[]) {
FairThreadQueue queue=new FairThreadQueue();
for (int i=0; i<200; i++) {
QueueTest qt=new QueueTest(queue, i);
qt.start();
}
}
public static class QueueTest extends Thread {
static int count=0;
FairThreadQueue ftq;
int threadNr;
QueueTest(FairThreadQueue ftq, int threadNr) {
this.ftq=ftq;
this.threadNr=threadNr;
}
public void run() {
ftq.getToken();
// test for reenterant test :)
ftq.getToken();
System.out.println("current counter "+count+" thread "+threadNr);
count++;
ftq.returnToken();
}
}
}
[JBoss-user] LOCKING-WAITING
Hello, i'm experiencing performance problems with jboss 2.1 under solaris: when i'm using one BMP EJB cuncurrently from multiple threads it seems to deadlock for a couple of seconds with following line reapeating in server.log: [Category] LOCKING-WAITING (CTX) for id CategoryPK(MUIKAQJkw34AAADfZiTtGJvA,de_DE) ctx.hash 6877805 cpu usage is 100% but calls to getXXX methods for that bean do not return untill deadlock is resolved (it takes usually 2-10 secs for that) and after that everything seems to be fine untill next deadlock occurs - bean has Supports flag for transactions and ist not in a transaction context while using, so i don't thing that the whole happends because of isolation of transactions. Dragan. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
