Further Development?

[Jerry0022]

Hi,
I just saw that you write about "Eventbus 2.0" in some comments. Was there any further development after 13th Feb 2010?
The last version I got is 1.4

[michaelbushe]

That's it for now. Java 8 makes things more interesting. I'm moving it to
github, my id is michaelbushe, it's really on the back burner still.
Anything in particular that you'd like?

Michael

On Mon, Jul 14, 2014 at 5:15 AM, Jerry0022 notifications@github.com wrote:

Hi,
I just saw that there you write about "Eventbus 2.0" in some comments. Was
there any further development after 13th Feb 2010?
The last version I got is 1.4

—
Reply to this email directly or view it on GitHub
#3.

Michael Bushe
Michael@Bushe.com
Bushe Enterprises, Inc.
508-625-1235

[Jerry0022]

Thanks for the fast answer.

At the moment I'm just thinking of different
eventpipes maybe not objects as Eventpipes but something like a fixed
Parameter, but probably this isn't necessary because of the topic
possibility.
Nevertheless I read in one comparison with mbassador and others (ok, it was
written by the maker of mbassador) that your one is by far the slowest.
Maybe there is a possibility to improve the speed without dropping features.
I will inform you if I really miss something in my current implementation
of EventBus ;)

EDIT: I found sth. Is it possible to implement maybe an synchronous version that after firing an event it waits as long as other methods are working...? I know it is quite similiar to an ActionListener but I think it would be a nice feature if possible.

Best Regards
Jeremy

2014-07-14 15:07 GMT+02:00 michaelbushe notifications@github.com:

That's it for now. Java 8 makes things more interesting. I'm moving it to
github, my id is michaelbushe, it's really on the back burner still.
Anything in particular that you'd like?

Michael

On Mon, Jul 14, 2014 at 5:15 AM, Jerry0022 notifications@github.com
wrote:

Hi,
I just saw that there you write about "Eventbus 2.0" in some comments.
Was
there any further development after 13th Feb 2010?
The last version I got is 1.4

—
Reply to this email directly or view it on GitHub
#3.

Michael Bushe
Michael@Bushe.com
Bushe Enterprises, Inc.
508-625-1235

—
Reply to this email directly or view it on GitHub
#3 (comment).

[michaelbushe]

Yes, there's a trade old, but Is 100,000+ events per second not fast enough for you? :-)

Michael

On Jul 15, 2014, at 12:47 PM, Jerry0022 notifications@github.com wrote:

Thanks for the fast answer. At the moment I'm just thinking of different
eventpipes maybe not objects as Eventpipes but something like a fixed
Parameter, but probably this isn't necessary because of the topic
possibility.
Nevertheless I read in one comparison with mbassador and others (ok, it was
written by the maker of mbassador) that your one is by far the slowest.
Maybe there is a possibility to improve the speed without dropping features.
I will inform you if I really miss something in my current implementation
of EventBus ;)

Viele Grüße
Jeremy

2014-07-14 15:07 GMT+02:00 michaelbushe notifications@github.com:

That's it for now. Java 8 makes things more interesting. I'm moving it to
github, my id is michaelbushe, it's really on the back burner still.
Anything in particular that you'd like?

Michael

On Mon, Jul 14, 2014 at 5:15 AM, Jerry0022 notifications@github.com
wrote:

Hi,
I just saw that there you write about "Eventbus 2.0" in some comments.
Was
there any further development after 13th Feb 2010?
The last version I got is 1.4

—
Reply to this email directly or view it on GitHub
#3.

Michael Bushe
Michael@Bushe.com
Bushe Enterprises, Inc.
508-625-1235

—
Reply to this email directly or view it on GitHub
#3 (comment).

—
Reply to this email directly or view it on GitHub.

[Jerry0022]

xD Yeah, that's why I said if I really miss something, I think currently it is more a benchmark scenario :D

More useful would be the request in the edit to have a synchronous EventBus, just like a threadsave Actionlistener but without the whole code overhead, what do you think about it, is it a big deal?

[michaelbushe]

I'm not sure what you mean. "the request in the edit"?

