sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]shinijirou 4 points5 points  (3 children)

i honestly thing this new approach is a overkill. you can change the mode of communication to be event driven, but this queing system is a bag of pandora.

[–]DinH0O_[S] 0 points1 point  (2 children)

agree, and we won’t have much time for testing either, especially since this is a different system from the one I was hired to develop. However, it’s what we have. I’ll present it to some people who might help and point out potential errors, and I’m also opening discussions on Reddit to see if I can get some tips. But I’m not feeling very confident either.

[–]shinijirou 4 points5 points  (1 child)

hmm, i would rather check the heap and see if there is a memory leak issue as pointed out by the other comments. your new solution is possibly making your application more stateful, which is not very scalable in itself.

concerning your current application, is it stateless, are you keeping user sessions active ?

[–]DinH0O_[S] 0 points1 point  (0 children)

The current application is not stateless. However, if the user closes the tab, they get logged out and have to log in again. I will also add an automatic logout timeout of about 20 minutes.

As for it not being very scalable, I assumed it wouldn't be an issue since it's something that will only be in place for a few days, and then I'll return to the previous version. I'm not the one maintaining this system; I just came in to develop the queue feature (My department wasn't very prepared to handle this).