search

vahidhedayati / grails-wschat-plugin

Grails websocket chat Plugin provides a multi-chat room add-on to an existing grails based site. provides: Private Messaging/WebRTC/Offline PM + room booking/reservations. Websocket TicTactoe. Add Live Chat to your Grails application
http://grails.org/plugin/wschat
Apache License 2.0
22 stars 10 forks source link

Concurrent Modification Exception #3

Closed grandec closed 9 years ago

grandec commented 9 years ago

Hi, I use this plugin and the "Concurrent Modification Exception" is thrown when i create a Session, disconnect, and create it again. The exception happens in the "sendUserList" method, i think it happens because when it is iterating to send all the user that a user has disconnected, someone enters the room and the map is updated with the new user while it is iterating. Even if the Set is set as synchronized, the iterator is not, so the problem happens.

vahidhedayati commented 9 years ago

I think its safe to say this is will be one of the features since it was rushed out thoughts. Simply due to where the response was i.e. in Service from where it was initiated in taglib. :) I am looking at your code and can see how I could incorporate and that as the websocket method.

The polling is the additional function, as in not essential the interface that collects has to be enabled in your config.groovy, I think with some minor tweak to your code above I should be able to easily have a client rather than poll use websockets to connect with the use of the taglib - the taglib doing just like the video executing the commands and doing back end work if required.

Whilst front end uses your method to simply connect acts as a sniffer and await response from the room if anything matches the example set case statements then to do like you have done something.

So thank you for providing that example it will be of great use.

grandec commented 9 years ago

No problem, you're welcome :D . Thanks for all the explanation.

:smile:

vahidhedayati commented 9 years ago

Victor Thanks for your contribution, I have added most of your code and created a new way of doing client connections, you can now do a tag lib call via gsp pages to send events. I tried to follow your internal convention as much as possible, I think by overriding the ChatClientOverrideService.groovy to get your users for your events and + WsClientProcessService.groovy to set your own backend functionality if required. finally by copying _process.gsp in to your own project and defining front end actions per side if required you will be able to do it all from within plugin.. also sending autodisco="true" from client should create send/disco clients which probably matches your model more.

grandec commented 9 years ago

Wow, having the code implemented in the plugin is awesome. I'm going to try to use the new Services in my application, to increase the integration with the plugin.

Thanks a lot.

vahidhedayati commented 9 years ago

No problems, one thing I have not tried as yet and wonder how plausible is having lets say divId's outside i.e. in the main gsp that calls the tag lib, the overring the _process.gsp by defining it as a template in the call - and setting the script in there to update an element from main calling gsp..

Also those methods you put in with closure calls in the service I have added in as well not used in my own code, if you wanted I could move them to the WsClientProcessService which is likely to get overriden.

The event is slightly different to yours so hope you can still use it ...

The last thing was you had random id's which may have been related to having two users log in ? (unsure) if so then already taken care of if not - you could possibly generate that as part of first part user being logged in -

Having it within the plugin means then in the future if the data structure of auth etc change then so will the client code as well to match it and hence saves you the trouble of having to keep upto date with actual plugin.

Also hoping with the tag lib call it will mean no iframe calls etc..

All the best Vahid

grandec commented 9 years ago

The random id's thing is because if two different users call the server to execute this code for the same time, there will be two "server" user connected with the same name. The random id thing is to avoid it.

The methods with closures call that you are talking about, is it the "quickConnect" and "quickRoomConnect" closures or the JsonString with the "context, data" thing??

vahidhedayati commented 9 years ago

"there will be two "server" user connected with the same name. The random id thing is to avoid it. "

The code then generates servername_frontend

When messages are sent via client it automatically checks for: so client1 sending to server1 sendMessage checks for

server1_frontend -> if so send server1 -> if so send message

That frontend name is hardcoded but you could override its name via config.groovy so by default its called something else.

Yep the quickConnect etc are all within another service: ChatClientListenerService.groovy

Some of the methods was changed in this so unsure if you can still make it work if you want I can move those blocks to : WsClientProcessService.groovy

