Exception on server bootup after updating full project (including database) #160
Comments
|
I still have this error when restarting pathmind on my local |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This is still an issue. |
FollowSteph
assigned FollowSteph and onuridrisoglu and unassigned FollowSteph, slinlee, kepricon and onuridrisoglu
|
@FollowSteph @slinlee I made some investigation on this error, here are my findings:
I wanted to give an update and also get your feedback on this. In my opinion, it's safe to continue ignoring this error - now that we know the details. Disabling BTW, when I enable detailed logging, this is the serialization error: |
|
@brunovianarezende can we also disable it in |
|
Yes, session persistent can be disabled. In this case, you will need to login again every time you make some code changes. I disabled it in |
|
@FollowSteph now that we know more about this error message, how do you think we should proceed? I think, the alternatives are,
|
|
@onuridrisoglu Personally I'm of the opinion that we should disable session persistence as it will only require a re-login when there is a code change. That's actually a good thing in my opinion in case something stored in the session causes a conflict with whatever has changed in the code. In other words whenever we deploy new code changes I'm ok with losing the session persistence and requiring a re-login, in fact I think it's a good thing. That being said I think this is a decision for @slinlee so can you please confirm which you of the 3 options you want to move forward with. I'm recommending option 2 for the above reasons but there may be other factors to consider beyond just technical reasons. |
|
@onuridrisoglu @FollowSteph @fionnachan @kepricon @brunovianarezende @gruff4l0 @henrikerola I'd like your opinions:This relates to developer experience. I tend to agree that if we regularly have error messages, we start to ignore them, esp n+1 error messages. But at the same time, would it be annoying to you to have to log in each time after code changes in your current workflows? I personally use a very brute force workflow where I restart my server, so I'm not a good representation. I"m just testing your PR and not doing actual dev. And regarding the third option, should we switch to using jrebel as a team? I think the Vaadin folks have experience using it, is it something you'd recommend? |
|
Personally I recommend just re-login in every time. I too restart my server often. It's very quick and clean and guarantees the same results. And most web browsers these days will save your username and password so you just need to click on the Login button and not actually type in anything. Our app is not overly complex so re-navigating to any one screen is pretty quick. I know some people really like JRebel but I'm personally not a big fan. I've tried it before more than once and I've found it both hard to configure/setup (outside of a very simple project and some luck) and that it has weird random issues that can eat up more time then it saves you. As in losing more time chasing a bug that was due to JRebel that eventually cost more than all the time it saved on the server reboots. My understanding is that it's more valuable when the server startup times are long, which isn't the case for us. My server startup times are within seconds, even with logging in. It could just be my experience but as a result I've not been a big fan of it. That being said I haven't looked at it for at least 2-3 years so a lot could've changed since then. The reviews seem to be that you either love or hate it, there's very little in the middle from what I could tell the last time I looked into them. Again the slower the startup times of your application the bigger the benefit which seems to be correlated with more positive reviews. But again my experience with it is very limited to the odd trials every 1-3 years as I give it another try. |
|
Agree with Steph. With the browser autofill function, it's just one click every time. It doesn't take much time for now. I think if it is taking up a long time in the future, we can consider options like JRebel or other tools. But now it's not a problem. |
|
I like JRebel a lot but agree that it has some issues. Vaadin is also working on improving the developer experience with all these tools (JRebel, spring dev tools and also we are looking into using a special JDK + agent combination which applies code changes without restarts). But I don't think those will land to 14.x series. Personally I would like to see a way to disable spring-dev-tools. I just comment it out right now in order to use JRebel. Also, one option to improve login experience while developing would be to have properties to set username and password and those would be populated to username and password fields (even we could do autologin if wanted). |
|
I just realized this ticket hasn't been updated in about a month therefore I'm following up. Basically my main concern is that over time we'll get complacent to exceptions on startup and may not notice additional ones due to being so use to this one. That being said I'm ok with losing session persistence but it's obviously your decision @slinlee. At this point since no one has really commented either way I think that should be ok. I would however recommend pushing using JRebel to another ticket if we want to pursue it further just so we can close this ticket. Again I'll leave that up to you @slinlee. I'm mainly focused on closing tech debt tickets tonight. |
|
@FollowSteph okay, yeah, I had do re-read all of this to remember what we were talking about, but I think it makes sense to disable session persistence. I'll assign this ticket to you to implement. @FollowSteph |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
ping. |
|
@brunovianarezende Do you remember how session persistence is setup? I believe it was either you or Onur that had set it up so it might be quicker and easier for you to do adjust it. If you don't I can look into it, but if you do please let me know. |
|
@FollowSteph : no, I don't remember. Actually, I haven't touched this part of the application, if I remember correctly. I think it would be better if you could look at it. |
|
Ok. No worries. It's not the highest priority anyways. Thanks for confirming. |
|
For some reason, I have missed that one for a long period of time. I have two questions:
|
|
To answer your questions:
I do not believe so. @slinlee can you please confirm.
I personally don't rely on them. I've had reliability issues in the past. And if I'm creating a new page or something along those lines I just temporarily add some bootstrapping code to speed up the process. But even then I find I rarely need to do this because it's often not worth it since the server startup time is fast enough.
I prefer this option as well, my thinking is that it should happen very rarely for users whereas it will happen all the time for developers. However since it's a pretty subjective usability decision I would defer to @slinlee for the final call on this one. |
|
Yes, the decision was made to disable session persistence. Here is the code you can try it out to see if it gets rid of the error @FollowSteph @alexamakarov |
|
Thank you for confirming @slinlee Now it's just a matter of making the adjustment. On a side note I've marked it as low priority (I'm assuming that's ok @slinlee) since we've been living with it for months. The reason we want to fix it is to avoid us getting so use to seeing an exception on server startup that we miss a real exception. But since none of us remember the details I think we can push it back until we do another big cycle of tech debt. Again that is unless someone remembers. The key based on Onur's earlier comment is that we have to figure out how to disable it in spring-dev-tools since it's set by default. That or remove spring-dev-tools which is probably a bigger decision that I would postpone for now. In my view it's either going to be very simple or someone has to dig through documentation to find where where the setting is located. |
|
The comment from Onur included the fix, so I just rebased it and created the new PR #2125 |
Just did a full update, including database, etc., and on first boot up of the server I got this in the server logs.
The text was updated successfully, but these errors were encountered: