Developer Notes

Manage server throughput for large downloads

Andrey Chorniy — Fri, 12 Apr 2013 17:14:54 +0000

Manage server throughput for large downloads

Initially I want to explore the solutions to implement Servlet/OutputStream with limited throughput in order to limit single download to some bandwidth.

It looks to be a perfect article which describe the way to distribute/manage server resources for large downloads.

http://nurkiewicz.blogspot.com/2011/03/tenfold-increase-in-server-throughput.html
It help to address a lot of issues, like:

some clients might be more privileged, having bigger or no limit at all,
some might be black listed, resulting in connection rejection or very low throughput
banning IPs, requiring authentication, cookie/user agent verification, etc.
we might try to correlate concurrent requests coming from the same client and use the same bucket for all of them to avoid cheating by opening several connections. We might also reject subsequent connections
and much more…

IcePush integration to web-application

Andrey Chorniy — Wed, 29 Feb 2012 21:57:08 +0000

In one of the previous post I show an example of how a4j-push and a4j-poll were used together. It help to solve several things and optimize code/requests a bit. But in reality it was not “real” push – it just execute periodic lightweight requests (ping server) and asks him – “do you have something new for me ?”. It has serious cons:

number of requests to server is linearly depends on the number of browser windows opened, so more simultaneous users we have connected to the server – the higher loading it will have. So, actually server can be just “overloaded” by that simple requests
with regards to previous point we have to increase the period between requests (to make less impact on the server) – but it is not good for user experience, since it will see the updates with a larger delay

What I expect from Push is that server itself initiate the push-notification to the client. So it does that right at the moment he have to say something new to the client. There is no need to say that such server-to-client communication open a lot of great features and possibilities to web apps.
Here is the diagram from the IcePush docs

It probably not that visible, but in short – “It works great”. IcePush client (javascript) send the list of subscribed topics he want to listen, server genberate the unique ID for him, after that client establish the connection with the server which listen for response from server. Server will notify the client once he will have notifications to send to him. Client call the callback function in which you may do anything (you may call any javascript function as well the a4j:jsFunction if you want to do something through JSF)

As a result, the client browser will be notified right after the event will occur on the server. It will be immediately pushed to the client and after that client is free to do anything he want to react to the notification.

The good thing is that it’s fairly easy to integrate IcePush technology with existent java-web application. The requirement here is just to have a servlet container.
In my case it was existent Richfaces/Seam-2/JSF application (I was afraid that IcePush may conflict with Richfaces, but it is not the case, IcePush can be integrated completely transparent to the JSF/Seam application, since it integrates on Servlet level).
IcePush has a number of ways to integrate, but I’ve chooses the jQuery Integration
You can find all the necessary information about IcePush integration here. I will show the example of integration of IcePush with existent web-application (Seam/Richfaces). I think the integration could be the same for GWT or any other app which is deployed in the Servlet-Container.

Downloaded jQuery integration package
Added the icepush.jar to the WEB-INF/lib

Added the following definition to web.xml

    
        icepush
        org.icepush.servlet.ICEpushServlet
        1
    
    
        icepush
        *.icepush

on the web-page initialized the IcePush with

//loaded required scripts
        
        
//initialized the icepush client

On the server side call the IcePush in the places I want to send notification (as a reaction to some event)
We can call method pushToUserList directly, but I wrapped it so it become asynchronous call, so it don’t slow-down the http-request processing (it may send notifications to several clients and as long it is network operation, it’s may cause a significant delay)

@Name("pushAsyncExecutor")
@Scope(ScopeType.APPLICATION)
public class PushAsyncExecutor implements Serializable {

    private static Log log = Logging.getLog(PushAsyncExecutor.class);

    @Asynchronous
    @SuppressWarnings("unused")
    public QuartzTriggerHandle  pushToUserList (@Expiration Date when,
                                                String pushGroup, Collection userIds) {
        pushToUserList(pushGroup, userIds);
        return null;
    }

