Similar complaint here:

http://stackoverflow.com/questions/2797231/why-does-postconstruct-callback-fire-every-time-even-though-bean-is-viewscoped

In auction, logging shows that the @PostConstruct on the @ViewScoped AuctionBean is invoked every time the page is interacted with. The recommendation is to call addCurrentSession() from a @SessionScoped bean.

The motivation behind this is as follows:

PushRenderer.addCurrentSession() needs to ensure that all current PUSHIDs for the session are included in the push group for the session. If ICEfaces does not receive a dispose-window message, however, it may maintain unused entries in this list.

It should be possible for addCurrentSession() to simply flag the session as being push enabled with the list of groups that the session was added to. Then, when a new view is initialized, the PUSHID for that view would be added to each of these groups. Cleanup of these PUSHIDs would be automatic. Any windows opened prior to addCurrentSession() would not support push anyway, since they would not have called the JavaScript push initialization.

Verify PUSH_IDs do not accumulate as a result of user interaction with auction.

The pushID accumulation was most probably solved by the fixes for PUSH-137.

With the current Mojarra version (2.1.1-FCS) the @PostCostruct annotated methods are properly invoked when a new view is created. This usually occurs when the a page is loaded.
When forward navigating the @PostConstruct annotated methods are invoked as well as they should be, additionally the @PreDestroy annotated methods are invoked right away.

Also confirmed that the pushID don't accumulate, it seems that PUSH-137 indeed resolved this issue.