|
Replies:
26
-
Last Post:
Jun 13, 2007 10:04 AM
by: tjquinn
|
|
|
|
|
|
|
Major Application client frustrations
Posted:
Apr 18, 2007 6:22 AM
|
|
|
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
|
|
|
|
|
|
|
Re: Major Application client and ORB frustrations
Posted:
Apr 18, 2007 7:43 AM
in response to: florianbruckner
|
|
|
Hello, Florian.
Thanks for taking the time to write down your frustrations. It's important that we hear all sides so we can work on what's most important to the most people.
Several of the issues you raise pertain to the ORB, so I've asked that team to respond as well. (I've also altered the subject of your post slightly to reflect that).
As for the app client container and Java Web Start concerns you mention:
Footprint - We very much want to drastically shrink the footprint precisely because of how its size inflates the initial download time.
I expect you realize this - but I'll say it for others who might not know - that once an end-user has launched one app client this way then for future launches Java Web Start will use the local, cached copies of those JARs and will not download them again - unless the JARs have changed in the meantime.
The organization of the JARs for all of GlassFish may change quite a bit in V3, and it makes sense for us to attack the app client container footprint problem at the same time.
Added customization of the generated JNLP documents - This is also an improvement we very much want to make. Issue 1118 records this RFE but it's good to hear how important it is to individual developers.
Usability - As I have written elsewhere, our initial implementation of Java Web Start support was intended to allow people to get going with this feature and to collect feedback on what further requirements we should try to address next. I feel it has met both of those goals. We continue to use your feedback and that from quite a few others in planning our V3 work.
I have to say that not everyone shares your view that the feature is "unusable" although I certainly see how it falls short in your situation. As with any engineering effort, we had to balance what we wanted to accomplish initially against the people and time we had to do it and that led to some tough choices. Having said that, there are some developers who have successfully deployed using this feature and are quite happy with it.
I think many of your concerns will be addressed as we improve this feature in future releases, I hope sooner rather than later. I trust as that happens we can count on you and other developers using the feature to make sure those changes are meeting your needs.
- Tim
|
|
|
|
|
|
|
|
|
Re: Major Application client and ORB frustrations
Posted:
Apr 19, 2007 3:06 AM
in response to: tjquinn
|
|
|
Dear Tim,
thanks for your response. I agree with you on almost everything. For most of the issues you mention there is a workaround that is feasible. What hits us most are the ORB related problems, and it may well be that for each of them is a workaround available, I just have not found it, even when going through the source code of the ORB.
Nevertheless there is one little consequence with the JNLP support. In every document found on this website it is strictly recommended to use a portable EJB client. The only way to achieve this is to go through the application client container, which in turn can either be invoked from the command line, or through the Glassfish JNLP support. With the custom Webstart WAR, you loose all this and have to go the non-portable way (being strictly discouraged throughout all documents).
So what is really missing is either a flexible JNLP container within Glassfish OR documentation how to invoke the ACC from a custom JNLP, which would be sufficient.
I hope I could bring the JNLP issue a bit into more context. And let me add that I very much appreciate the effort of the Glassfish team to deliver a world-class application server - its just issues that need to be worked on and they didnt seem to be a priority initially, given the fact that most J2EE apps still use a web frontend.
best regards,
Florian
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 18, 2007 8:17 AM
in response to: florianbruckner
|
|
|
|
|
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@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@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>
>
>
[edson.richter.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 19, 2007 5:27 AM
in response to: Edson Carlos Er...
|
|
|
Dear Edson,
do you have a pointer or a name for that module? I was not able to find anything going into that direction?
best regards
Florian
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 19, 2007 6:27 AM
in response to: florianbruckner
|
|
|
|
|
Hi!
Under Update Center -> NB Extras -> Miscelaneous -> Export EJB Client Jar:
Module Size: 13 KB
Author: Lukas Jungmann
Release date: 2006/10/19
Provides support for exporting client jar from some EJB module.
I expect this helps.
Regards,
Edson Richter
glassfish@javadesktop.org escreveu:
> Dear Edson,
>
> do you have a pointer or a name for that module? I was not able to find anything going into that direction?
>
> best regards
>
> Florian
> [Message sent by forum member 'florianbruckner' (florianbruckner)]
>
> http://forums.java.net/jive/thread.jspa?messageID=213136
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>
>
>
[edson.richter.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 19, 2007 7:27 AM
in response to: Edson Carlos Er...
|
|
|
Hi Edson,
thanks for the pointer, but this is not what really helps in reducing the footprint.
What the module does is to create a service client jar, i.e. a jar file that contains only the interfaces needed to access the EJBs from a client, at the same time not distributing the implementation of the EJB.
Whats so heavy in the footprint are the appserv*.jar, so a lean client would need a stripped down version of that jar, and unfortunately this is not provided by the module you mention.
best regards,
Florian
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 18, 2007 11:36 AM
in response to: florianbruckner
|
|
|
Hi
yes we've shared the same frustrations with the ACC as is. Above the footprint and lack of webstart customization problems for which we could live with, we found the major performance problem with the ORB rmi/iiop implementation sufficiently blocking to continue with the ACC.
In our application, we must deploy on clients with low bandwidth, and we found unacceptable responses times in our tests.
So we decided to switch to a lighter protocol with Hessian and we are really happy with it because we have now:
- low footprint, the client jars size downed to < 300k
- no more firewall issues, all http
- no more performance issues, responses times in certain cases downed from 40s to less than 1s
this was at the cost of refactoring a bit our architecture and loosing all the benefits of having the ACC with depency injectioin, automatic security etc.
I believe the ACC is a big step for enterprise java clients, but it is not completely production ready as is and needs some more work to adress these issues, but i m quite confident with what Tim said that in glassfish v3, it will be another beast 
Best regards
Yves.
Message was edited by: ygillet
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 18, 2007 12:02 PM
in response to: ygillet
|
|
|
Honest feedback is the best, if not always the most comfortable, to receive.
I can understand why some people might choose not to use ACC and/or the Java Web Start support for app clients in their solutions.
I would urge anyone with specific issues to be sure to file bugs or enhancement requests, as appropriate, using IssueTracker as early as they can. Thanks to several in the community who already have done just that, because IssueTracker issues are important as we plan our priorities for current and future releases.
And I should emphasize that GlassFish is an open-source project, so external committers who want to help work on these sorts of issues would certainly be welcomed!
- Tim
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 28, 2007 2:12 PM
in response to: florianbruckner
|
|
|
Hi,...
I've got the same error on my clients. I can only run my client on the same machine where the server is running.
I really don't know what else I can do to solve this. Doe's any one have some idea?
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)
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 28, 2007 5:06 PM
in response to: adilsonlc
|
|
|
Hi.
Are the errors you included from an attempt to have the client use a server on another system? I assume that's the case, because the error reports that it cannot connect to localhost, which I also assume means you did not have a server running there when you launched the client.
What do you do to try to use a different server?
Are you using the appclient script to start the client? If so, it by default uses the sun-acc.xml file in the ${install-dir}/domains/${domain-name}/config directory to find out what host and port to use in connecting to the server. When you create a domain (which is done automatically as part of installing or as part of the maven configure-runtime or configure-cluster) a default sun-acc.xml is generated.
Check the contents of that file and edit it - or you can make a copy, edit the copy, and specify
-xml <path-for-the-revised-sun-acc.xml>
when you run the appclient script to launch the client.
Check that out and please post your results.
- Tim
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 30, 2007 9:54 PM
in response to: tjquinn
|
|
|
I have my servers only on Linux systems. My clients are both Linux and Windows. Unfortunatelly my client app doesn't run on both, just on the server.
They don't access my ejb on both ways, appclient and javaws.
I agree with you that the problem is that my client cannot reach the server, I just don't know why.
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 30, 2007 5:35 AM
in response to: adilsonlc
|
|
|
Are you running the server on Linux?
Try the following: In the Server Admin Console goto Configuration->ORB->IIOP Listeners and add a second listener with the "Network Address" set to IP-address of the server. Remember to restart your server.
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Apr 30, 2007 10:05 PM
in response to: mikael
|
|
|
I guess you've found the answer for the idea our friend tjquinn had. Maybe my server isn't binding the address (I had no idea SJAS needed to do that).
Unfortunately, today is a holiday in Brazil, so I'll have to wait for tomorrow to try your suggestion at the office. I just have my own computer at home.
Here at home I've tried changing the address on orb-listener-1 from 0.0.0.0 to 10.1.1.2 that is my ip address at home, and guess what, I made my local try to run my client application show the same problem accessing my ejb's as I get when running them remotely.
As soon as I could make a real test across a network I'll get in touch.
I'll create an orb-listener-2 pointing to my server IP to see what happens.
By the way, yes all my servers run Ubuntu 7, and on my clients you'll find both linux and windows machines.
---- wrote next day ------------------
Yes you where right. Changing the address on orb-listener-1 from 0.0.0.0 to 10.1.1.2 (my server IP) made all work perfectly. Now my server can deliver my resources to my appclients the network with no problems.
Now the clients can run using both appclient and java web start.
Thanks for your help.
Message was edited by: adilsonlc
Message was edited by: adilsonlc
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
May 1, 2007 5:42 AM
in response to: florianbruckner
|
|
|
Hello everybody,
surfing the sourcecode and talking to people led to a partial relieve for our communication problems. Eventually, setting these properties resolved some of our issues (they are not documented or official, but seem to work without sideeffects on V1UR1):
System.setProperty(ORBConstants.COMMUNICATIONS_RETRY_TIMEOUT, "" + (5*1000));
This property controls how long the ORB retries to submit a call. In contrast to what I believed (which was a retry count), it is a timeout. The default is 60 seconds, which is awful lot for a login. Reducing this to 5 seconds got at least almost immediate response for the user that, for example, the host is not reachable.
Another setting is to control the response timeout (I am not quite sure what exactly this means in terms of transport, but it does not seem to prevent large messages from being transmitted, even if the time for their transmission exceeds the timeout). I chose to set this value extremely low (in contrast to the 30 minutes that are used by default), and it did indeed improve our situation.
System.setProperty(ORBConstants.WAIT_FOR_RESPONSE_TIMEOUT, "" + (2*1000));
This may need to get some finetuning on our side to also take into account longer processing time on the server.
There is another property that could be set (ORBConstants. TRANSPORT_TCP_TIMEOUTS_PROPERTY), but there was nobody I talked to who could explain what it means and the values seem to be sufficiently low anyway:
// transport read tcp timeout property, colon separated property
// with syntax <initial time to wait:max read giop header time to
//
The default values for this property is "100:6000:300:20"
best regards,
Florian
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
May 3, 2007 11:28 AM
in response to: florianbruckner
|
|
|
Florian,
What version of Java are you using? I'm using version 6 (Update 1) and
I don't seem to have any of the ORBConstants you mention. I'm looking
at the source for:
com.sun.corba.se.impl.orbutil.ORBConstants
Are you setting those properties in your application client or on the
server?
I also share some of your frustrations. Mainly:
1. The lack of configuration options.
2. The lack of fault tolerance / error handling.
A lot of the issues are not impossible to work around, but it's time
consuming and frustrating to find a solution. The ORBConstants you've
posted is a perfect example of the 'type' of thing I feel like I'm
dealing with continually. I would expect network timeouts, retries,
etc. to be well documented, easy to set properties, but they're not.
As for fault tolerance / error handling it's one of the things that
frustrates me the most. The thing that's been annoying me lately is
trying to figure out all the runtime exceptions I need to catch and deal
with. For example:
org.omg.CORBA.COMM_FAILURE
I 'think' I understand why it's a runtime exception, but I'm not
'positive', so I won't speculate. I don't like to use blanket
catch(Exception e)
type code, but I'm not quite sure how to deal with some of the ORB
stuff. I don't have a clue what kind of / how many runtime exceptions
there are that I might need to deal with. Obviously I can figure it
out, but it's not the type of thing I want to be spending my time on.
NAT traversal isn't an issue for me right now, but I never even
considered the possibility of something not being NAT friendly these days.
In my opinion, a lot of the issues you've described can be solved with a
better application client container implementation. One of the main
things we need is the option of implementing callback handlers for
runtime configuration, logins and error handling. I've brought up all
of these issues on the mailing list before and was satisfied with the
responses I received. In fact, Tim (tjquinn) acknowledged some of my
concerns and was the person who suggested that a callback mechanism
would be the most likely solution to some of the issues I described.
>From what I gather, the current application client container
implementation was intended to be a 'starting point' rather than a
robust solution. I think it's been fairly successful in provoking
discussion and am confident the developers will improve with the next
version.
I'm still developing, so am content to live with some of the
deficiencies for now and deal with them once I'm closer to deploying. I
intend to contribute to the discussion a bit more at that time.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
May 3, 2007 1:11 PM
in response to: Ryan J
|
|
|
Hi Ryan,
to answer the technical part of your message: the ORB in Glassfish' app client container lives in a different package than the one shipped with Java Standard Edition. com.sun.corba.ee.impl.orbutil.ORBConstants is the correct classname, and that is the one used.
It is hard to understand that there are two implementations of CORBA, one being in the Java Standard Edition and another, from what I understand completely separated one as part of the client container. Nevertheless, this has already been answered on various mailing lists and is for (again, my understanding, I may be wrong) historical reasons.
Florian.
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
May 5, 2007 1:06 AM
in response to: florianbruckner
|
|
|
I just found this thread, and thought I should add some recent developments.
First, Florian is right: the two ORBs are separated for historical reasons.
The reason for this is that it takes a long time to release a new ORB
in the JDK, and during that time, we are developing enterprise features
for the ORB in the app server. This makes it very difficult to get to the
point where we can rely on the ORB in the JDK, and even if we could,
there are problems with getting to an app server that requires a particular
release of the JDK as a minimum level. That said, I'd like to sync up
the ORB in JDK 7 with the current GlassFish ORB at some point.
If I can get to that, we will eventually be able to make the footprint
of downloaded apps smaller when the client is running on JDK 7.
Second, our next ORB integration will include a couple of changes of
interest to this discussion. First, I've moved all of the dynamic stub
generation off of BCEL and on to the codegen library, which uses ASM
for generating bytecode at runtime. This means that a future integration
(NOT the one coming next week) will remove the ORB's copy of BCEL,
which will reduce the ORB footprint by around 600K. I also need to
look at some other areas (e.g. activation and pcosnaming) that are
not needed, and perhaps reduce the footprint even further.
I'll post this, and then post another discussion about retries.
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
May 5, 2007 1:32 AM
in response to: florianbruckner
|
|
|
Now, about the retries. We've known for some time that there were some
issues with ORB retries. Recently someone filed a high priority bug
(6546045, which was a duplicate of 6394769) complaining about too many
retries. I wrote a simple test to reproduce this, and found that the ORB
was re-trying 56000 times per minute on my test machine (JDK 1.5_10,
Ubuntu 6.06, Athlon 64 3500+ with 2 GB RAM).
The problem is that the ORB needs to retry the entire list of endpoints
in a cluster, and wrap from the end of the list to the beginning. The
old code intended to use a simple exponential backoff in this case,
but it ONLY applied the wait with backoff when the error was either a
TRANSIENT or a COMM_FAILURE connectionRebind (both COMPLETED_NO
of course). Any other COMM_FAILURE COMPLETED_NO was treated as
a "try the next endpoint" kind of retry. Now, this is good in the cluster case,
because we want to try the next endpoint quickly. But we also don't want to
try all of the endpoints over and over again if they all fail.
The fix is to introduce another use of TcpTimeouts here, and to record
the failed endpoints in a list, until we find that the next endpoint to try
is already in the list. In that case, we clear the list, sleep for the next
timeout, and then start retrying again. That way, we try every endpoint once,
and then sleep until we try again, or timeout.
This brings us to the topic of the ORB config parameters in
com.sun.corba.ee.impl.orbutil.ORBConstants (by the way, the ORBs
in the JDK and the App server are really the same code base snapshotted
at very different times. The names are renamed automatically at build tinme).
The relevant constants are:
TRANSPORT_TCP_TIMEOUTS_PROPERTY
This one controls the retry behavior when the ORB is reading data
and does not get all of the data at once. It is a TcpTimeouts.
The defaults are 2000:6000:20
TRANSPORT_TCP_CONNECT_TIMEOUTS_PROPERTY
This is the one relevant to this discussion. It controls
how the ORB behaves on the client side when attempting to
connect to an IOR (the wire rep of an EJB reference).
This is also a TcpTimeouts.
The defaults are 250:60000:100:5000
WAIT_FOR_RESPONSE_TIMEOUT
This controls how long the client waits for a response AFTER successfully
sending a request. The default is 30 minutes.
Both TcpTimeouts use the same scheme:
initial:max:backoff:maxsingle, where
initial is the first timeout in milliseconds
max is the maximum wait time (before the last wait, which can go
over this time) in milliseconds
backoff is the backoff factor by which the timeout is increased each time
(the multiplication is actually by (backoff+100)/100, so 20 is 1.2 and
100 is 2, but we avoid any use of floating point here)
maxsingle is the maximum single wait time
I've removed the old COMMUNICATIONS_RETRY_TIMEOUT.
You can certainly configure these any way you would like.
Please let me know how this works for you (it will probably be another 2 weeks
before you can get a build with this ORB in it). Also, I'd like to know
if there are any needs for fine grained control over timeouts. Right now the
granularity is the entire ORB, so you cannot set a timeout that applies
to only a single request, or a single EJB reference.
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
May 5, 2007 1:55 AM
in response to: florianbruckner
|
|
|
Just a few more comments:
> Hello everybody,
>
>
> - 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?
This one is interesting. I know what ORB.init does both in the ORB
and in the app server, but 20 seconds is a long time. Could you share
your profiling info with us?
>
> - 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.
>
It should suck less now, as some significant performance problems
have been fixed. Which build are you using? There was a big
problem with the huge classpath of the app server creating a huge
codebase interacting with a bug in the marshalling code that did not
properly handle repeated codebase strings. This fix is certainly in the recent
builds for the past few months.
We also greatly improved how the ORB reads messages from a socket.
It reads all available data as fast as possible, instead of reading 12
bytes then the message size. Internal benchmarks show a 50% or so
increase in the throughput.
>
> - 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.
>
We'll need to look at this again. We are mainly focusing on
throughput oriented tests (like SpecJ) at this point.
> - 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:
>
This should be better once the latest ORB is integrated (see my
previous post). This is exactly the problem I fixed.
>
> - 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.
We don't directly use a count, but the TcpTimeouts I described
give you more or less the same capability.
>
> - 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.
Wait for connect is covered. The ORB also has settable
high water marks on the inbound and outbound connection caches,
which will cause connections to be closed. But so far we have
not seen a need to directly age out connections.
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.
You're right; I don't think there is a way to override this.
We do need to control this in order to support CSIv2.
Again, with the new timeouts, do you need anything else?
> 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.
You could use the request timeout to handle this,
if the granularity is OK (see previous post).
> 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()?
In general, yes, but many thread could choose to ignore
interrupt, for example a while(!condition) wait loop would
have no choice but to spin and continue waiting if interrupted.
We could probably make the CorbaResponseWaitingRoom
code respond to an interrupt() call, but I'm not sure if that's a
good idea or not.
Ken.
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
May 5, 2007 3:24 AM
in response to: kcavanaugh
|
|
|
Hi Ken,
thanks a lot for your support.
We are using V1UR1 currently. We are getting close to acceptance and
production, due once we sorted out some showstoppers. So V2 is not an
option for us.
> Just a few more comments:
>
>
>> Hello everybody,
>>
>>
>> - 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?
>>
>
> This one is interesting. I know what ORB.init does both in the ORB
> and in the app server, but 20 seconds is a long time. Could you share
> your profiling info with us?
>
I will take a Netbeans profiling snapshot and follow up with that.
>
>
>> - 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.
>>
>>
>
> It should suck less now, as some significant performance problems
> have been fixed. Which build are you using? There was a big
> problem with the huge classpath of the app server creating a huge
> codebase interacting with a bug in the marshalling code that did not
> properly handle repeated codebase strings. This fix is certainly in the recent
> builds for the past few months.
>
> We also greatly improved how the ORB reads messages from a socket.
> It reads all available data as fast as possible, instead of reading 12
> bytes then the message size. Internal benchmarks show a 50% or so
> increase in the throughput.
>
We currently use ORBUseNIOSelectToWait=false, and this alone reduced it
by 50%. We havent tested with newer versions of Glassfish as this is
currently not an option.
>
>
>> - 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.
>>
>>
>
> We'll need to look at this again. We are mainly focusing on
> throughput oriented tests (like SpecJ) at this point.
>
Unfortunately latency ia critical for our application, and I assume for
most rich clients that use fine grained operations. We have a lot of
small operations going against our service layer (mostly data requests),
and batching them is not really an option (we do a lot of lazy fetching
of data).
>> - 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.
>>
>
> We don't directly use a count, but the TcpTimeouts I described
> give you more or less the same capability.
>
>> - 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.
>>
>
> Wait for connect is covered. The ORB also has settable
> high water marks on the inbound and outbound connection caches,
> which will cause connections to be closed. But so far we have
> not seen a need to directly age out connections.
>
Having settings in the ORB should be sufficient, at least if their
behaviour is documented. I already found out about some other parameters
(mainly WAIT_FOR_RESPONSE_TIMEOUT) and tried to set them low, but this
had sideeffects. For example, if the operation we call has a huge
payload (lets say an image of 3000K), the request times out before it
arrives fully on the server. At least we do not see the method entry on
the server side when we get the Exception on the client side for this
special case.
Nevertheless, WAIT_FOR_RESPONSE_TIMEOUT may be the wrong setting, I will
try the paramters you described in your earlier message.
> 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.
>>
>
> You're right; I don't think there is a way to override this.
> We do need to control this in order to support CSIv2.
> Again, with the new timeouts, do you need anything else?
>
I don't think so. If timeouts can be specified properly there should not
be a reason for this.
>
>> 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.
>>
>
> You could use the request timeout to handle this,
> if the granularity is OK (see previous post).
>
>
>> 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()?
>>
>
> In general, yes, but many thread could choose to ignore
> interrupt, for example a while(!condition) wait loop would
> have no choice but to spin and continue waiting if interrupted.
> We could probably make the CorbaResponseWaitingRoom
> code respond to an interrupt() call, but I'm not sure if that's a
> good idea or not.
>
This is more or less a question of request monitoring. You were
mentioning this earlier:
> Please let me know how this works for you (it will probably be another 2 weeks
> before you can get a build with this ORB in it). Also, I'd like to know
> if there are any needs for fine grained control over timeouts. Right now the
> granularity is the entire ORB, so you cannot set a timeout that applies
> to only a single request, or a single EJB reference.
Definitely, yes. Our operations are with varying granularity. For
example we might have a very small request just pushing a single value
to the service layer. On the other hand we have very huge request, when
we transmit a BLOB to the server. So therefore specifying the timout on
a per-request basis would be a good thing to do (at least for our use
case).
Another thing is to monitor the state of the operation and to make it
cancellable. I could, for example, put the remote operation call on one
thread and have another one monitoring the request, giving the user some
feedback about the current state of the application. Thats also when
interrupting becomes relevant, as the user may choose to cancel the
current operation (again, for example when uploading a BLOB), or we may
want to show some progress information when transmitting a large amount
of data.
If you want we can discuss this in detail (I think that would be a bit
out of scope for this thread).
Florian.
> Ken.
> [Message sent by forum member 'kcavanaugh' (kcavanaugh)]
>
> http://forums.java.net/jive/thread.jspa?messageID=215664
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
--
3Kraft Software | Applications | Development
Wasagasse 26/2
1090 Vienna
Austria
Phone: +43 (0)1 920 45 49
Fax: +43 (0)1 920 45 49
Mobile: +43 (699) 102 53 901
E-Mail: florian.bruckner@3kraft.com
Web: http://www.3kraft.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
May 5, 2007 1:57 PM
in response to: Florian Bruckne...
|
|
|
> Hi Ken,
>
> thanks a lot for your support.
>
> We are using V1UR1 currently. We are getting close to
> acceptance and
> production, due once we sorted out some showstoppers.
> So V2 is not an
> option for us.
OK. Unfortunately all of the performance work is in V2.
It would be possible to port some, but not all of these features
to a patch on V1, but I don't know what the support and sustaining
plans are there. The big item is likely to be the codebase problem
I mentioned, and that would be fairly simple to patch, but that would
require action by the sustaining team and a support contract.
> >Profiling shows that the time is
> spent
> >> in ORB.init()... WTF is it doing?
> >>
> >
> > This one is interesting. I know what ORB.init does
> both in the ORB
> > and in the app server, but 20 seconds is a long
> time. Could you share
> > your profiling info with us?
> >
> I will take a Netbeans profiling snapshot and follow
> up with that.
OK, thanks.
> >
> We currently use ORBUseNIOSelectToWait=false, and
> this alone reduced it
> by 50%. We havent tested with newer versions of
> Glassfish as this is
> currently not an option.
Making NIO select both perform well with small numbers of connections
and scale well with large numbers is tricky. Again, some major improvements
are available in V2, and these are definitely too much to port back to V1.
> >
> >
> >> - 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.
> >>
> >>
> >
> > We'll need to look at this again. We are mainly
> focusing on
> > throughput oriented tests (like SpecJ) at this
> point.
> >
> Unfortunately latency ia critical for our
> application, and I assume for
> most rich clients that use fine grained operations.
> We have a lot of
> small operations going against our service layer
> (mostly data requests),
> and batching them is not really an option (we do a
> lot of lazy fetching
> of data).
OK. I'll take a look at this when time permits.
> >
> Having settings in the ORB should be sufficient, at
> least if their
> behaviour is documented.
OK. We can follow up with docs on the timeout settings for V2.
> I already found out about
> some other parameters
> (mainly WAIT_FOR_RESPONSE_TIMEOUT) and tried to set
> them low, but this
> had sideeffects. For example, if the operation we
> call has a huge
> payload (lets say an image of 3000K), the request
> times out before it
> arrives fully on the server. At least we do not see
> the method entry on
> the server side when we get the Exception on the
> client side for this
> special case.
>
> Nevertheless, WAIT_FOR_RESPONSE_TIMEOUT may be the
> wrong setting, I will
> try the paramters you described in your earlier
> message.
OK, but remember that the CONNECT version of TcpTimeouts is only
available in V2 (in a couple of weeks).
> >> 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()?
> >>
> >
> > In general, yes, but many thread could choose to
> ignore
> > interrupt, for example a while(!condition) wait
> loop would
> > have no choice but to spin and continue waiting if
> interrupted.
> > We could probably make the CorbaResponseWaitingRoom
> > code respond to an interrupt() call, but I'm not
> sure if that's a
> > good idea or not.
> >
> This is more or less a question of request
> monitoring. You were
> mentioning this earlier:
>
> > Please let me know how this works for you (it will
> probably be another 2 weeks
> > before you can get a build with this ORB in it).
> Also, I'd like to know
> if there are any needs for fine grained control over
> timeouts. Right now the
> granularity is the entire ORB, so you cannot set a
> timeout that applies
> to only a single request, or a single EJB reference.
> Definitely, yes. Our operations are with varying
> granularity. For
> example we might have a very small request just
> pushing a single value
> to the service layer. On the other hand we have very
> huge request, when
> we transmit a BLOB to the server. So therefore
> specifying the timout on
> a per-request basis would be a good thing to do (at
> least for our use
> case).
>
> Another thing is to monitor the state of the
> operation and to make it
> cancellable. I could, for example, put the remote
> operation call on one
> thread and have another one monitoring the request,
> giving the user some
> feedback about the current state of the application.
> Thats also when
> interrupting becomes relevant, as the user may
> choose to cancel the
> current operation (again, for example when uploading
> a BLOB), or we may
> want to show some progress information when
> transmitting a large amount
> of data.
>
> If you want we can discuss this in detail (I think
> that would be a bit
> out of scope for this thread).
I think that would be a good idea. And we should really discuss
this in a separate thread.
Ken.
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Jun 13, 2007 5:53 AM
in response to: kcavanaugh
|
|
|
Hi Ken,Tim,
Quick question for you.
Is there an intention to make this timout more user-friendly, i.e. maybe the ORB or ACC pop a window to the user telling him/her that there is currently a communication error, would you like to retry, something like that... Right now, if you don't have your console open, you have no idea what is going on...is the network or server down or just really slow? The user just doesn't know.
The default behavior I'm noticing on b50 is that an Application Client (started with WebStart) just keeps retrying while logging its problem in the console. From the user's point of view, there's nothing happening (I suspect typical users will NOT have their Webstart console opened, or if they do, I doubt they would go through the stack traces to understand what is happening).
I'll be happy to file an RFE for this, I just didn't want to do that if it's already on the roadmap.
Francis
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Jun 13, 2007 10:04 AM
in response to: chiss
|
|
|
Hi, again, Francis.
I think at the moment this is an ORB decision. If the ORB continues to retry without returning control to the client and/or the ACC then there are no exceptions thrown that the ACC could catch and display to the user in a dialog box (for the Java Web Start case).
I would suggest that you go ahead and create an RFE for the orb component if the confning options Ken has described don't do what you'd like.
- Tim
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Jun 8, 2007 12:54 PM
in response to: florianbruckner
|
|
|
Hi everyone
I MUST add dissapointment.
> 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.
We need to port our application to a platform that offers us the environment to let us implements useful new features. We weighted several platforms and languages, including c#.net, pascal(delphi), java, c/c++, and took the decision to go with java. Portability, decent learning curve, readily available support, etc. We have to develop gui forms. No problem, we were confident that we could handle the swing's lack of data binding. Among several new features, two were outlined as VERY IMPORTANT and in fact defines our project:
-High connectivity
-Easy deployment
A few days ago we decided to run a small connectivity test. Local tests: very well, Intranet tests, okey; Internet tests, IMPOSSIBLE.
>
> - 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
>
Write once, runs everywhere: FALSE, besides that huge amount of jars, configuration, etc that MUST be manually made; java versions might make your application goes wrong. That is a real setback.
> - 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?
Till today, I thought that something in our configuration was wrong, but we've encountered slow performance, and even server (Win2k3 server) hangs. Serious setback.
>
> - 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.
Now connectivity is not really possible, is it? Or do we have to resource to slow http based webservices?
Here is my problem, with deadlines over us, WRONG development platform selection, and Java/ORB POOR issues resolutions, should'n I be dissapointed?
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Jun 8, 2007 1:50 PM
in response to: freddyforjava
|
|
|
I'm sorry you have found this so frustrating.
I have a few questions I hope you will answer to help clarify a few things and provide some important details.
I assume because you are posting in this forum that you have developed a Java EE application and are deploying it to GlassFish and your frustration comes from the built-in support for launching app clients using Java Web Start. I ask because you didn't refer to GlassFish in your post. (You did mention the number of JARs.) I just want to make sure you are not talking about a non-Java EE application launched using Java Web Start from a standard web container (either the web container that is part of GlassFish or some other web server).
Assuming you are using GlassFish and the built-in Java Web Start support, what build of GlassFish are you using? Have you had the same problems - or the absence of problems - with other builds?
What release of Java are you using? Have you had the same problems - or the absence of problems - with other releases?
The issue with the large number and large size of JARs that are needed is well-known and much-discussed. If you've read some of the other posts related to the Java Web Start support in GlassFish in this forum you know it's something we're very eager to address in the next major release of GlassFish. We know this is a hardship, and we wish we could have done something about it already. It just was not feasible with the time and resources we had. I know that doesn't help you now.
Also, I also hope you know that this large download is needed only for the first app client launch performed from the server. Future launches of any app client - the same one or different ones - from the server do not repeat the big download.
You referred to manual configuration that is required. Please be more specific...what configuration are you referring to?
The slow performance you mentioned... Is this happening after the download has completed before you see the initial GUI display from your app client? In response to user actions in the GUI? At some other time?
Is there any logging output in the server's server.log file that might indicate any problem? This might help identify the cause of the hang. Did you use the jstack utility to dump the thread stacks?
- Tim
|
|
|
|
|
|
|
|
|
Re: Major Application client frustrations
Posted:
Jun 11, 2007 8:56 AM
in response to: tjquinn
|
|
|
> I assume because you are posting in this forum that
> you have developed a Java EE application and are
> deploying it to GlassFish and your frustration comes
> from the built-in support for launching app clients
> using Java Web Start. I ask because you didn't refer
> to GlassFish in your post. (You did mention the
> number of JARs.) I just want to make sure you are
> not talking about a non-Java EE application launched
> using Java Web Start from a standard web container
> (either the web container that is part of GlassFish
> or some other web server).
As I pointed out we are in the middle of developing a JAVA EE application.
At the moment of the issues we were using SJAS 9 update 1. We did start using JWS, but later on i'll explained why we are not using it anymore.
>
> Assuming you are using GlassFish and the built-in
> Java Web Start support, what build of GlassFish are
> you using? Have you had the same problems - or the
> absence of problems - with other builds?
We understand that SJAS 9 is sun adoption of GlassFish project, so we think that we are in a GlassFish environment. This is our first usage of GlassFish project.
>
> What release of Java are you using? Have you had the
> same problems - or the absence of problems - with
> other releases?
On the development site we are using Sun Java Build 1.6.0_01-b06.
We've tested on Clients running Java 1.6 and Java 1.5_07.
>
> The issue with the large number and large size of
> JARs that are needed is well-known and
> much-discussed. If you've read some of the other
> posts related to the Java Web Start support in
> GlassFish in this forum you know it's something we're
> very eager to address in the next major release of
> GlassFish. We know this is a hardship, and we wish
> we could have done something about it already. It
> just was not feasible with the time and resources we
> had. I know that doesn't help you now.
We were trying during this weekend the Hessian/Burlap protocol, since we are
running out of time, we need to solve the problem now. Our client deployment is
now reduced to 2.1Mb.
If useful, what I think is that jars are very dependent to each other, so if i only need one feature of the EE implementation, I'll finish releasing the whole jar's into the client. Maybe recomposing jars into working units might help. Java design allows you to have the same class repeated in several jars, even that is not a good technique, certainly is a practical one. Am I using EJB? a simple and non dependent client jar for EJB, using Web services? a simple independent jar for Web services. My 2 cents.
>
> Also, I also hope you know that this large download
> is needed only for the first app client launch
> performed from the server. Future launches of any
> app client - the same one or different ones - from
> the server do not repeat the big download.
We do know that, but webstart is not our preferred client launch method, cause we
need to send client dependent parameters.
>
> You referred to manual configuration that is
> required. Please be more specific...what
> configuration are you referring to?
I was referring to the client side, we have decided to package client jars and libs to deploy on the client, because on jnlp, you have to go into client deployment directory and manipulate some xml to have a sucessfull conection to a server. That is not very difficult, in fact is quite easy, but on several client .... On our approach a simple start up parameter will do, and can be automatically done on the client with a simple script. That's a lot easier than let jnlp do it trick and then go into each client to set it up.
>
> The slow performance you mentioned... Is this
> happening after the download has completed before you
> see the initial GUI display from your app client? In
> response to user actions in the GUI? At some other
> time?
I am developing on a 1.83GHZ DuoCore with 2GB ram, and overall performance just look okey. Testing the gui client on a Ubuntu Feisty Linux 1.2GHZ Athlon, component rendering is not smooth, RMI is pretty slow (seems that the marshalling/unmarshaling takes has a lot of overhead).
I really hate to compare technology, but we did test using Hessian, and performance on the same client is noticeable much better. We will try to do both tests on a Ubuntu Edgy Linux client running at 800MHZ 256MB ram, after we upgrade it's java to 1.6. By the way, gui does not render object well if using 1.5_07 java implementation.
>
> Is there any logging output in the server's
> server.log file that might indicate any problem?
> This might help identify the cause of the hang. Did
> you use the jstack utility to dump the thread
> stacks?
The hang that we experienced, did not report any exception at all, everything was performing but at an incredible slow rate. Kind of remind me when you have low memory and begin to do swaps of large memory blocks that are needed at the same time in memory to perform a specific task. A few minutes later CPU usage went up to 100% on a java process (can't tell if Tomcat, or SJAS). About 15 minutes later we've decided to turn off our server (YES unplug it from the outlet). The server is a 3.0GHZ P4 4GB ram.
>
> - Tim
Thanks Tim, this is one of the reason that we stick to Java, the community support is REALLY into supporting...
Federico
|
|
|
|
|
java.net RSS