    public static void pushToUserList(String pushGroup, Collection userIds) {
        log.trace("Started pushToUserListImpl");
        try {
            PushContext pushContext = PushContext.getInstance(SeamComponentFactory.getServletContext());
            for (Long userId : userIds) {
                pushContext.push(getUserNotificationGroupName(pushGroup, userId));
            }
        } catch (Throwable ex){
            log.error("Failed to push updates", ex);
        }
        log.trace("Finished pushToUserListImpl");
    }

    /**
     * this method generate the push-id for the userId and "pushGroup"
     */
    private static String getUserNotificationGroupName(String pushGroup, Long userId) {
        return new StringBuilder(pushGroup.length() + 16).append(pushGroup).append("_UsR_").append(userId).toString();
    }
}

How to avoid primary page conversation timeout on background requests in Seam. Hacking around Seam request lifecycle

Andrey Chorniy — Mon, 27 Feb 2012 17:55:26 +0000

It will be not easy to read and understand this article, so please remember that you always have a choice to not read it
So,.. in our app we have few background processes on the page which are periodically ping server and update some page parts. Now I think this is not the greatest approach and we should use a real PUSH technology instead of periodic ping in every place where it is possible, but anyway. Our problem was that those requests (if they were handled by Seam Context-Filter) may cause our conversation (the page which user open in the browser) to be destroyed because of conversation timeout. And it really doesn’t work for us, since that really “secondary” requests may kill our primary conversation (especially if we have several browser windows opened)
So, to summarize the problem – “periodic seam requests (ajax requests) cause the destroying of the conversation”, so, if user don’t do any activity on the page during the conversation timeout – the next his action show the “Conversation timed out” message.

Partial solution here could be not use Seam ContextFilter for that requests, but in that case we couldn’t use our Seam components (so it don’t work for us)
The better solution (I think) – is to “Avoid timing-out the conversation in our background requests”. It is what will be described below. However the Much Better Solution would be also “Avoiding the background periodic requests by using a real push approach” – like it is shown in the IcePush integration post. But that not always work, but definitely preferable solution.
So, the workaround for us was to establish Seam environment for the request but don’t cause the the same environment as it is done in the org.jboss.seam.web.ContextFilter but don’t call the Manager.conversationTimeout()

Finally solution looks like 2 classes (created from Seam ContextFilter and ContextualHttpServletRequest)
pretty simple ContextFilterWithoutTimeout (it just create and run ContextualHttpServletRequestWOTimeout)

import java.io.IOException;
import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import org.jboss.seam.web.AbstractFilter;

public class ContextFilterWithoutTimeout extends AbstractFilter {
   public void doFilter(final ServletRequest request, final ServletResponse response, final FilterChain chain)
       throws IOException, ServletException
   {
      new ContextualHttpServletRequestWOTimeout( (HttpServletRequest) request )
      {
         @Override
         public void process() throws ServletException, IOException
         {
            chain.doFilter(request, response);
         }
      }.run();
   }
}