Which overhead do you want to get rid of? There's a thread cleanup that is only active in certain scenarios and is configurable. If you just use topic you can save microseconds of class-matching over string matching at the cost of type safety and other conveniences.

You can use all the same code synchronously as asynchronously. After all, swing is single-threaded and it works fine there. EventSubsriber is essentially an ActionListener. Do you mean a FIFO bus that blocks until all the subscribers for the last event have been processed? If you can implement an EventService different from the SwingEventService and ThreadSafeEventServuce, you can plug it into your apps today, and contribute it back to the available set for everyone else.

Michael

On Jul 16, 2014, at 3:05 AM, Jerry0022 notifications@github.com wrote:

xD Yeah, that's why I said if I really miss something, I think currently it is more a benchmark scenario :D

More useful would be the request in the edit to have a synchronous EventBus, just like a threadsave Actionlistener but without the whole code overhead, what do you think about it, is it a big deal?

—
Reply to this email directly or view it on GitHub.

[Jerry0022]

Ok, sry for the confusion.
At the moment I use mainly from your library:

Class1:
EventBus.publish(topic, object);
Class2:
AnnotationProcessor.process(this);
@ EventTopicSubscriber(topic = "")

I'm very happy about this easy async thing. But sometimes I need the same just synchronous as you mentioned in your last answer: Do you mean a FIFO bus that blocks until all the subscribers for the last event have been processed? Yes :D "Blocks" in terms of the publisher waits.
I haven't understood your whole work, sry. What is the easiest way to get this work? With your work or a standard Java feature? Maybe you can write example code lines as I did above?

[michaelbushe]

Now that I think about it, if you only have one thread sending events, then
you have a FIFO as described. (BTW, for one event, listeners are always
called in a FIFO order, blocking ).

Describe for me the application. Who is sending and receiving the events?

Michael

On Wed, Jul 16, 2014 at 12:44 PM, Jerry0022 notifications@github.com
wrote:

Ok, sry for the confusion.
At the moment I use mainly from your library:
Class1:
EventBus.publish(topic, object);
Class2:
AnnotationProcessor.process(this);
@ EventTopicSubscriber(topic = "")

I'm very happy about this easy async thing. But sometimes I need the same
just synchronous as you mentioned in your last answer: Do you mean a FIFO
bus that blocks until all the subscribers for the last event have been
processed? Yes :D
I haven't understood your whole work, sry. What is the easiest way to get
this? With your work or a standard Java feature. Maybe you can write
example code lines as I did above?

—
Reply to this email directly or view it on GitHub
#3 (comment).

Michael Bushe
Michael@Bushe.com
Bushe Enterprises, Inc.
508-625-1235

[Jerry0022]

I have two "managers" in one thread, maybe soon some more. Then I have x threads of clients. If a client feels to close itself it shall inform all the registered "managers" and shall wait for their actions before it closes.
Between "managers" and clients is no relationship they don't know of each other. Thread safe it should be in terms of if many clients fire the termination event then the first one's event should go to all registered "managers" then the second client's event to all etc. etc. (as far as I understood from your last answer this is already done by your code, for one event the publishing fifo blocking and for many events they come in an order, too?)

With the above code the client would inform all registered "managers" but would continue doing its things and maybe the "managers" have not finished working on process this termination information. It is essential that the "managers" do first their things and after that the client completes its termination (<- that is what I'm looking for, thread safe & synchronous).

I hope the explanation is good enough :D

[michaelbushe]

Ah, since you have multiple clients on different threads, there's no
guarantee that all the subscribers to client1's publish will finish before
all the subscribers to client 2's.

Two solutions:

1. Perhaps your best solution is to handle this in you managers. It might
   be easy, straightforward and in the right place if a manager blocks until
   it's done it's work and the manager's coordinate, they probably will have
   to any, even if you only had one client.
2. Implement your own EventService, maybe call it FIFOEventService. It
   should be similar to SwingEventService.java, which is a tiny class that
   extends the ThreadSafeEventService and overrides publish to handle Swing's
   threading. Instead, put something like a LInkedBlockingQueue (
   http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/LinkedBlockingQueue.html)
   in front of the publish. Contribute back please if you get it working.

Thanks,

Michael

On Wed, Jul 16, 2014 at 1:28 PM, Jerry0022 notifications@github.com wrote:

I have two "managers" in one thread, maybe soon some more. Then I have x
threads of clients. If a client feels to close itself it shall inform all
the registered "managers" and shall wait for their actions before it closes.
Between "managers" and clients is no relationship they don't know of each
other. Thread safe it should be in terms of if many clients fire the
termination event then the first one's event should go to all registered
"managers" then the second client's event to all etc. etc. (as far as I
understood from your last answer this is already done by your code, for one
event the publishing fifo blocking and for many events they come in an
order, too?)

With the above code the client would inform all registered "managers" but
would continue doing its things and maybe the "managers" have not finished
working on process this termination information. It is essential that the
"managers" do first their things and after that the client completes its
termination (<- that is what I'm looking for, thread safe & synchronous).

I hope the explanation is good enough :D

—
Reply to this email directly or view it on GitHub
#3 (comment).

Michael Bushe
Michael@Bushe.com
Bushe Enterprises, Inc.
508-625-1235

[Jerry0022]

Thanks for your answer. I think I tried solution 1 :)
My Client has this in his method:

// A termination method
String topic = "...";
ProxyTopicSubscriber subscriber;
for(Object object : EventBus.getSubscribers(topic))
{
subscriber = (ProxyTopicSubscriber) object;
if(subscriber.getProxiedSubscriber() instanceof NetworkClientTerminationInterface)
{
NetworkClientTerminationInterface termination = (NetworkClientTerminationInterface) subscriber.getProxiedSubscriber();
termination.onClientConnectionLost(topic, this);
}
}
// Now the client can terminate itself

And my "Manager":

@EventTopicSubscriber(topic = "...")
public boolean onClientConnectionLost(String topic, Object object)
{
synchronized (this)
{
// TODO
System.out.println("ClientsHandler termination");
}
return true;
}

All "Managers" implement the Interface "NetworkClientTerminationInterface" which has only the onClientConnectionLost method (see above).

If more than one client calls the onClient...method the synchronize should prevent problems. On the other hand I don't use the EventBus.publish() method but I go through all subscribers manually therefore every subscriber is handled synchronous. Am I right? What do you think about this implementation?
The only think I liked to do is a synchronized method but in interfaces it is a illegal modifier therefore the synchronized block inside the method...

[michaelbushe]

If you are calling the subscribers yourself, you are using the EventBus wrong.

Michael

On Jul 16, 2014, at 5:34 PM, Jerry0022 notifications@github.com wrote:

Thanks for your answer. I think I tried solution 1 :)
My Client has this in his method:

// A termination method
ProxyTopicSubscriber subscriber;
for(Object object : EventBus.getSubscribers(topic))
{
subscriber = (ProxyTopicSubscriber) object;
if(subscriber.getProxiedSubscriber() instanceof NetworkClientTerminationInterface)
{
NetworkClientTerminationInterface termination = (NetworkClientTerminationInterface) subscriber.getProxiedSubscriber();
termination.onClientConnectionLost(topic, this);
}
}
// Now the client can terminate itself

And my "Manager":

@EventTopicSubscriber(topic = "...")
public boolean onClientConnectionLost(String topic, Object object)
{
synchronized (this)
{
// TODO
System.out.println("ClientsHandler termination");
}
return true;
}

All "Managers" implement the Interface "NetworkClientTerminationInterface" which has only the onClientConnectionLost method (see above).

If more than one client calls the onClient...method the synchronize should prevent problems. On the other hand I don't use the EventBus.publish() method but I go through all subscribers manually therefore every subscriber is handled synchronous. Am I right? What do you think about this implementation?
The only think I liked to do is a synchronized method but in interfaces it is a illegal modifier therefore the synchronized block inside the method...

—
Reply to this email directly or view it on GitHub.

[Jerry0022]

But this means that it is now synchronous as described in my explanation,
or?...Yes, I know I misuse your EventBus...but only to get it synchronous
(for some cases)

Viele Grüße
Jeremy

2014-07-17 0:46 GMT+02:00 michaelbushe notifications@github.com:

If you are calling the subscribers yourself, you are using the EventBus
wrong.

