laforge49 / jactor-util Goto Github PK

To get most of the benefits of JActor2, you have to make it one of your core technology; you have to use it (almost) everywhere. But if you decided to have a lightweight web-client, and you want to reuse the same code both on the client and the server, then you will want to use GWT. But GWT does not support threads, as it is not (yet) available to JavaScript (Note: their is already the JavaScript web-workers https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers , but I don't think all browsers support them yet, and they probably need to be used differently then Java's threads).

So what this means is, if we can keep all the multi-threading related API usage within the implementation of JActor2, then we could have two implementations of the same API, one of which is single-threaded, and GWT ready. This gives us the possibility of reusing domain code in the client, simply by linking to a different implementation of JActor2.

How this is to be done, is as yet not specified. But in the mean time, trying to use generic non-multi-threading-specific interfaces whenever possible, and either moving the creation of multi-threading aware classes to factories, or using "injection", would make the implementation of this task easier. Another issue is with Reflection, as Java's Reflection classes cannot be used directly in GWT. There are (partial) solutions for Reflection, but we need to add dependencies on other APIs to use them.

laforge49:

Good points. So we just need to be careful as to what classes are exposed
in the API for now.

Also, to the best of my knowledge, we do not use reflection.

As JActor is primarily an alternative to threads n locks, GWT with its lack of support for multithreading seems most inappropriate.

In most applications that have "long processing" (say, batch image format conversion) or do network/IO calls, there is a need to limit the number of request being processed in parallel. While having a single reactor do all the work is a solution, sometimes you want to devote more then one thread to it.

A nice solution to this is a "pool". You have a "pool manager" (non-blocking) reactor (blade?) that receives all requests to the pool. This reactor in turn manages a "pool" of Isolation reactors, that do the actual work. It's job is to pass the requests to the pool nodes, such that the incoming requests are processed in order, and as fast as possible, while hiding the implementation of the pool itself. As in typical thread-pools, one has the choice of fixed-size, or grow-as-you-need (un)bound pools, but this should not normally be visible to the pool user. So we might want to offer more then one implementation of the "pattern".

laforge49:

we could also use a kind of semaphore to limit things.

The Bills mail which will give the context about the feature

I made a bit of a mess of things yesterday in my haste to migrate ThreadManager to PActor. Thanks Vicky for cleaning up some of that mess. I've done a bit more now and PingPong once again compiles.

I think Sebastien is right. Dependency injection will be a great way of handling implementations. This applies to MailboxFactory, JID factories and OSGi. Vicky, please do some digging into Google Guice and peaberry.

For now Sebastien, I would appreciate it if you could finish message buffering. After that there is the option of adding Guice/peaberry and cleaning up MailboxFactory a bit more or proceeding with commandeering. But we also need to discuss synchronous messaging, which has a latency of almost 4 times that of PActor. Perhaps there is a faster way of normalizing control flows that will not be as expensive as a second queue in Mailbox.

I do love the [extreme] separation of API and implementation. And it looks like Guice/peaberry will play into this very nicely. You should also observe that the revised PActor javadocs do not speak so much of implementation particulars now but are much more focused on usage. I believe this not only brings greater clarity, but a degree of freedom when supplying alternative implementations or in subsequent revisions of the default implementation. Decoupling is always best, and Dependency Injection the pain points quite nicely. :-)

A tutorial is needed for durable.

Integration with logback ( http://logback.qos.ch/ ) would provide added support for clusters.

Groovy ( http://logback.qos.ch/manual/groovy.html ) can be used for logback configuration.
ServerSocketAppender ( http://logback.qos.ch/manual/appenders.html ) and SocketReceiver ( http://logback.qos.ch/manual/receivers.html ) can used to pass the logs.

This would allow us to have multiple nodes that do the file logging. These nodes then would need to be configured with one SocketReceiver per ZooKeeper node of interest.

See https://github.com/cp149/jactor-logger by Campion. :-)

A micro-benchmark showed me that the "default" hashCode() implementation, which is a "native call", seem to be very slow (like 13 times slower then having your own hashCode() method that just returns some int). If the results are correct, since a short profiling session of one of my PingPong benchmarks shows we spend quite some time using "Sets", defining our own hashCode() method in all the "hashed" classes my speed things up a bit.

Vicky:

Interesting, which tool are you using for profiling?

Sebastien:

I use JProfiler (not free). I can't say if it is better or worst then YourKit or whatever, but that is what we bought at work.

MIGRATED FROM PAMailbox

The discussion about timers reminded me of java.util.Timer. I think something like that is essential to an Actor API. Maybe we can extract it from Project Harmony, and turn it into one of our API classes?

Bill:

Easy enough to write an actor to do it. I like to think of PAMailbox as a minimalist kernel, feature poor, fast and stable. CRON is a service, a part of an OS, but not a part of the kernel.

I think what we really need is a singleton actor which holds a set of Named (see PAUtil for Named) actors that provide various services. A CRON actor would be a first such service. All we really need is for MailboxFactory to hold that singleton, via an effectively final (set once) property. That's all the hook you need.

Skunkiferous:

Fair enough. But before I jump into implementing this, we need to work-out how those "Services" relate to OSGi Services (if at all).

Bill:

not at all. they are just actors associated with an overarching service. hmm. lets wait on this, I'm realizing that there may be different sets of actor services associated with different OSGI services. And I have a lot to do before diving into OSGI again.
…

CRON should be built over a database, I am thinking. This would be a lovely application for jfile, which I will be the next thing I migrate to the PActor API.

The code needs a good rework, using composition to simplify the API much the same way it was done in core. A super high-speed serialization library is important, but no if no one understands how to use it.

A high-performance database with live backups that builds on JActor2 serialization and distributed logging could be very useful in building scalable applications.

In event/message based systems, some things are more "important" then others. While a full-blown request priorisation subsystem might be an overkill atm, having a simple "high priority"/out-of-band flag for Requests/Events would get us a long way.

This would simply cause the new event/message to be set as "next in the list", instead of as last. Possibly it needs not be a flag in the event/message, but rather a send/call optional parameter.

Integration of JActor2 with something like netty's web server or Jetty would make it easier to use JActor2 based servlets.