and the ContextualHttpServletRequestWOTimeout which is a copy of ContextualHttpServletRequest with commented call to
// Manager.instance().endRequest( new ServletRequestSessionMap(request) );
so it doesn’t call the touchConversationStack() and Manager.instance().conversationTimeout(session);
as the result our request don’t update anything in the conversation stack and don’t cause the timing-out of conversations
“destroyConversation( conversationEntry.getId(), session );”
it doesn’t mean that conversations will not be timed out – they will, but they will do it as a result of primary user request (or request which is working through Seam ContextFilter). So we don’t change Seam request processing completely, but create the way to make exceptions in request processing, so we can create requests which will not cause our conversations to be timed-out.

   public void run() throws ServletException, IOException
   {
      log.debug("beginning request");

      // Force creation of the session
      if (request.getSession(false) == null)
      {
         request.getSession(true);
      }

      // Begin request and Seam life cycle only if it is not nested
      // ContextualHttpServletRequest
      if (getCounterValue() == 0)
      {
         ServletLifecycle.beginRequest(request);
         ServletContexts.instance().setRequest(request);
         restoreConversationId();
         Manager.instance().restoreConversation();
         ServletLifecycle.resumeConversation(request);
         handleConversationPropagation();
      }

      try
      {
         incrementCounterValue();

         process();

         decrementCounterValue();

         // End request only if it is not nested ContextualHttpServletRequest
         if (getCounterValue() == 0)
         {
//            Manager.instance().endRequest( new ServletRequestSessionMap(request)  );
            ServletLifecycle.endRequest(request);
         }
      }
      catch (IOException ioe)
      {
         removeCounter();
         Lifecycle.endRequest();
         log.debug("ended request due to exception");
         throw ioe;
      }
      catch (ServletException se)
      {
         removeCounter();
         Lifecycle.endRequest();
         log.debug("ended request due to exception");
         throw se;
      }
      catch (Exception e)
      {
         removeCounter();
         Lifecycle.endRequest();
         log.debug("ended request due to exception");
         throw new ServletException(e);
      }
      finally
      {
         log.debug("ended request");
      }
   }

in the web.xml we declare the filter and servlets which will use it. We map this filter to the servlets which make periodic background calls to the server

    
        No Conversation Timeout Filter
        ContextFilterWithoutTimeout
    
    
        No Conversation Timeout Filter
        LongOperationsServlet
    
    
        No Conversation Timeout Filter
        PollServlet

As I said before – it doesn’t completely change the Seam request processing, it just let us to avoid conversation timeout for our primary page. In case user will open two pages and leave them for certain time (larger than configured conversation timeout) – only the first page he will interact with will continue conversation, because on the first interaction the other conversation 9form other page) will be timed out. But that is expected behavior of Seam conversations and we are not going to change it. What we solve here – is that our primary conversation will not be destroyed because of our background (secondary) calls and that those secondary calls will have an access to all Seam components.

Conditional re-rendering in JSF (Richfaces)

Andrey Chorniy — Thu, 23 Feb 2012 21:31:21 +0000

It happens that you want something to be re-rendered only if ajax-request is executed without errors. Or in other words – you want to be lazy if it possible and not perform “reRender” if you could. Just like that funny guy – he have to be lazy to be strong
For example you have a dialog which call some ajax-action and you want to re-render it only if ajaxrequest is executed without errors
if yo’ll put a plain it will always reRender the “list” – even if ajax request has errors.

the workaround could be moving the reRendering to a separate a4j:jsFunction call and call it only when you want it

pretty easy and your “list” will be reRendered only after success call to the “#{actionBean.action}”

XHTML code to inject the error-severity in the input field “requestSeverity”

Javascript function to check presence of errors (error-messages-severity)

function hasAjaxErrors() {
    var errorSeverityElement = document.getElementById("requestSeverity");
    if (errorSeverityElement){
        return errorSeverityElement.value >= 2;
    }
    return false;
}

Useful Eclipse navigation shortcuts for java developer

Andrey Chorniy — Tue, 14 Jun 2011 15:49:59 +0000

I find that this article (10 Eclipse Navigation Shortcuts…) is great and will save you a lot of time in development/coding if you are programming in Eclipse. I personally prefer Intellij Idea for java development, but in case of Android “Eclipse + ADT plugin” doesn’t leave much chances to alternative IDE’s.
Great shortcuts, I use part of them before and really miss “CTRL-E” Go to other open editors

and “CTRL-O” Go directly to a member (method, variable)

Richfaces a4j:poll and a4j:push Can Do More Together

Andrey Chorniy — Sun, 27 Feb 2011 17:01:36 +0000

Task: Update the content of the page if the content is changed on server-side, in other words – show the most-fleshiest content to the user.

The most simple solution that comes to mind is to use component which will periodically call some action which will load fresh content and re-render the content on the page. But that not very optimal since you will create the content on server-side and send it back to the client each time you execute the polling request.

a4j:push component looks like the one who was created to avoid that every-time re-rendering. Here is what demo-site says about it:

The main difference between a4j:push and a4j:poll components is that a4j:push makes request to minimal code only (not to JSF tree) in order to check the presence of messages in the queue. If the message exists the complete request will be performed. The component doesn’t poll registered beans but registers EventListener which receives messages about events.

Looks very promising, but in reality it’s a kind of tricky to integrate it with your real application because some code on the server side should execute something like that:

synchronized (listener) {
listener.onEvent(new EventObject(this));
}

But, to do so we should have something in background which will periodically check for updates and generate the events and send them to our listener. Starting a Thread is not good option since we have to worry about the way to stop it, as well who start Thread’s in web-apps ? @Asynchronous task is better one option, but still has the same issues – we have to worry about it lifecycle and stop updates at some point (user may leave the page or close his browser) so we actually has no good way to manage the lifecycle of launched background tasks.
At first I try to use a4j:push with action=”#{myActionBean.checkForUpdates}” but action is not called by a4j:push, it just checks if he has new events and only if it has such – execute action and do reRendering (all that JSF lifecycle)

But it looks like combination of a4j:poll and a4j:push could work here in that way.

a4j:poll execute an action which check for updates in the data and fire an Event if they are exists
a4j:push periodically check for new events and re-render content on new event

So, a4:poll play role of assistant, actually it’s like the managed background task on the serverside which periodically poll for the data, but it’s live on the client-side, so in case user will close his browser – server will not execute the requests to datsource anymore.

I call it a “conditional re-rendering”. Here is the JSF code I use to make it working.

The only issue here is that we have to ensure that a4j:push is executed AFTER a4j:poll so action called in a4j:poll will generate the event before we will execute the a4j:push. Unfortunately we don’t have the way to manage it in JSF with attributes, but that could be done with help of postponed launching of a4j:push (with some reasonable gap which should be bigger than time required to execute check for data-updates)
The postponed a4j:push execution is achieved with enabling it with ‘enabled=”#{myActionBean.pushUpdatesStarted}”‘ attribute and calling the javascript with timeout

jQuery(document).ready(function() {
    window.setTimeout(startPushUpdates, 5000);
});

so, having all that JSF code and MyActionBean.java we have quite optimal solution
I didn’t include java-code here but I believe if you read this line than you most probably got the idea and capable to implement it on your own

Future notes: it looks that IceFaces propose their own vision of ajax-push and it’s not based on periodical polling of server from server-side.

As well they have Direct-To-Dom rendering which looks like much more optimal way of re-Rendering. Haven’t tried it yet, but for me it looks ajax-push at IceFaces and re-rendering is a more optimal solution.
It would be nice to hear from the ones who try both RichFaces and IceFaces ajax push approaches.
BTW, just find that RichFaces team prepare some updates to a4j:push in RF-4.0

With this release we have added a few new components, redesigned a4j:push to use advanced Comet implementation and JMS servers

Export to Excel with jXLS can be faster

Andrey Chorniy — Mon, 14 Feb 2011 19:05:18 +0000

I got a question about the jXLS performance, in short it was like “jXLS is a kind of slow for my big reports”.
I mentioned that in my previous post (Creating Excel reports from java is easy)

It’s true, especially about latest jXLS, after I updated my jxls-0.9.8 to 1.0-RC1 (see downloads) I noticed that report generation become MUCH SLOWER. I believe the difference is in the expression library version JEXL. In the 1.0-RC1 they start using JEXL-2.0.1 version and before they use JEXL-1.1
Anyway, it looks downgrading it back to the jXLS 0.9.8 solves my problems, the performance is not blazing fast but much better than in jXLS 1.0. I bet jXLS 0.9.9 work faster than 1.0

Howto disable form submit on Enter and fix for RichFaces rich:inputNumberSpinner