Michael

On Jul 16, 2014, at 5:34 PM, Jerry0022 notifications@github.com
wrote:

Thanks for your answer. I think I tried solution 1 :)
My Client has this in his method:

// A termination method
ProxyTopicSubscriber subscriber;
for(Object object : EventBus.getSubscribers(topic))
{
subscriber = (ProxyTopicSubscriber) object;
if(subscriber.getProxiedSubscriber() instanceof
NetworkClientTerminationInterface)
{
NetworkClientTerminationInterface termination =
(NetworkClientTerminationInterface) subscriber.getProxiedSubscriber();
termination.onClientConnectionLost(topic, this);
}
}
// Now the client can terminate itself

And my "Manager":

@EventTopicSubscriber(topic = "...")
public boolean onClientConnectionLost(String topic, Object object)
{
synchronized (this)
{
// TODO
System.out.println("ClientsHandler termination");
}
return true;
}

All "Managers" implement the Interface
"NetworkClientTerminationInterface" which has only the
onClientConnectionLost method (see above).

If more than one client calls the onClient...method the synchronize
should prevent problems. On the other hand I don't use the
EventBus.publish() method but I go through all subscribers manually
therefore every subscriber is handled synchronous. Am I right? What do you
think about this implementation?
The only think I liked to do is a synchronized method but in interfaces
it is a illegal modifier therefore the synchronized block inside the
method...

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#3 (comment).

[michaelbushe]

I see. Try 2. :-)

I'd like to put something like this in, and other kinda of buses, but it won't be Fall, maybe Winter.

Michael

On Jul 16, 2014, at 6:50 PM, Jerry0022 notifications@github.com wrote:

But this means that it is now synchronous as described in my explanation,
or?...Yes, I know I misuse your EventBus...but only to get it synchronous
(for some cases)

Viele Grüße
Jeremy

2014-07-17 0:46 GMT+02:00 michaelbushe notifications@github.com:

If you are calling the subscribers yourself, you are using the EventBus
wrong.

Michael

On Jul 16, 2014, at 5:34 PM, Jerry0022 notifications@github.com
wrote:

Thanks for your answer. I think I tried solution 1 :)
My Client has this in his method:

// A termination method
ProxyTopicSubscriber subscriber;
for(Object object : EventBus.getSubscribers(topic))
{
subscriber = (ProxyTopicSubscriber) object;
if(subscriber.getProxiedSubscriber() instanceof
NetworkClientTerminationInterface)
{
NetworkClientTerminationInterface termination =
(NetworkClientTerminationInterface) subscriber.getProxiedSubscriber();
termination.onClientConnectionLost(topic, this);
}
}
// Now the client can terminate itself

And my "Manager":

@EventTopicSubscriber(topic = "...")
public boolean onClientConnectionLost(String topic, Object object)
{
synchronized (this)
{
// TODO
System.out.println("ClientsHandler termination");
}
return true;
}

All "Managers" implement the Interface
"NetworkClientTerminationInterface" which has only the
onClientConnectionLost method (see above).

If more than one client calls the onClient...method the synchronize
should prevent problems. On the other hand I don't use the
EventBus.publish() method but I go through all subscribers manually
therefore every subscriber is handled synchronous. Am I right? What do you
think about this implementation?
The only think I liked to do is a synchronized method but in interfaces
it is a illegal modifier therefore the synchronized block inside the
method...

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#3 (comment).

—
Reply to this email directly or view it on GitHub.

[Jerry0022]

ok, super :)

Thanks a lot for your help!

Viele Grüße
Jeremy

2014-07-17 0:58 GMT+02:00 michaelbushe notifications@github.com:

I see. Try 2. :-)

I'd like to put something like this in, and other kinda of buses, but it
won't be Fall, maybe Winter.

Michael

On Jul 16, 2014, at 6:50 PM, Jerry0022 notifications@github.com
wrote:

But this means that it is now synchronous as described in my
explanation,
or?...Yes, I know I misuse your EventBus...but only to get it
synchronous
(for some cases)

Viele Grüße
Jeremy

2014-07-17 0:46 GMT+02:00 michaelbushe notifications@github.com:

