CrossEvents v0.2-beta

Plugins Plugin Releases
21

I would assume it simply would be benchmarks above + connectivity time. This means creating a universal network (NA<->EU<->AUS etc) would like anything be more difficult than just have multiple separate ones (NA servers chat together, EU servers chat, AUS servers chat.

22

I did some ping tests between 2 boxes of a friend:
(pinged from s2.thefantasycraft.com)

That wouldnā€™t give a problem if the event doesnā€™t has to return to the sending server. But if the event is Returnable it would have 9ms to finish before the sending server drops the result. Do you think I should make this configurable? After all this issue is more on network level, than on programing/plugin level.

23

So for returnables you wait on them to return? It might be a good idea to offer async dispatching of those and then allowing the return value to be retrieved via a Furture or some kind of callback mechanism. That could improve throughput immensely.

EDIT: Also, waiting one ms between each loop isnā€™t helpful. Itā€™ll slow stuff down. If you want to loop, then busy loop. Also, returning event packets could be handled better if you didnā€™t add them to a map and then retrieved them from there. Itā€™s better to have a thread dedicated to handling returning events and having that retrieve from a BlockingQueue or something similar. And if youā€™re feeling adventurous you could try using the disruptor pattern by LMAX.

Note that IO is your producer there.

2 Likes
24

Good idea :smiley:. I add it on the list.
I was just adding something to fix the serialization issue.

1 Like
25

Thats something news for me :smile:. Learning every day.

So If I understand this correctly. I can make my event waiting thread do this
return Queue.take(); //will wait until my object is here

and my receiving thread something like this
queueMap.get(packet.getEventId()).put(packet.getEvent());

26

What you do is you start one or more threads that do something like

while(true) {
    Returnable r = messageQueue.take();
    // Do something with your message. You could update and unblock futures here.
}

For the handling code you could do something like

void handle(Returnable r) {
    callbacks.get(r.getUUID()).call(r);
}

And then you do this every time you get a packet:

void onMessage(Returnable yourMessage) {
    messageQueue.put(yourMessage);
}

The real task here is to have just as many consumer threads (that take stuff from the queue) so the Queue is never completely full (if itā€™s bounded, which is typically faster than other solutions), but the threads can only just keep up and you donā€™t have threads that never get to handle a message because others always take them.

(Thatā€™s for the async. What you were doing is right for synchronized calls)

2 Likes
27

Trying out your CrossChat example and I run into this: http://prntscr.com/7f3yjd

28

The API has changed a bit. Texts.parseJson becomes Texts.json().from and Texts.toJson becomes Texts.json().to.

2 Likes
29

I updated my CrossChat example with the new Formatting API I added in it. Now you can use Text in events without having to worry that they break on sending.

30

Updated the API and implementation with Async calls :smile:. Thanks @TBotV63.

2 Likes
31

Interesting idea. So basically it allows servers to ā€œtalkā€ to each other?

32

Exactly :smile:. Its almost the same thing as netevents for bukkit. Only it contains a bit more stuff lol.

  • Support for returnable events.
  • JSON Serialization with the ability to add Formatters.
  • Server Status Events
  • Async returning

I tried this some time ago. Only it ended up in a class explosion:

1 Like
33

Mind explaining the configuration somewhere? Itā€™s straight forward for the most part, but I had to look at the github wiki to find out that a non-server = a client and clients connect to the one marked as a server. Although Iā€™m unsure how the passwords are used and whether or not all clients should have unique ones or use the serverā€™s password.

34

Yeah I will have to clear that up. I am still trying to make the wiki worth reading :slight_smile: .
But basicly you have to make sure that:

  • Every server uses the same password to connect to the Central server
  • You have 1 server set as IsServer=true.
  • You donā€™t really have to change the UUID of the server. They get regenerated when a duplicated id is found.
1 Like
35

Hey, not sure why but with my server instance of CrossEvents it wonā€™t properly get setup. I receive the following:
[Server thread/ERROR] [CrossEvents/CrossEvents]: CrossEventsServer failed to start on localhost:25565
I snooped through the CrossEvents code and found the IOException catch block in the onEnable which outputs to the console (as shown above) logger.error("CrossEventsServer failed to start on " + config.getHostName() + ":" + config.getPort()); if it fails to start. Although Iā€™m not sure why. Itā€™s simply a localhost:25565 and I havenā€™t even setup the clients for CrossEvents. Thoughts?

36

Yeah 25565 is prob been used already :smile:. It needs to get a new port.

37

Nice! All working now :slight_smile: Canā€™t wait to mess around with this, actually so useful.

1 Like
38

No. The error message for a port in use is very specific. Usually something like: failed to bind to port 25565. Is another server running?

39

The error here is kinda more generic. Its listing to an IOException. Maybe I could add the message of the exception in it.

2 Likes
40

Jenkins link does not work