eBus / News: Recent posts

eBus 4.4.0: Get the (eBus) Message

eBus 4.4.0 focus is on allowing abstract EMessage and EField
field types. Prior to this release, eBus only allowed concrete
EMessage and EField types. This release makes it possible to
have an abstract EMessage/EField classes as a field type and
successfully transmit the overall message to another eBus
application.

This change also applies to an array of such abstract field
types. This means that an EMessage[] or EField[] may contain
different subclass instances. That is, the array elements are not
required to be instances of the same subclass.... read more

Posted by Charles Rapp 7 days ago

eBus 4.3.7: Yet More Bug Fixes

eBus v. 4.3.7: Yet More Bug Fixes

This release fixes the following bugs:

Bug 21: Remote subscriptions not closed on connection loss.
Remote subscriptions were left in place on connection loss because eBus needed to cast the remote feeds to its proper type in order to unadvertise or unsubscribe and ESubscribeFeed was left out of this code. This is corrected by now calling EFeed.close() because remote feeds are thrown away on connection loss.... read more

Posted by Charles Rapp 2017-05-29

eBus 4.3.6: New Dispatcher Features

eBus v. 4.3.6: New Dispatcher Features

New Features

Special Dispatcher Thread Types
There are two new Dispatcher threads: SWING and JAVAFX. Using these names in the eBus.dispatchers property means eBus will use the Swing and JavaFX GUI threads to deliver events to eBus clients. When an eBus client receives events on the GUI, then the client can freely update GUI controls from that event callback method.... read more

Posted by Charles Rapp 2017-05-07

eBus 4.3.5: More Bug Fixes

eBus v. 4.3.5: More Bug Fixes

eBus v. 4.3.5 fixes bugs 19 and 20. Bug 19 points out that the EServer API change to allow multiple eBus services did not change closeServer() to accept a service port argument. This has been corrected as well as adding a closeAllServers() method.

Bug 20 corrects error in eBus remote connection logic introduced in v. 4.3.3. These errors were not found in unit test because of bugs in the ConnectTest JUnit test class. The errors in both ETCPConnection, EAbstractConnection, and ConnectTest are corrected in this version and remote connections are now working.

Posted by Charles Rapp 2017-03-29

eBus 4.3.4: Bug Fix

eBus v. 4.3.4: Bug Fix release.

eBus v. 4.3.4 fixes bug 18. Testing showed that if a feed was advertised, unadvertised, and re-advertised, then the feed would not receive feed state updates because the feed was not correctly reset when unadvertised. This problem also applies to subscriptions.

This problem is now corrected in v. 4.3.4.

Posted by Charles Rapp 2017-03-23

eBus 4.3.3: Multiple service ports.

eBus 4.3.3: Allowing multple service ports.

eBus v. 4.3.3 now allows an application to open multiple service ports instead of just the one. If you are using an eBus configuration file to define your service ports, then you must now add an "eBus.services" property which specifies a comma-separated list of service names. This service name must now appear in each individual service property name.

This means services are defined in the same manner as client connections. The API and configuration property changes are explained in the latest eBus Programmer's Manual.... read more

Posted by Charles Rapp 2017-03-03

eBus 4.3.2: Request feed callbacks and java.time support.

eBus v. 4.3.2: taking time for more callbacks.

eBus v. 4.3.2 adds two new minor features: improved callbacks for request feeds and adding java.time classes to supported message data types.

Request messages use @EReplyInfo to specify which reply message classes may be sent in reply to that request. Prior to this release, ERequestFeed.replyCallback(ReplyCallback) method put one callback in place for all reply message classes.... read more

Posted by Charles Rapp 2017-02-12

eBus 4.3.1: eBus & SMC - A match made in Heaven.

Marrying eBus with SMC

eBus 4.3.1 Release

Release 4.3.1 contains the utility SmcDemoSrc_1_0_0.tgz which shows how Java lambda expressions make it possible to translate eBus messages directly into finite state machine transitions when the FSM is generated by SMC. eBus Programmer's Manual contains a new section "State of the Union: eBus & SMC" which describes how an SMC-generated FSM is integrated into your object and into eBus.... read more

Posted by Charles Rapp 2017-01-15

eBus 4.3.0: Happy New Year!

eBus 4.3.0

This release introduces a new feature which makes it possible for application objects to open their feeds from within an eBus Dispatcher thread. This eliminates the problem of eBus calling back an object while the object is opening its feeds. See the eBus Programmer's Manual section entitled "Gentlemen, start your objects" for details. The new functionality is in the net.sf.eBus.client.EFeed class.... read more

Posted by Charles Rapp 2017-01-02

eBus 4.2.1 Release: Bug Fix Release

eBus 4.2.1

This release makes a minor change to Dispatcher configuration and corrects a bug wherein local reply feed state is not forwarded to a remote eBus application.