If you are calling the subscribers yourself, you are using the
EventBus
wrong.

Michael

On Jul 16, 2014, at 5:34 PM, Jerry0022 notifications@github.com
wrote:

Thanks for your answer. I think I tried solution 1 :)
My Client has this in his method:

// A termination method
ProxyTopicSubscriber subscriber;
for(Object object : EventBus.getSubscribers(topic))
{
subscriber = (ProxyTopicSubscriber) object;
if(subscriber.getProxiedSubscriber() instanceof
NetworkClientTerminationInterface)
{
NetworkClientTerminationInterface termination =
(NetworkClientTerminationInterface) subscriber.getProxiedSubscriber();
termination.onClientConnectionLost(topic, this);
}
}
// Now the client can terminate itself

And my "Manager":

@EventTopicSubscriber(topic = "...")
public boolean onClientConnectionLost(String topic, Object object)
{
synchronized (this)
{
// TODO
System.out.println("ClientsHandler termination");
}
return true;
}

All "Managers" implement the Interface
"NetworkClientTerminationInterface" which has only the
onClientConnectionLost method (see above).

If more than one client calls the onClient...method the synchronize
should prevent problems. On the other hand I don't use the
EventBus.publish() method but I go through all subscribers manually
therefore every subscriber is handled synchronous. Am I right? What do
you
think about this implementation?
The only think I liked to do is a synchronized method but in
interfaces
it is a illegal modifier therefore the synchronized block inside the
method...

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
<
https://github.com/michaelbushe/EventBus/issues/3#issuecomment-49238010>.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#3 (comment).

[Jerry0022]

I think I could basically generalize it. Ok, some improvements could be done (no restriction to one method in one interface). But basically this was the method I gathered for.

The interface has only one method and doesn't extend.

Manager:

@EventTopicSubscriber(topic = "Network_ClientConnection_Lost")
    public void onClientConnectionLost(String topic, Object object)
    {
        // TODO
        System.out.println("ClientManager termination" + topic);
    }

Client:

EventBusExtended.publishSync(topic, this, (new NetworkClientTerminationInterface()
        {
            @Override
            public void onClientConnectionLost(String topic, Object object)
            {}          
        }));

EventBusExtended :p

import org.apache.commons.lang3.ClassUtils;

public synchronized static void publishSync(String topic, Object invokingObject, Object interfaceObject)
    {
        if(interfaceObject.getClass().getInterfaces().length > 1)
        {
            try
            {
                throw new Exception("Only ONE interface to be checked is allowed!");
            } catch (Exception e)
            {
                // TODO: Handle Exception
                e.printStackTrace();
                System.exit(101);
            }
        }

        List<Class<?>> list = ClassUtils.getAllInterfaces(interfaceObject.getClass());
        if(list.size() > 1)
        {
            try
            {
                throw new Exception("Only one interface with ONE method to be executed is allowed!");
            } catch (Exception e)
            {
                // TODO: Handle Exception
                e.printStackTrace();
                System.exit(102);
            }
        }


        ProxyTopicSubscriber subscriber;
        HashSet<Object> subscriberInterfaces;
        for(Object object : EventBus.getSubscribers(topic))
        {
            subscriber = (ProxyTopicSubscriber) object;
            subscriberInterfaces = new HashSet<Object>(Arrays.asList(subscriber.getProxiedSubscriber().getClass().getInterfaces()));

            if(subscriberInterfaces.contains(interfaceObject.getClass().getInterfaces()[0]))
            {

                    try
                    {
                        synchronized (EventBusExtended.class)
                        {
                            subscriber.getSubscriptionMethod().invoke(list.get(0).cast(subscriber.getProxiedSubscriber()), topic, invokingObject);
                        }
                    } catch (IllegalAccessException | IllegalArgumentException
                            | InvocationTargetException | SecurityException e)
                    {
                        // TODO: Handle Exception
                        e.printStackTrace();
                        System.out.println(103);
                }
            } 
            else
            {
                try
                {
                    throw new Exception("Misuse of EventBus with " + topic);
                } catch (Exception e)
                {
                    // TODO: Handle Exception
                    e.printStackTrace();
                }
            }
        }
    }