Thanks Bishnu,
Can you provide a patch? I'll submit it to svn.
Our website could use some jazzing up too if you've got some cycles to
spare?
http://svn.apache.org/viewvc/river/site
Peter.
On 20/05/2014 9:37 PM, Bishnu Gautam wrote:
HI All
I think there are still some old Jini fans who
Actually... I read the article and I'm interested in your upcoming River
tutorial ;)
On 21/05/2014 7:38 PM, Bishnu Gautam wrote:
Hi Peter
Jini installer seems using an older version of LAX installer that is 7.0. It
seems too old and I do not have patch for this installer. However, I have all
extensions,
we could run these manually on Sun's JVM, while allowing River to build
on other architectures.
Regards,
Peter.
Come on people, we need at least three votes to nominate a new Chair.
Lets give this project one last shot.
Tom I have already voted in favour.
Peter.
Thanks Zsolt.
Regards,
Peter.
- Original message -
On Thu, May 15, 2014 at 11:22 AM, Peter Firmstone j...@zeus.net.au
wrote:
Yes, I was testing on another machine, not sure why it uploaded entire
files, especially since the changes were very minor.
IDEs with differing space/tab
Perhaps we should postpone the rename for now.
On 14/05/2014 4:55 PM, Dawid Loubser wrote:
I agree strongly with Bryan here. I do like Rafał's suggested approach
of creating a namespace-compatibilty module if the package names will
change (which, agreed, is probably long overdue).
Making it as
Actually an alternative could be to use future send for all transfers,
except for eof, which can be safely used for async send since the byte
buffer doesn't change after eof.
On 14/05/2014 7:55 PM, Peter Firmstone wrote:
There are two methods of transfer, one, future send, where the
original
Hmm, it already does that, I wonder if this is safe for direct ByteBuffer's?
Visibility is one issue, the second is mutual exclusion. I think mutual
exclusion is ok, not sure about visibility.
On 14/05/2014 8:01 PM, Peter Firmstone wrote:
Actually an alternative could be to use future send
One of the things I like about JERI is it's multiplexing and multithreaded.
What I don't like about JERI is, it passes ByteBuffers between calling
threads and pool threads.
Who can guess what's wrong with that?
Peter.
.
Regards,
Peter.
On 14/05/2014 8:15 PM, Bryan Thompson wrote:
All you need to do is dup the buffer. That gives you independent fields for
position and limit, which is what is not thread safe. You do need a
synchronization section around that dup, but that is a very fast operation.
You can also
On 13/05/2014 9:59 AM, Dennis Reedy wrote:
Apologies for not chiming in earlier, I've been running around with my air
on fire for the past couple of weeks. As to whether River is dead, I don't
think it is, maybe mostly dead (in which case a visit to Miracle Max may be
in order). I think River is
Thought you may find these results interesting, just killed some more
latent concurrency bugs in JERI.
* Mahalo stress tests are now running with 0% contention at close to
raw socket speed.
* ClassLoading is thread confined for each classloader to avoid
contention.
* All
then dynamically create a class remotely, while
remaining compliant with the lambda spec.
Cheers,
Peter.
Sockets
2. DNS-SRV Lookup Discovery
3. Distributed Lambda Expressions
4. Modular build
Good to hear River is still useful.
Regards,
Peter.
On 13/05/2014 12:54 AM, Bryan Thompson wrote:
We have been using river/jini since 2006. While I have very little time for
work on open source projects
managed to modernise the internals with promising results.
I'm working on a bug in JERI at present. The public API has remained
compatible in keeping with general consensus. I have a hard enough time
changing private code, the list is very conservative with change.
Regards,
Peter.
On 13/05
investigate using a provider to plug in
various serialization frameworks that are available now.
That and codebase provisioning should make River really sing.
The stress tests were devised by the original Jini team, they're probably the
closest thing I've got to deployment scenario's.
Regards,
Peter
- Original message -
On 01-05-14 00:29, Peter wrote:
- Original message -
On 30-04-14 02:02, Dennis Reedy wrote:
A this point I'm soliciting opinions and thoughts. Note that using
Gradle is certainly an option here, the breakout into multi-modules is
not tied to Maven
Thanks Dennis,
The test harness presently includes a number of classes from the the main
build, so it'll depend on them, but not include them.
Jsk-policy also needs investigating.
Cheers,
Peter.
- Original message -
You can certainly use the approach in qa_refactor. I did make 2
Thanks for the tip.
Cheers,
Peter.
- Original message -
On Apr 23, 2014, at 8:01 AM, Peter j...@zeus.net.au wrote:
- Original message -
On Apr 22, 2014, at 7:47 PM, Peter Firmstone
peter.firmst...@zeus.net.au wrote:
From: Peter Firmstone
after confirming the modular build structure though.
Cheers,
Peter.
Gr. Simon
they were loaded by the system classloader).
Peter asked me to help him modularizing qa_refactor, this was
something I spotted.
Dennis
information for maven to resolve them.
File names can be obtained from CodeSource's for all classpath classes.
Regards,
Peter.
- Original message -
And actually, why shouldn’t they be resolved in the application’s class
loader? Isn’t an application possibly looking for a service
- Original message -
On Apr 22, 2014, at 7:47 PM, Peter Firmstone
peter.firmst...@zeus.net.au wrote:
From: Peter Firmstone peter.firmst...@zeus.net.au
Subject: Decision process for a Modular build tool
Date: April 22, 2014 at 7:40:29 PM EDT
To: d...@apache.river.org
of order faster and there
is no contention whatsoever.
Cheers,
Peter.
- Original message -
The simple programming mechanism I use for unordered but inclusive
events is a map or set. I use a map for what is expected and a map for
what has happened. I use a thread responding
distributed
system infrasture like no other.
Cheers,
Peter.
- Original message -
Out of order processing always implies a waiting time and timeout events
processing. What is hard, is discovering how long to wait. What hasn’t
been happening by and large, is to have self adjusting
and provide
sufficient information allowing them to be correctly ordered.
Regards,
Peter.
- Original message -
Hi Peter:
You should probably create a JIRA enhancement ticket to track discussion
if you’re picturing adding some kind of order-guaranteeing comparator to
the API. But I
into modules
that mirror the current jar file build result, while remaining build tool
agnostic.
The work performed by Gregg and Sim on ClassLoading is an important step.
Which reminds me, it's probably about time I merged this work in qa-refactor.
Regards,
Peter.
- Original message -
Dnia
This result can be safely ignored, the port required by the test suite is in
use.
- Original message -
See https://builds.apache.org/job/river-qa-refactoring-jdk7/31/
--
[...truncated 8059 lines...]
are-passwords-available:
password:
There's that NoClassDefFoundError again, this time during the build process but
with a different missing class.
Regards,
Peter.
- Original message -
See https://builds.apache.org/job/river-qa-refactoring/161/
--
[...truncated 7268 lines
.
Regards,
Peter.
On 13/04/2014 6:06 PM, Apache Jenkins Server wrote:
Seehttps://builds.apache.org/job/river-qa-refactor-solaris/41/changes
Changes:
[peter_firmstone] Minor improvements for ServiceDiscoveryManager
--
[...truncated 15905 lines...]
[java
On 10/04/2014 10:42 PM, Rafał Krupiński wrote:
Dnia 2014-04-10, czw o godzinie 22:15 +1000, Peter Firmstone pisze:
Rafał,
If you're considering a new git hub project, I'd reccommend using the
qa_refactor branch, it contains a significant number of bug fixes.
ClassLoader and URI string handling
.
Regards,
Peter.
On 11/04/2014 5:40 AM, Gregg Wonderly wrote:
On Apr 10, 2014, at 2:35 PM, Rafał Krupińskirafal.krupin...@sorcersoft.com
wrote:
Dnia 2014-04-10, czw o godzinie 14:40 -0400, Greg Trasuk pisze:
Hi Rafal:
On Apr 10, 2014, at 2:15 PM, Rafał Krupińskirafal.krupin
Rafał,
If you're considering a new git hub project, I'd reccommend using the
qa_refactor branch, it contains a significant number of bug fixes.
ClassLoader and URI string handling perform very well also.
Regards,
Peter.
On 10/04/2014 7:17 PM, Rafał Krupiński wrote:
Dnia 2014-04-09, śro o
Michał,
Just though I'd mention that objects implementing Distributed don't need
to implement Serializable.
Cheers,
Peter.
On 18/03/2014 11:18 PM, Michał Kłeczek wrote:
Thanks Peter,
There is no need to rush with it yet.
I need to run it locally first :-)
But it would be good to have
?
Regards,
Peter.
I'll get a branch build up and running on Hudson for this soon.
Regards,
Peter.
- Original message -
Folks,
I've attached a first patch to River-436.
IMHO the idea is really sound - fixing several issues with River and
creating several new possibilities.
I am more than eager
Serialized objects are given access to streams, you want to send in a patch?
Do you think that Distributed object's should also be given access to the
OutputStream too?
Regards,
Peter.
- Original message -
How about introducing a builder API:
public My getInstance(Arg1 arg1
will be able to configure their
executors to be multi threaded if they wish.
Regards,
Peter.
- Original message -
All you have to provide in the client is a class loading implementation
that knows about Util and pins it into a parent class loader from the
class loaders that proxies load. I
to returning results to clients.
Cheers,
Peter.
On 9/03/2014 6:02 PM, Michał Kłeczek wrote:
Peter,
I'm still trying to grasp what you want to achieve...
Is it simply in-band code downloading?
Regards,
I'm open to suggestion.
Regards,
Peter.
- Original message -
Peter,
Can your SerialReflectionFactory expose an API to interact with the
stream? It would be enough to be able to retrieve context Collection
from ObjectStreamContext.
Thanks,
--
Michał Kłeczek
XPro Sp. z
interface extends DistributedLambda.
Regards,
Peter.
- Original message -
To enable remote clients to invoke processing at the server with lambda
expression invocation on remote objects, without code downloads.
Presently the enclosing class is serialized along with the lambda
Serialization that's simple, rather than
everything's Serializable but broken.
So you're right, magic gone, at least for distributed programming.
I'll do some more investigation, but this looks bleak.
Regards,
Peter.
- Original message -
Doesn’t look like there’s any magic. I performed
.
Thoughts?
Regards,
Peter.
be serialized, without requiring the enclosing class, so
the lambda receipe can be used to create an object independant of it's
original enclosing class during deserialization.
Will keep you posted.
Any thoughts appreciated.
Regards,
Peter.
On 9/03/2014 11:41 AM, Peter Firmstone wrote:
The present
and distribution.
Looks interesting, appears to be AL2 licensed?
Regards,
On Thursday, March 06, 2014 07:56:13 PM Peter wrote:
River doesn't prevent using OSGi, in fact, we are making changes to
enable it, we also want to support Maven, but we don't currently
mandate using either
Actually, Distributed could dovetail nicely with a modular service provider, by
decoupling implementation from state, object state can be migrated to alternate
implementations, remotely, or even locally within the same jvm.
Cheers,
Peter.
- Original message -
- Original message
GlassFish and Jboss do dynamic stub generation for IIOP proxy's too, now that
would be cool.
Cheers,
Peter.
- Original message -
Greg is referring to the fact that Jeri provides the ability to ship a
java.reflection.Proxy object to the report host as the service
implementation
- Original message -
On Mar 7, 2014, at 4:18 AM, Peter j...@zeus.net.au wrote:
Also... Could you elaborate more on code dynamically generated at the
server and how does it differ from code downloading?
Bytecode for lambda expressions is generated at runtime
cannot be changed after deployment.
We could allow Service API to be loaded on demand after deployment, if it
doesn't already exist at the client, but again it cannot be changed after
deployment, only added to.
Cheers,
Peter.
- Original message -
The real problem is that Util interface
,
Peter.
- Original message -
But it will also be loaded by WrapperProxy ClassLoader, since it is
preferred there. So it will end up with ClassCastException, right?
Regards,
Michal
If Util is installed locally, it will only be loaded by the application
ClassLoader, since it isn't
,
Peter.
- Original message -
But it will also be loaded by WrapperProxy ClassLoader, since it is
preferred there. So it will end up with ClassCastException, right?
Regards,
Michal
If Util is installed locally, it will only be loaded by the application
ClassLoader, since
If Util is installed locally, it will only be loaded by the application
ClassLoader, since it isn't preferred.
Peter.
- Original message -
Folks,
while woking on the River-436 patch proposal I've came across the
scenario that I am not sure how to handle:
Utility service
Can we replicate the original jar file?
If we create a modular build, it would help keep this logically separate and
people who currently use it will find the class files where expected.
Regards,
Peter.
- Original message -
They’re not in a separate jar file. They are just part
base.
So it limits plain old Serialization as well, not just codebase downloads.
This solution would also work with your module provider.
Can I suggest creating a new Jira for your module provider, with an
explanation of its capabilities and benefits?
Hope this helps explain it.
Cheers,
Peter
like to change Reggie to use an arbitrary port if a configured port
is in use, this then allows an admin to try a range of ports, using
DiscoveryAdmin, so a port in use failure isn't terminal, but instead a
minor inconvenience.
Regards,
Peter.
net.jini.discovery.DisoveryAdmin states
, 2014, at 7:38 PM, Peter Firmstone
peter.firmst...@zeus.net.au wrote:
I'm currently getting a number of test failures where a port passed in
by configuration is already in use. If the port specified is 0, then
an arbitrary port is selected if 4160 is not available.
However Reggie
mutating, never mutate again after publishing, but mutate
a new object and replace the old one instead.
Regards,
Peter.
On 20/02/2014 9:24 AM, Greg Trasuk wrote:
The standard I proposed is what is currently implemented by River-Container.
Rio’s convention is very much different, and relies
implementation also uses other remote services) while avoiding name
space visibility issues.
Regards,
Peter.
On 20/02/2014 12:58 PM, Greg Trasuk (JIRA) wrote:
[
https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId
suggesting building without classdep.
On 13/02/2014 12:40 AM, Greg Trasuk wrote:
Hi Peter:
I’m still trying to understand what you’re suggesting. Are you talking
specifically about classDepAndJar? When I try to run the build against
JDK8-EA, I get an exception in ‘org.objectweb.asm.ClassReader
+1 Peter.
On 13/02/2014 2:09 AM, Simon IJskes - QCG wrote:
On 12-02-14 17:00, Greg Trasuk wrote:
OK, fair enough. I’ll close this issue and open another one that
just makes sure the jars aren’t in the source distribution (that _is_
an Apache requirement) without adding Ivy.
+1
In general
+1 Peter.
- Original message -
Hi all:
The quarterly report to the board is due on Feb 12. I have attached a
proposed report. Please forward edits you suggest ASAP.
Cheers,
Greg Trasuk.
—Begin proposed report ---
Apache River is a Java-based Service Oriented
+1 Peter.
Note that the current build system does not support java 8.
Maintaining a build system is a significant burden ( I know I had to implement
Java 5 support).
We will need a new build system for java 8, this looks like a step in that
direction. In reality we need to adopt the build
-
Hi Peter:
I’m not familiar with Java 8 yet. How is the current build not
supported?
Cheers,
Greg.
On Feb 11, 2014, at 5:35 AM, Peter j...@zeus.net.au wrote:
+1 Peter.
Note that the current build system does not support java 8.
Maintaining a build system
Original Message
Subject:Re: P2P Internet Services - no code downloads, lambda's
Date: Wed, 05 Feb 2014 22:44:54 +1000
From: Peter Firmstone j...@zeus.net.au
To: Greg Trasuk tras...@stratuscom.com
I agree regarding SOAP and River needing to be easier
a huge
difference to our userbase, which at present appears limited.
Thoughts?
Peter.
just keep squashing bugs...
Regards,
Peter.
- Original message -
+1
I'm in agreement with Dennis on this one. To me it makes sense to move
River forward with a nice big bang miracle upgrade. :-) And adopting
this stuff in as a v3.0 seems like a good idea. I would like to see
light of day, you'll be stuck with
buggy circa java 1.4 style or earlier code on modern jvm's performing new
optimisations that expose these issues in deployed environments.
Remember the major argument cited against is, this code has not been peer
reviewed.
Cheers,
Peter.
Results:
+1 Peter Firmstone (PMC)
+1 Bishnu Prasad Gautam
+1 Luis Matta
Abstain:
Greg Trasuk
I would have liked to see more participation from PMC members, since
this is a vote on a procedural matter and as there have been no
objections after 72 hours, under Apache voting rules it passes.
Notes:
ServiceDiscoveryManager
NotifyEventTask
If the task list contains any RegisterListenerTasks
or LookupTasks associated with this task's lookup service
(ProxyReg), and if those tasks were queued prior to this
task (have lower sequence numbers), then run those tasks
before
Rather than discuss specific instances where I've made changes to ensure
an object reference doesn't escape during construction, I figure it
would be more constructive to discuss final fields themselves.
Some of the arguments against using Startable were based on timing when
references to
service implementations to be thread safe (remote method
invocation is performed via a thread pool), but River doesn't provide an easy
way for implementors to use final fields.
Services can also use static methods and writeReplace, provided they're not
using the starter kit.
Peter.
- Original
and Reggie.
Regards,
Peter.
- Original message -
I understand the sentiment, but I’m uncomfortable with the number of
changes that happened without much review between releases. Run the
following commands:
svn diff https://svn.apache.org/repos/asf/river/jtsk/trunk
https
to the community.
Peter.
- Original message -
Just to clarify, the reversions fixed problems with merging, they were
unrelated to tests.
When I fix a failing test, I first confirm it also passes on either
other architectures or after repeated tests, or that changes made
revealing the failure
on replacing
TaskManager in SDM, JoinManager and Reggie.
Regards,
Peter.
- Original message -
I understand the sentiment, but I’m uncomfortable with the number of
changes that happened without much review between releases. Run the
following commands:
svn diff https
Vote results in chronical order, after 72 hours:
+1 Peter Firmstone
+1 Simon IJskes
+0 Greg Trasuk
According to our rules that's one vote short for inclusion into the Jini
Specification.
On this occassion there was interest in developing a more comprehensive
standard for starting services
,
Peter Firmstone.
also reccommend reverting trunk, with the exception of Sim's
recent work, which I have peer reviewed.
Regards,
Peter.
- Original message -
Given the number of users on this mailing list, and the tiny number of
votes, it seems that many people are abstaining.
Why is this such a touchy
, by consulting
experts in each field relating to a bug?
Do you support theory based development?
+1 Peter Firmstone.
likely to happen too
often, but we need to retain the ability to do so if necessary.
Regards,
Peter.
- Original message -
[
https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870763#comment
and separate out the
event notifications.
Thoughts?
Peter.
com/sun/jini/test/impl/servicediscovery/event/LookupTaskServiceIdMapRace.td
**
* This test attempts to simulate the following race condition that
* can occur between an instance of UnmapProxyTask (created and queued
* in LookupTask
Wouldn't it be more reasonable to expect that each ServiceEvent should
arrive in order for each ServiceID, without regard for the order that
the services (ServiceID's) themselves are registered?
Thoughts?
Regards,
Peter.
/** Executes the current QA test.
*
* For each service instance
com.sun.jini.test.impl.outrigger.matching.StressTest.num_writers=250
com.sun.jini.test.impl.outrigger.matching.StressTest.interleave=true
com.sun.jini.test.impl.outrigger.matching.tryShutdown=1
ant -f
C:\\Users\\peter\\Documents\\NetBeansProjects\\peterConcurrentPolicy
qa.run-tests
qa.run-tests:
qa.james-brown:
Deleting directory
C:\Users\peter
Hmm, 10,000 entries, 400 readers and 250 writers don't appear to be a
problem either.
Anyone have some really decent hardware to give Outrigger a proper workout?
Cheers,
Peter.
scale? (qa-refactor branch in skunk).
Cheers,
Peter.
ant -f
C:\\Users\\peter\\Documents\\NetBeansProjects\\peterConcurrentPolicy
qa.run-tests
qa.run-tests:
qa.james-brown:
Deleting directory
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\qa\soul
Created dir:
C:\Users\peter
services.
I'd be interested in your thoughts, given the issues you've faced with code
downloading.
Regards,
Peter.
- Original message -
From the very early days of Jini, I have not had good luck with
ServiceDiscoveryManager. I actually have perhaps 3 different version
You have no objections to Theoretical analysis?
Now you've had a chance to review the JMM, has it changed your thoughts on
Startable?
Regards,
Peter.
- Original message -
On Jan 4, 2014, at 6:15 PM, Peter j...@zeus.net.au wrote:
“we’re using final variables, therefore all our
know and review it.
Regards,
Peter
Regards,
Greg.
dependency, since Guava
doesn't support serialization compatibility across releases.
Feel free to propose any alternative suggestions.
Please raise any objections to fixing ServiceDiscoveryManager in another thread.
Regards,
Peter.
- Original message -
Gregg,
Are you able to help out
Just a nicety to remove boilerplate casts, see my recent commit to qa_refactor,
svn revision 1554723
If there are any objections I'll revert this change as it isn't critical.
Regards,
Peter.
code auditing as well?
Should we allow theoretical development based on standards like the Java
Memory Model with visual auditing and static analysis with FindBugs, or
should we prohibit fixing bugs that don't include a test case
demonstrating the failure?
Regards,
Peter.
On 4/01/2014 6:58
Would you like me to add this class, so that existing configurations
utilising a TaskManager can also be used? This might be useful for
retaining backward compatibility with existing configurations?
Regards,
Peter.
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more
.*
Regards,
Peter.
- Original message -
I’d like you to make a reasonable case for why TaskManager needs to be
replaced, requiring changes to many other classes that depend on
TaskManager, rather than stating what the problem is with TaskManager
and seeking to fix it, which would only
?
Obviously something that is run much more is going to benefit from the
hotspot compiler, but the numbers and thread counts are difficult to
explain, other than River 2.2.2 is spending most of it's time bogged
down with contention?
Anyone have time to investigate?
Regards,
Peter.
any
dependant tasks from running, I would like to use this as a replacement
for TaskManager and RetryTask.
Can anyone spare time to review, suggest alternatives, or improvements?
Thanks in advance,
Peter.
Failed
com_sun_jini_test_impl_servicediscovery_event_DiscardDownReDiscover.td
Test
the reciepient is, if
that recepient is not contactable in spite of considerable effort, we
should abandon futher attempts to do so. At present RetryTask will
continue to attempt to make contact every 5 minutes.
Regards,
Peter.
Sometimes it’s best not to try to abstract-away all complexity
with Task.runAfter?
When I profile the stress tests now, the hotspot's are Socket's and
there's very little monitor contention.
Regards,
Peter.
On Jan 4, 2014, at 12:18 AM, Greg Trasuktras...@stratuscom.com wrote:
I’ll also point out Patricia’s recent statement that TaskManager should be
reasonably
, accessing a nonexistent DNS server which
stalls it and causes the timing to work out okay? What if the 3.5
second reduction to 2 second reduction that Peter made, opens the window
to T2 using O1 before T1 completes?
We really do need to fix these things. I’ve made many, many patches to
my
Thanks Gregg.
On 24/12/2013 3:04 AM, Gregg Wonderly wrote:
The value for “now” needs to be reestablished in the loop, or else this loop
will wait too long on a spurious wake up.
Gregg
On Dec 23, 2013, at 5:52 AM, peter_firmst...@apache.org wrote:
Author: peter_firmstone
Date: Mon Dec 23
People may also find the following interesting:
http://www.azulsystems.com/blog/cliff/2011-10-17-writing-to-final-fields-via-reflection
Regards,
Peter.
- Original message -
On Dec 20, 2013, at 2:49 PM, Dan Creswell dan.cresw...@gmail.com wrote:
BUT
The critical aspect
That proves wait returning early wasn't the problem.
- Original message -
See https://builds.apache.org/job/river-qa-refactor-win/34/changes
Changes:
[peter_firmstone] After considerable testing using a multi threaded
Executor and Runnable tasks to CAS an AtomicLong to generate
601 - 700 of 1121 matches
Mail list logo
