I successfully enabled redis in a spring boot + vaadin application and it runs fine on my computer. The application is on a test run in a slower environment and an error occours multiple times.
WARN c.v.s.communication.ServerRpcHandler [ServerRpcHandler.java : 266] - Unexpected message id from the client. Expected: 248, got: 249
It seems like it happens when the serialization/deserialization of the VaadinSession takes too long. For example I have a page that has multiple checkboxes. I click on the first, then the second and third. After this the upper warn is thrown and a previous state of the page appears. In this case it might be without any cheched checkboxes or with one or two checked checkboxes. In rare cases it works properly.
I can't think of a solution for the problem. One thing I tried is showing a loading indicator immediately (100ms) (the default is after 300ms of loading) but it doesn't solve the problem.
Can I somehow configure when the serialization/deserialization occurs instead of every UI change or make it faster by leaving parts of the VaadinSession out of it? (I need the data on the current page so I can't make the ui components transient.)
We had a discussion about the problem in my workplace and we think that the components are working properly. The problem occurs when a serialization is slower then the next request's deserialization. (Every UI change begins with a deserialization to get the latest state then serializes the modified state.) My solution was creating an aspect that stores the latest VaadinSession that was sent for serialization and compares every deserialized VaadinSession to the stored one. I keep the one with the higher lastProcessedClientToServerId. This solves the issue almost every time.
Related
This question is to do with FatWire Content Server version 7.6.
I have a FatWire template which goes through some assets and returns some markup. It takes about 2 minutes to complete. The result gets cached successfully in FatWire ContentServer cache and I can see it in the CacheManager tool. The ExpiryTime on the template is 10 years in the future. After a short while (usually 1-2 mins), the ExpiryTime changes to a past date (1980-02-01 01:01:01) and hence is expired. The item then disappears from the cache.
Has anyone experienced this before? It is only happening with this template. Any ideas as to the reason the item expires after first being cached successfully?
If you are using old-style page cache implementation (SystemPageCache, SystemItemCache table), then there may I'd suggest to enable some debug, to see if a particular page/element or event is running after this, to cause the change to the table:
enable these loggers (restart afterwards):
com.futuretense.cs.db=DEBUG
com.futuretense.cs.request=DEBUG
com.futuretense.cs.event=DEBUG
com.futuretense.cs=DEBUG
Tail futuretense.txt/sites.log, and reproduce the issue - You should be able to see the point where the new page let is cached with future expiration, and then something subsequent changes it. That may tell you whether it occurred as a result of a system event, or another page request. In case this is occurring on a clustered environment, you would need to set the same logging & tail on the other cluster nodes to spot whether the change is occurring from those.
If you are using new-style page cache ("InCache", cs-cache.xml etc), then it may be that another node is unexpectedly interacting with this node. You could temporarily isolate this node from a cache cluster, by adjusting the multicast settings in cs-cache.xml - e.g. timeToLive=0 will prevent any other nodes on different physical servers from seeing this one.
I have a Selenium test which has been working as expected for the past 1 month.
Since last week this one test alone fails 8 times out of 10, when the form is saved, throwing a Hibernate "Transient Object Exception". So it doesn't fail 100% but just around 80-90% of the time. But it fails just at that one point when Save button is clicked.
The developers tell me that they have changed nothing at all in the test server in the last one week.
I tried the same form manually about 10 times and it saves perfectly all 10 times.
Could there be something wrong with my Selenium test ?
Any thoughts would be helpful.
The exception means that the object that is fed to hibernate (I'm guessing a Java representation of the form) is not attached to the hibernate scope at the time of saving/updating.
Given that it works manually and not with Selenium, I'm guessing a race condition.
Something like an update/delete being performed while the matching object is not (yet) attached to the hibernate session.
Selenium is quite a bit faster at clicking then a human ;-)
My best bet would have the programmers look at any (async) calls to the database via hibernate and execution order of those calls and see if there are any race conditions possible (or in this case; where).
Have you tried adding a wait command? It may be something as simple as trying to select the element a little to early.
I have a large richfaces tree and each element in the tree can be selected which loads the content via AJAX and edited which redirects you to a new page. This was working great until I had a particularly large document I was working on and saving no longer worked. You got redirected to the edit page which showed the right content, but trying to "save" any edits resulted in a ViewExpiredException.
I tried tweaking a lot of parameters and eventually arrived at two parameters that fixed it:
com.sun.faces.numberOfViewsInSession
com.sun.faces.numberOfLogicalViews
As far as I can see, the default for each is 15, I set them to a ridiculous 500 and the application works again. Unfortunately because I don't know where the problem is situated and it's a large application I can't show you any relevant code.
But the questions are: what exactly do these parameters do, what could cause me to bump into these exceptions and what are acceptable values?
UPDATE
I'm not entirely sure why the question got downvoted but if it is with regards to the supposed duplicate: I had found that post through google but the link it provides is dead. Except for the bog standard (and vague) definition of the parameters, there does not seem to be much information on them.
When server side state saving is used (which is default) than those two parameters can be used to configure maximum number of logical and actual views.
Logical view is top level view which is created on every GET request (for example when you open page in new browser window or tab, entering address in address bar of browser, iframes...). Each logical view can have some number of associated actual views. Actual views are created as user navigate through your pages with standard JSF mechanisms (for example if you navigate to page returned from action methods in commandButton). Both queues of views use LRU algorithm to decide when view will be removed, and maximum number of those queues are limited by values of these two parameters.
So, com.sun.faces.numberOfViewsInSession defines the maximum number of JSF views stored in the session for per logical view, and com.sun.faces.numberOfLogicalViews defines the maximum number of logical views to store per session.
According to information you provided a suspect that configuration of com.sun.faces.numberOfViewsInSession solved your problem, but you must further investigate why is created so many views.
Additional link:
What are the differences between Server and Client side state saving and what are the benefits/drawbacks of each?
I have a small Vaadin v8 application that has several input fields (comboboxes, selectgroups, etc...). The content of most of these is determined by the chosen content of the first ComboBox. However, when I select something in it, all the others stay blank until I click one, at which point they all update. This is not desired behaviour, but I assume it's being caused by the server-side being up to date but not updating the client side view. (Even when adding requestRepaint() in my first Combobox's ValueChangeListener)
There must be some method to force Vaadin to get the data I want it to display even if no other components are clicked?
EDIT
I'm not allowed to post answers to my own question so soon, so I'm putting it here temporarily:
I found that there's a javascript method that synchs client and server.
myComponent.getApplication().getMainWindow().executeJavaScript("javascript:vaadin.forceSync();");
The only problem I have now is that the ValueChangeListener on one of my comboboxes still only fires when I click another combobox (or the same one twice). It's the weirdest thing because the second combobox, when loaded, fires it's event perfectly.
Is the first ComboBox in "immediate" mode?
If not, it probably should be : component.setImmediate(true).
See https://vaadin.com/book/-/page/components.selection.html
I had the same problem, see below how it could be done in version 8.0.5 (from 2017):
#Push
public class WebUi extends UI {
public void fireComponentUpdated() {
getUI().push();
}
}
There is a hack you can use if you have set a datasource for your componets that forces vaadin to re-render them. I use this for updating tables that have dynamic data
yourcomponent.setContainerDataSource(yourcomponent.getContainerDataSource());
Did you requestRepaint on the correct components?
Keep in mind that requestRepaint marks the component as dirty but doesn't mean it will be repainted - a client can only be refreshed when it makes a request to the server.
See this thread https://vaadin.com/forum/-/message_boards/view_message/231271 for more information about your options (it deals with UI refreshes due to background thread processing).
In Vaadin 7 it is enough to put this line in main UI.init(VaadinRequest) method:
UI.getCurrent().setPollInterval( 1000 );
if you want to refresh your UI (in this case) every second. This way you instruct UI to poll server for changes in defined interval.
Beware, excessive server traffic might be a problem if you have lot of users that use your application at the same time.
In Vaadin 6 you will have to play with ProgressIndicator (which could be invisible if you want) and try to do the similar what UI.getCurrent().setPollInterval(int) in Vaadin 7 does.
I've setup a Wicket + Hibernate + Spring Web application that involves gathering some data (having some files generated and returned), storing this in a database, creating some images and displaying all this on a webpage.
This all works fine for short runs, but sometimes gathering the data (which involves some remote number crunching) takes too long (20+ minutes) and times out. I've tried to resolve this using two approaches, but both of them show some problems.
The first approach was using AjaxLazyLoadPanels and just doing everything within the getLazyLoadComponent. This worked fine for the short runs, but for the 20+ minute runs the LazyLoadComponents would not load (nice oxymoron there) due to timeouts.
The second approach involved creating an intermediate Fragment with an added AjaxSelfUpdatingTimerBehavior with a duration set to 10 seconds, that polled for the files that are created in the number crunching. This seems to make the tasks run in the background without problems, but fails when the returned data needs to be stored in the database. I'm using the Open Session in View pattern, but maybe this fails when attempting to store data after 20 minutes?? (Solution could lie in resolving this..).
Due to the above problems I'm now reading up on alternate approaches to handle these long running tasks and came across:
org.apache.wicket.util.time.Task
org.apache.wicket.util.watch.ModificationWatcher
I'm now wondering if either of these might be better suited to solve the time-out problems I'm having in both running the tasks and storing the data in the database afterwards, or if anyone has any other solutions that might help in this situation.
I'd really like to know if a new approach is viable before I spend another day implementing something that might turn out not to work after all.
Best regards,
Tim
I know we have had success in using a Panel with an attached AjaxSelfUpdatingTimerBehavior. The task and the results piece are separated from the view logic, but are made accessible for the view via a service you create. The service implementation we have used is then responsible for starting a TheadPool or ExectutorService for running the individual tasks. The service can provide a way to monitor the progress/status of the particular job/call that is taking place. Once it is complete it should also make the data available for the view. Injection of a SessionFactory into the service implementation (or injected DAO) should be sufficient to create the HibernateSession outside of a WebSession.