Andrey Chorniy — Sat, 06 Nov 2010 00:37:10 +0000

It’s quite generic problem – to disable automatic form submit on ENTER, to avoid occasional submits which could lead either to page refresh or even to redirecting to another page.
The general idea is to define onkeypressed event handler for text input fields
Here is the article which describe the general approach to do it in HTML.

we can assign onkeypressed event handler to all fields just with few lines (with help of JQuery of course)

function noEnter() {
    return !(window.event && window.event.keyCode == ENTER_KEY_CODE);
}

jQuery(document).ready(function(){
      jQuery(:input:text).keypress(function(){
           return noEnter();
      });
});

That works fine for a lot of components, but not for rich:inputNumberSpinner. ”onkeypressed” handler was assigned and was called, but … it still not work, after a plenty time in debug I finally ensured that it not working and start investigating the richfaces sources for that component and found that it has a javascript command that DIRECTLY perform the form submit. And there is no way to prevent this behavior using tags or javascript handlers.
BTW – I really like new google-chrome developer tools, pretty good and *faster* alternative to FireBug in FF)

After some googling I found that there is an RF issue exists (not resolved yet) and there is no way to prevent form submission according to the richfaces-issue and actually in the related-post this issue is described in details, but it looks that solution could be only fixing the RichFaces library itself.
So, let’s do it! We will need to build it form sources, since direct update of the script in the jar-file is not working – richfaces have minified scripts and they are pretty hard to read/modify

You can download patched richfaces-ui.jar from here.

Download RichFaces sources (I prefer to use stable builds)
Extract them and navigate to the file in which form-submission is done “ui/inputnumber-spinner/src/main/resources/org/richfaces/renderkit/html/script/SpinnerScript.js”

comment out that crazy row

        if (e.keyCode == 13){
            if (this.spinner.required || "" != this.edit.value)
                this.edit.value = this.getValidValue(this.edit.value);
            if (this.edit.form) {
//                this.edit.form.submit();
            }
        }
}

Lets build the Richfaces from sources. The first problem you can met is the memory. We will need a bunch of memory, so ensure that you have 64-bit java (since you will need a lot of memory – about 1500MB – I was not able to allocate this amount on 32-bit java in Windows-XP)
so, instead of redefining env variables I just copied mvn.bat to mvn64.bat and added the following lines
```
set JAVA_HOME=E:/Java/jdk/jdk.1.6_64
set MAVEN_OPTS=-Xms512m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m
```

no lets rebuild richfaces-ui to do it, let’s grab few command-lines from developmentBuild.sh

cd %PROJECT_DIR%/ui
mvn64  clean install -Dmaven.test.skip=true
cd %PROJECT_DIR%/ui/assembly
mvn64  clean install -Dmaven.test.skip=true

Let’s take a cup of tea since it will take a while…
After build is done you will find the updated richfaces-ui.jar in the local maven repository.
${repository-home}/org/richfaces/ui/richfaces-ui/3.3.3.Final/richfaces-ui-3.3.3.Final.jar

HierarchyViewer missed in Android SDK r07 for Windows

Andrey Chorniy — Fri, 29 Oct 2010 21:02:53 +0000

I just updated to Android SDK-r07 and find out that I don’t have hierarchy-viewer tool anymore, what a nice surprise
I know this program is stored in hierarchyviewer.jar so just created the hv.bat in tools directory with just

java -Xmx512m  -jar ./lib/hierarchyviewer.jar

.. and it works for me.

Another way – is to download Android-SDK-r06 and take hierarchyviewer.bat from it. Still don’t know how it happens that Android-SDK-r07 miss that great tool launcher

For those who don’t know nothing about that great tool, I recommend to take a look at article about layout-efficiency in android and about layout-optimization – and start using and in your layouts. And of course spend some time exploring your view-s in HierarchyViewer.

Show dynamic progress of time-consuming process in Seam/RichFaces

Andrey Chorniy — Fri, 22 Oct 2010 10:06:08 +0000

