Challenges using Icefaces
I would just like to take a quick moment and inform anyone about Icefaces, and the challenges I have faced using it. Take it from my current experience (version 1.6.1 and 1.6.2) and the words of an Icefaces developer that since Icefaces "is a stateful technology......providing enhanced features for the user....but require server-side resources to do so." That last statement has been our recent struggle.
Unfortunately, on my current project we don't have the luxury of lots of server-side resources. It's disappointing to say we have to share a single server that is already running IIS; then we have to run Jboss and MS SQL on the same machine. Obviously this is not by choice and doesn't look to change in the near future.
It might be Icefaces never intended their framework to run in such a limited environment. But that really doesn't help me now. It would be great if they published information about minimum hardware requirements, especially if they are aware of performance issues. Equally important I am sure we have strayed away from best practices in using Icefaces.
Please don't ask me why we choose to use Icefaces in the first place (I wasn't with the group at the time). But I assume it was a lack of knowledge of how Icefaces works, and we weren't aware of the environment limitations. Either way, we are facing difficult challenges that are very frustrating.
For example, we recently had severe problems with an editable table which was sortable (much like an excel spreadsheet). When users clicked twice on the header to sort, the data appeared to be sent twice and some how our data got corrupted. Consequently we had to disable the ability to sort.
Also, based on my understanding of Icefaces, it appears that all clients maintain a constant connection with the server. I am assuming this is what the Icefaces developer above was referring to when he says Icefaces is a stateful technology. For some reason, I feel this constant connection would cause challenges for 50-100+ concurrent clients with limited server-side resources.
Hope it helps someone.
11 comments:
Ouch.
James,
I am sorry to hear of your negative experience. It is too bad that you did not reach out to us on our forum for help. We find that, often, performance issues are created at the data access layer where you are binding JSF into the persistence layer. Typically, we don't see performance issues with the presentation layer, the only place ICEfaces extends the standard JSF runtime.
We would be happy to work with you and understand the root of your performance problems. We have many successful projects exhibiting good performance, and I suspect yours could become one too.
Steve Maryka
CTO ICEsoft
@Steve,
I appreciate you taking the time to add a comment. Again, I think some of our problems are more related to our environments limitations causing the appearance that icefaces suffers from performance issues. On the other side though I am not 100% convinced that if we had dedicated servers it would be perfect (meaning I still feel there are some performance issues with icefaces).
Thanks for mentioning the forums. I will encourage my team to seek advice from them. Not sure why, but its still not a habit yet to immediately go there whenever problems arise. Google is the first choice. :)
One particular nasty problem we discovered was having an editable table that had sortable columns caused massive issues when the user double clicked the header to sort. I know they are not suppose to click twice, but he did and consequently it corrupted the data. We have since had to temporarily disable the sort ability. I believe at one point we did go to the forums for help.
Finally, I am personally motivated to gradually phase out our use of icefaces. However, it would definitely be cheaper and probably quicker if we could get valuable advice from the forums on how to fix our scalability issues.
Update,
I have updated the original post Titled "When not to use Icefaces". Yesterday was a bad day and perhaps the way I came across was a little harsh.
For some reason, I feel this constant connection would cause challenges for 50-100+ concurrent clients with limited server-side resources.
Keeping a connection open is needed only for applications that use Ajax Push (page updates initiated by the application without user intervention). If this capability is not needed, ICEfaces can be configured to run in "synchronous mode".
James,
While I share in your frustrations, I don't believe the performance problems are isolated to IceFaces. The developers on the project need to take ownership of their code. There are places that are not efficient that have nothing to do with Icefaces.
I'd consider part of the problem to be learning IceFaces and part to be bad programming/design. After those are fixed, well, then maybe there are points where IceFaces may have problems.
But we should not get a knee jerk reaction to a piece of technology.
I've heard people on this same project complain about using Hibernate and being emphatic about it. Yet, how many projects out there are using Hibernate and having success with it?
As with all tools, there may be limitations that need worked around. That doesn't necessarily mean through all of it out to be replaced by another technology. All too often, replacing the technology just changes where the limitations exist.
Your co-worker on the same project,
jsh
I heard if you went with Grails these problems would all go away - magically! ;-)
50-100+ connections isn't a problem if you are using a server that takes advantage of the java nio package - like Tomcat 6.
We are also facing some kind of performance issues using icefaces.
The application that we are currently working on uses a massive implementation of datatable. Each datatable in a screen stores data that may go upto a 100. As the amount of data increases, there are severe performance issues with the rendering time; the rowselector component works very slowly.And sometimes the system gets a bit unresponsive. This has left many developers frustrated and so we are planning to move on to struts.
i have used icefaces but may not be as extensive as the above authors..
If you think it has performance issues, did you try testing a simple page with some regression testing tool? Then again trying the same thing with a struts based page?
How can you just conclude to travel back in evolution and say you are going to use struts..
if a particular component is not suitable, in this case a row selector component,
1) Try to make sure the sluggishness is not on the business or database layer
2) if you are sure it is at the component level,
think of a work around..with out using row selector component
I hope i contributed something to alleviate your frustration, please don't decide quickly in frustration...
hi all
i' have the same problem with ices faces 1.8.0. I 'm developing an Hr application and when users login to my application some time get stuck and Application hosted in (IBM ) servers but client end we have p4 machines (3GHz) ,there are no problem with source code ,some time when adding users continiosly (inserting) application getting slow
(when i adding 6 or more records) and when i close and open browser again it works fine ,also calender component become unresponsive for some time that kind of issues are in application most time i think this is problem with icefaes since we have power full servers to host application still there are no solution , i'm try to tune glassfish v2 and allocate more resources for fixing this issue
Post a Comment