Dispatcher Configuration
The eBus blocking, spinning, and spin+park run queue types are replaced with java.util.concurrent.ConcurrentLinkedQueue. This resulted in the dropping of the Dispatcher configuration parameters runQueueType, spinLimit, and parkTime.... read more

Posted by Charles Rapp 2016-12-04

eBus 4.2.0 Release: Lambda expression support.

eBus 4.2.0 Release

eBus client role interfaces now support lambda expression callbacks. Application classes are still required to implement the role interface associated with a given feed type but do not have to override the interface methods. Instead, an application class can have eBus callback to a lambda expression.

Note: this feature is backward compatible. Existing code can use eBus 4.2.0 with no changes. Existing eBus applications will see no change in eBus behavior now that lambda expressions are supported.... read more

Posted by Charles Rapp 2016-11-20

eBus API Update

No sooner have I started working on an eBus GUI, then I discovered that eBus does not make full use of what Java 8 offers.

GUIs have a tight coupling between callbacks and GUI controls. JavaFX for Java 8 supports this coupling using @FunctionalInterfaces and Lambda. That means that events are passed directly to the code for processing that event. And that code can reference a control it needs to update.... read more

Posted by Charles Rapp 2016-11-16

eBus GUI

The next eBus release will be a JavaFX-based GUI that does the same work as the esample program. User can open publishers, subscribers, repliers, and requestors as well as open and close remote connections. User-defined messages will be supported. The goal will be to show how easy it is to use eBus in any Java application.

Posted by Charles Rapp 2016-11-11

eBus Future.

The latest eBus version 4.1.0 finalizes the move to the new feed-based API. I normalized the interface between producers (publishers and repliers) and consumer (subscribers and requestors). The focus is to develop new and more sophisticated feeds. Ideas for these new feeds are:

  • Historical, On-going notification feed: A subscriber requests notifications from a given time interval. This interval may be entirely in the past, past and present, and present to some future time. The current notification feed has a time interval from the present and on-going. A purely future time interval is not supported. The difficulty with this feed is merging past and present notifications so that overlapping notifications are detected, preventing duplicate notifications being posted to the subscriber. Another problem is detecting gaps between the retrieved historical messages and newly received messages.
  • Active/Stand-by notification feed: Publishers declare a feed state as ACTIVE or STAND_BY. Both imply an UP feed state. An active/stand-by subscribe feed tracks this state and forwards to the subscriber the active publisher's notifications only. If the ACTIVE publisher goes down, then the active/stand-by subscribe feed switches to the newly activated STAND_BY publisher. While this sounds simple in principle, there are some difficulties to overcome:
    1. How do two or more publishers decide which is active and which is stand-by?
    2. How do two or more publishers keep in sync? For this scheme to work, there must be a way to make sure all publishers are posting the same notification message at the same time.
    3. If question 2 is answered, then how to detect that a publisher is significantly lagging the others? And if detected, what should be done about it?
    4. Again, given that question has a satisfactory answer, is active/stand-by needed? Shouldn't the subscribe feed forward the first notification to arrive and then ignore the redundant notificatons arriving after that?
  • Active/Stand-by request feed: Requests are posted to the active replier only. If the active replier goes down, then the feed switches to the newly activated stand-by feed. A variation on this is to post the request to all repliers but forwarding only the active replier's response to the requestor. The goal here is to compare the responses from the active and stand-by repliers to determine they are the same. If they differ, then some sort of corrective active is needed.
  • Load balancing request feed: The request feed forwards request to one of serveral repliers, evenly distributing the requests across the repliers. The goal is to keep the work load roughly equal across the repliers, resulting in equal response times.... read more
Posted by Charles Rapp 2016-11-11

eBus v. 4.1.0: Request/Reply API Update.

eBus v. 4.1.0

Overview: Request/Reply API and Minor Changes

Note: eBus v. 4.1.0 is NOT backward compatible.
Note: eBus v. 4.1.0 requires Java 8.

eBus 4.1.0 changes the request and reply API between the
application and eBus.

+ A requestor must call ERequestFeed.subscribe() before
  posting a request message to the feed.

+ ERequestor interface has a new method:
  void feedStatus(EFeedState, ERequestFeed)... [read more](/p/ebus/news/2016/11/ebus-v-410-requestreply-api-update/)
Posted by Charles Rapp 2016-11-09

eBus 4.0.0: New API

eBus v. 4.0.0

Overview: Major API and JVM Changes

Note: eBus v. 4.0.0 is NOT backward compatible.
Note: eBus v. 4.0.0 requires Java 8.

eBus 4 changes the API between the application and eBus.
eBus API is now based on feeds, making a simpler API to use.