Sometimes you need to start really time-consuming task on the server, but doing that with simple h:commandAction which will re-render page after it is done is not a good idea. Showing a4j:status (which could be blocking – see “avoid concurrent call to conversation“) – is a bit better and will work for relatively short tasks (like 5 – 15 seconds, matter of taste actually) but still not good solution for really long tasks (something more than 1 minute)

For really long tasks I recommend to show the progress indicator (it’s also known usability fact that user will think that task with dynamic progress-bar is faster than the same task but without progress-bar)

There is a quite good component to do it with Richfaces – it’s progressBar component, the only problem to do it with Seam is that you should initiate progress (by calling the action) and that action should immediately return and start some background process. It’s always bad practice to use Thread’s in the web-containers, in Seam we have alternative Asynchronous tasks, but.. the problem with them is that they actually will be running in completely separate scope (they don’t know nothing about your conversation scope)

The trick here is to pass all the required parameters to asynchronous method and use them for returning the results too (in the conversation). That way we are not crazy about memory issues, since as long the long computation process will be ended the memory will be released (the reference to the object will be only in the initiator – the conversation scoped bean)

So, the solution may look like that.

Define the PrgressBean.java which will hold all required initialization parameters for the process and methods to access the progress-state
add “progressBean” attribute (+getter) in your action-class (ConversationBean.java)
define methods to start process which will make a call to asynchronous method in other “LongProcess.java” and pass the progress bean to it
add rich:progressBar and start/stop buttons in “commandPanel” (could be done inside progressBar only), + “updatedResults” – here you can show intermediate and final results during the process (optional)

In short – it is all you need to show very informative long-running process progress.

Future Notes:

Richfaces has few other ways to build your own progressBean – it is a4j:poll and a4j:push components. rich:progressBean actually utilize “pooling” approach, in most cases it’s quite enough to periodically update progress/results for the user, so actually there is no much sense to write your own approach using a4j:poll. a4j:push maybe quite good alternative to rich:progressBar since it use much less traffic and doesn’t update JSF tree (so it’s potentially a better alternative). I think you can easily adapt described approach to use a4j:push – you just need to add few pieces (addListener method and send events to the listener during the process)

Code-Snippets

Java Code:

@Name("longProcess")
@AutoCreate
public class LongProcess {
    private ProgressBean progress
    @Asynchronous
    public void startProcess(ProgressBean progress) {
        this.progress = progress;
        this.progress.setInProgress(true);
        try {
            runProcess();
        } finally {
            this.progress.setInProgress(false);
        }
    }

   private void runProcess(){
     //perform your time-consuming operations here and periodically update the progress status
....
     progress.setPprogress(progressValue);
....
     if (progress.shouldStop()){
        //finish long process and return
     }
....
   }
}

@Name("conversationBean")
@Scope(ScopeType.CONVERSATION)
public class ConversationBean  {
    private ProgressBean progressBean = new ProgressBean();
    @In LongProcess longProcess;

    public void startProcess(){
        if (!progressBean.isInProgress()) {
           progressBean = createNewProgressBean(); //initialize it with required parameters here
           longProcess.startProcess(progressBean);
        }
    }
    public ProgressBean getProgressBean(){
        return progressBean;
    }
    public void stopProcess(){
       progressBean.stop(); //update the internal state of progress-bean so long-process will check it and stop
    }
}

Richfaces/JSF code










    
        
       
    
    
        
      
    



      
     

it use a method conversationBean.updateRate to determine the update rate. I’s optional and could be just hardcoded to some value like “1000″ (1 second). Can be used to dynamically set it to appropriate value, so your progress bar will not be updated to often and can be even changed during a process to fit to your real update rate
reRender="#{conversationBean.shouldUpdateTable ? 'updatedResults':'anyEmptyComponent'}" 

As you see reRender here use dynamic condition, so conversationBean has a control other it and can skip heavy “updatedResults” update to save a traffic