Since its quite likely you will be overriding this - if you do end up using this method and then you could overide those methods if required.

vahidhedayati commented 9 years ago

sorry forgot to mention watch this: https://www.youtube.com/watch?v=xagMYM9n3l0 if you haven't already

vahidhedayati commented 9 years ago

" wschat does not accept user with the same name, even at different rooms."

This should now work - as in one user should be able to log in multiple times to different rooms (not the same one)

    compile ":wschat:1.13-SNAPSHOT"

problem was with : https://github.com/vahidhedayati/grails-wschat-plugin/blob/master/grails-app/services/grails/plugin/wschat/auth/WsChatAuthService.groovy#L28

grandec commented 9 years ago

Hi, happy new year. :D

With this new version, when I log in to different rooms with the same log in, how the messaging will works? The messages goes to the last room logged?

vahidhedayati commented 9 years ago

BTW I logged to warn that from 1.11 to 1.13 lots of DB changes so it may break - may be worth backing up previous db and you may need to remove the tables and let it recreate--

I tested this using a normal chat then invited myself to a conference which was a different room convention

ChatRoomList.groovy#L7 I have now added roomTypes for Booking-chat-event

Hmmm so here is the run down after a test - very buggy pms going to wrong windows. Users list overwritten . But I think this is due to some of these refreshes going on -

If you want I can work with this tomorrow and see if there is a way of localising PM's more based to user iterator in the room - disable sending out room info on any rooms that are not of roomType chat which would then mean setting up rooms that have other types for this type of work,

On the side note - you can also enable Offline PM's. in short in a scenario server (master) goes offline messages should pop up - upon reconnection

vahidhedayati commented 9 years ago

Okay more thoughts.

If you can work with creating variations of room types.

So user called server joins room called room1 of room type ab

Then server joins rooms room2 of room type xyz

If you can work with that sort of model I could work on a room iterator. Adding room types as they arrive with a user joining. Then set user iteration to be roomtype_username set a new session value for real username then call this for display. Additional session field holding user room type.

Finally a delve into messaging to find roomtype_username

This would allow 1 user to get messages uniquely

If you can work on roomtype variations I can look into rest.

Let me know On 4 Jan 2015 17:28, "Victor Terra Ferrão" notifications@github.com wrote:

Hi, happy new year. :D

With this new version, when I log in to different rooms with the same log in, how the messaging will works? The messages goes to the last room logged?

— Reply to this email directly or view it on GitHub https://github.com/vahidhedayati/grails-wschat-plugin/issues/3#issuecomment-68640905 .

grandec commented 9 years ago

Hi, In the application that I am working, the rooms might have 5000 users connected at the same time in the same room, and every time that a user joins or leaves, the plugin sends to every user the updated list of the current online users. Can you put a variable to disable this? I'm starting to worry that a lot of time and data is going to be wasted sending all the users the userlist every time. Thanks a lot :D see ya.

PS: Isn't it easier to make a RoomList and Inside it a Userlist, so you can iterate in the roomList to find the UserList? so wont have to iterate through everyone.

vahidhedayati commented 9 years ago

Hi hope all is well, :)

I have released 1.13-SNAPSHOT2 with this enable:

wschat.send.userList='no'

Which should stop sending the users list, yes the room iterator is something I had been thinking about the complications of all of this would be now that I have a friends list that also looks up users globally etc.. I have reverted that other change back (allowing user to login twice) since it was not working as it should have been.

I will look into it again soon

grandec commented 9 years ago

Thank you :D

grandec commented 9 years ago

Thank you :D

vahidhedayati commented 9 years ago

cool :) I guess its working

vahidhedayati commented 9 years ago

Hi Victor, hope all is well. Finally moved over the user list to concurrent hash map. Hopefully it will fix those issues from early on this year.

vahidhedayati commented 9 years ago

https://github.com/vahidhedayati/grails-wschat-plugin/issues/7 nudge nudge wink wink got that multiple log in working in the end. Failed that first time a very long time ago and I kind of gave up back then.. Anyways dual log in now works too.

Will close this issue - open a new one if required