An application interacts with eBus by:

  1. Opening a publisher/subscriber/requestor/replier feed.
  2. Advertising/subscribing on that feed.
  3. Sending/receiving messages on that feed.... read more
Posted by Charles Rapp 2016-03-13

Re-designing net.sf.eBus.client package.

The next eBus release will be version 4.0.0, introducing a new eBus API. The old API based on EAdvertisement, ESubscription, etc. will be replaced with a new API based on feeds. For each eBus role (EPublisher, ESubscriber, ERequestor, and EReplier), there is a feed (EPublishFeed, ESubscribeFeed, ERequestFeed, and EReplyFeed). The new API will be used as follows:

  1. Implement an eBus role.
  2. Open the feed associated with that role and for a specific message key.
  3. Advertise/subscribe/request on that feed.
  4. When done, unadvertise/unsubscribe from that feed.
  5. Close the feed.... read more
Posted by Charles Rapp 2016-02-09

Moving to Java 8.

Java 8 has been out for almost 1.5 years and Java 9 will be out in 1 year. There are features in that release which I wish to use in eBus. As a result, the next release will be built with Java 8 and will be using lambda features.

So be aware that eBus is moving on to Java 8.

Posted by Charles Rapp 2015-08-06

eBus 3.2.5: Minor Improvements.

Overview: Minor improvements and bug fixes.


net.sf.eBus.client:

ERemoteApp:


Declared _connections as a java.util.concurrent.ConcurrentMap,
removed excessive use of locks associated with _connections.


net.sf.eBus.comm

EConnection:


Converted _reconnectDelay and _heartbeatDelay from long to
AtomicLong. Removed locks associated with these variables.... read more

Posted by Charles Rapp 2015-01-26

eBus 3.2.4: Multicast your bread upon the water.

Overview: Major, minor improvements and bug fixes.


net.sf.eBus.client:

EClient:


Exposed this class so applications may post tasks to an eBus
client's executor. This makes eBus objects effectively
single-threaded by accessing the client from its executor
alone. Note: the client executor is a single-thread.

ERemoteApp:


Corrected state machine so that when the connect fails to open
and the connection is configured to reconnect, the next state
is "Reconnecting", not "Closed".... read more

Posted by Charles Rapp 2014-11-01

eBus 3.2.3: Fourth of July Release.

eBus v. 3.2.3

Overview: Bug fixes and improvements.

NOTE: I am unable to check in my changes to eBus' SourceForge
Subversion repository. The source code is available as a
separate download. The changes will be checked in as soon
as the problems are resolved.


net.sf.eBus.client:

EClient:
Changed executor thread creation and assignment so that:
1. A new executor is created only when needed (up to a maximum
set at the number of available processors).
2. A client is assigned to the executor with the fewest number
of clients.
3. If the client is an ERemoteApp proxy, the proxy uses the
ERemoteApp's executor. That means each eBus connection uses
only one executor.... read more

Posted by Charles Rapp 2014-07-05

eBus 3.2.2: ERequest Improvement.

eBus v. 3.2.2

Overview: One minor change.


.Net No Longer Supported

Due to my C# skills de-grading, the .Net eBus is no longer
supported.


eBus.jar incorporates dependent libraries.

eBus.jar now includes classes from its dependent libraries:
SMC's statemap.jar and javassist.jar. There is no need to
download these jar files separately and include on the classpath.... read more

Posted by Charles Rapp 2014-06-08

eBus 3.2.1: Memorial Day Release

eBus v. 3.2.1

Overview: One minor change.


.Net No Longer Supported

Due to my C# skills de-grading, the .Net eBus is no longer
supported.


eBus.jar incorporates dependent libraries.

eBus.jar now includes classes from its dependent libraries:
SMC's statemap.jar and javassist.jar. There is no need to
download these jar files separately and include on the classpath.... read more

Posted by Charles Rapp 2014-05-26

eBus 3.2.0: Improved message serialization.

Overview: Two major changes and bug fixes.


.Net No Longer Supported

Due to my C# skills de-grading, the .Net eBus is no longer
supported.


eBus.jar incorporates dependent libraries.

eBus.jar now includes classes from its dependent libraries:
SMC's statemap.jar and javassist.jar. There is no need to
download these jar files separately and include on the classpath.... read more

Posted by Charles Rapp 2014-05-18

eBus 3.1.0: Faster than ever!

eBus v. 3.1.0

NOTE: eBus v. 3.1 contains code-breaking changes due to a
need to simplify message processing and improve eBus
performance.

Overview: The release goal was to noticeably improve eBus
performance by reducing the number of "bookkeeping"
classes and, in turn, reducing the number of instances.

      eBus classes now fall into two categories: subjects and
      handles. There are two subject classes:... [read more](/p/ebus/news/2014/02/ebus-310-faster-than-ever-449/)
Posted by Charles Rapp 2014-02-17

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks