I do believe for one of the reported problems there is a (partial?)
solution: NetBeans 5.5 has a plugin (get on Update Center) to generate
the EJB jar client with reduced footprint.
Please, try it and report us the results! Would be very interesting.
Regards,
Edson Richter
glassfish_at_javadesktop.org escreveu:
> Hello everybody,
>
> like many others who have reported similar behaviour, we're developing a rich java client distributed over webstart. Now, I am starting to get frustrated over the large number of issues with the client we are facing.
>
> - Size of the client jar files: We need to distribute well over 20MB of jars purely related to communication with the application server, and they contain everything - almost the complete application server
>
> - The Webstart container in glassfish: It is simply not usable, you cannot customize the JNLP, let alone specify native DLLs or other things like jar versioning. Our workaround: a web application that does it with the sample JnlpDownloadServlet and a non-portable application client, as we cannot use the application client descriptor.
>
> - Time for login: On slower machines (like a 1.4Ghz iBook), login takes >20 seconds, with most of the time 100% CPU. Profiling shows that the time is spent in ORB.init()... WTF is it doing?
>
> - NAT traversal: The application simply connects to the server and sends requests to it. There should not be any need to connect back or even transmit a server name back to the client and connect to that (which is the case right now), effectively eliminating the possiblity to server NAT.
>
> - Request performance: As pointed out by others in this forum, the performance of the ORB greatly sucks. We're communicating with statless EJBs, transmitting value beans back and forth. Compared to other application servers, it takes up to 10 times as long.
>
> - Latency: This time, Jonas is 5 times as quick. Our average request latency for requests without payload (e.g. a simple ping()) is well above 10ms, sometimes as bad as 30ms. Without any network interference.
>
> - fault tolerance: It may happen, that the server is not reachable (host down, glassfish stopped, whatever). When it happens and the user wants to login, we're getting tons of log output (written to stdout, as Java logging is obviously used in the ORB) with like this:
>
> 18.04.2007 12:26:37 com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
> WARNUNG: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: localhost; port: 3700"
> org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No
> at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2348)
> at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2369)
> at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:212)
> at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:225)
> at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:104)
>
> thousands of lines (last time I checked it was > 20K lines). Only when those tousands of lines are logged (usually into nirvana, who is going to read this???), we are getting a javax.naming.CommunicationException on the client side indicating to us in the application that the login may have failed. You couldn't tell me that 19K5 lines of output earlier???
>
> - configurability of ORB behaviour: The ORB as a ton of properties that could be set. Possibly, but whenever I thought I had found a setting it turned out to be non-settable. Lets talk about an retry count for communication (see above, could save a ton of poor electrons wasted for logging). Lets talk about a socket timeout - all not settable. This last one (network timeouts) is one of our major headaches so far.
>
> - network timeout: There is no way to specify, how long I want to wait for a connect and how long I want a socket to be allowed idle. I searched and tried a lot, even creating my own socket factory. But guess what - the current version does not allow it to be overridden. There is a property, which is even being described in some documents (e.g. Sun App Server 8 docs), but Glassfish hardcoded sets it to its IIOPSSLSocketFactory. We're having troubles with this, because from time to time, a client may experience network problems. When this happens, the client is frozen to a point where it is not usable. If I cannot specify a timeout on socket level, I thought I maybe could just have watchdog thread and interrupt() some other threads (i.e. the locked thread). Try this - its a major show in the log console and a broken ORB. Shouldn't any blocking thread be prepared to receive an interrupt()?
>
> Sorry for ranting, but this had to be said from my side.
>
> regards,
>
> Florian
> [Message sent by forum member 'florianbruckner' (florianbruckner)]
>
> http://forums.java.net/jive/thread.jspa?messageID=212926
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>
>
>