.
Regards,
Peter.
On 21/12/2013 11:10 AM, Greg Trasuk wrote:
(off-list)
Peter:
You’re sounding unprofessional, and you’re missing the fact that people are
giving reasonable and well-thought-out feedback. You seem to be taking the
conversation personally.Perhaps you should take a few hours
much better at communicating the development concepts, can you
do me a favour and put forward a vote proposal, it would be beneficial to all
parties to come to some decision on the underlying issue.
Regards,
Peter.
- Original message -
I have not seen any evidence of lack
,
documenting it as part of River's external interface, is a Strategy 2
item. It is an external interface change, and needs to be voted on
accordingly.
Logging non-use of Startable is a Strategy 3 item, and is also an
external interface change.
Patricia
On 12/21/2013 3:11 AM, Peter wrote
No problem, don't beat yourself up about it.
- Original message -
Peter - I apologize. I had meant to keep my suggestion to cool down
off-list, but it appears that I failed to remove dev@river.apache.org
from the recipients when I replied.
Cheers,
Greg.
On Dec 21, 2013
find it funny, I probably would have been offended given
that he thinks so little of my efforts.
Never mind, he won't think so poorly of it after its release.
Peter.
- Original message -
On 12/19/2013 10:47 PM, Peter wrote:
- Original message -
On 12/19/2013 12:16 PM, Greg
Pat,
I'd like to invite you back, even if it's just in an advisory capacity.
I think we can all benefit from your experience.
So far you've managed to explain everything so eloquently, the rest of us look
like children fighting over toys.
Regards,
Peter.
- Original message -
On 12
`Jini 2.x
doesn't seem to have such an issue even with the serious flaw you
claim?` are typical of an experimental approach.
As I understand the big picture, Peter is pushing a change to a more
theory-based approach.
Shifting the balance from experimental towards theory involves
is multi core.
Patricia is 100% correct, I'm developing using a more theory driven
approach.
But this is creating unrest with people who are experimental driven;
where are the tests that prove my changes are correct?
The real question is, where next?
Regards,
Peter.
of anyone in the source distribution (the source release).
I've no opinion yet on if 'tool' jars belong in a binary distribution.
Gr. Simon
On 19-12-13 12:10, Peter wrote:
Looking at the last paragraph in Sam's email he goes on to say we can
have jar files in svn for build tools etc
method for lifecycle management?
Closeable would also be acceptable?
Is there anything else you need?
Regards,
Peter.
- Original message -
What we need is a discussion on a more developer-friendly service
startup convention to replace ServiceStarter.
Maybe, that is to say, I'm
for my sense humour? Dan?
No takers? Oh well...
Merry Christmas,
Peter.
(c) even where there is an apparent problem, the exposure window is
very small.
Remember an exposure window can be small in terms of numbers of
statements, but long in terms of elapsed time. Leaving apparently small
Ok, that's definitely worth trying, I don't have suitable hardware right now,
so will see if I can pick up something like a T2000.
Thanks,
Peter.
- Original message -
We might be able to get some benefit more portably by writing a Java
program that spawns a specified number
called after JMM safe construction to allow the service to start any
threads and be exported.
Regards,
Peter.
- Original message -
The way that services are instantiated and setup is an implementation
detail. When I think of compatibility I think of the API and the lookup
methods
, yes we can change it to WARN.
A much harsher option is to throw an exception during export which breaks
backward compatibility.
Regards,
Peter.
- Original message -
org.apache.river.api.util.Commission is an interface services should
implement
If it's a SHOULD, not a MUST
and exporting.
All our services have final fields, so Starter is more appropriate for River's
own services.
Regards,
Peter.
- Original message -
Hmm, good point, Startable, makes more sense.
An object can be exported using Startable.
I think we should have a policy to strongly discourage
So based on this, we should document safe methods for exporting services, log a
message using fine and reference the documentation in the message.
Peter.
- Original message -
Pat your comment about non final fields is interesting.
Isn't it also the case that we need to safely
, however it would be
detrimental if we don't have such a method for those who would.
Regards,
Peter.
- Original message -
I feel like we’re going down a rabbit hole here when you start talking
about exporting immutable objects. Wouldn’t it be kind of silly to
export an immutable
+1 Peter.
I've been going over the Exporter implementations and Exporter interface.
The Exporter interface specifies that export and unexport behaviour is defined
by the implementation.
That means it's up to the implementation to specify whether a happens before
edge occures before export
Sure:
http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/org/apache/river/api/util/Commission.java?view=markup
The interface name will be changed to Startable as per list comments below.
Regards,
Peter.
- Original message -
Hi Peter,
Could you post a link
.
The skunk/qa_refactor branch uses safe construction tehniques and export after
construction, it's had sweeping changes made internally to classes to
significantly improve Java Memory Model compliance.
If you haven't checked out this branch, now's the time to do so.
Regards,
Peter.
for animal sniffer to analyse the public api?
Regards,
Peter.
Maybe it would make sense to
split out the infrastructure services, like Reggie, Mahalo, and
Outrigger into different sub-projects that could be updated separately?
Any thoughts?
Greg.
On Dec 17, 2013, at 5:03 AM, Peter j
I'm happy to accept whatever release version number that the committers decide
when that time comes.
I think it best to narrow our focus for now on how to proceed with the release
process.
Regards,
Peter.
- Original message -
The way that services are instantiated and setup
Thanks Jake, I'll set up a test build for it on the weekend.
Regards,
Peter.
- Original message -
Please verify using buildslave ubuntu1, minerva, with path
$HOME/tools/jtreg/latest/linux/bin/jtreg and jtreg lib path available at
$HOME/tools/jtreg/latest/lib/
-Jake
On Sun
every time, rather than occassionally.
Regards,
Peter.
- Original message -
On 12/17/2013 7:42 AM, Gregg Wonderly wrote:
...
As I’ve discussed here before, one of the most destructive
activities
that has happened in the JDK, has been the “enforcement” of “volatile”
vs “non-volatile
any
tests with thread dumps, the standard tests probably aren't sufficiently
loading the system.
Regards,
Peter.
- Original message -
I don't think you need to assume increased JVM optimization to explain
the phenomenon. It is typical of what happens when increasing thread
safety
Any chance of getting jtreg installed on Jenkins?
Regards,
Peter.
- Original message -
From Tony Stevenson t...@pc-tony.com
Sent Sun, 15 Dec 2013, 23:41:42 EST
To Peter Firmstone peter.firmst...@zeus.net.au
Subject Re: Jenkins - jtreg test suite
Please contact bui...@apache.org
Anyone looked at the code in the failing test yet?
Who can spot the race condition?
I'll give you a hint; on this occassion it happens just before the test
exception.
This bug is a perfect example why it's important to do some housekeeping to
reduce our code debt.
Cheers,
Peter
Hi,
Would it be possible to install the jtreg test library on jenkins?
http://download.java.net/openjdk/jtreg/
River has a number of tests written for jtreg we'd like to run on jenkins if
possible.
Thanks,
Peter.
I've been looking into lambda expressions, good news folks, they are
serializable, so will work with remote services.
This will enable new powerfull remote end processing capabilities. It has the
capacity to redefine the way services are used.
Regards,
Peter.
+1 Peter.
- Original message -
Apache River 2.2.2 is a maintenance release based on the Apache River
2.2 branch, primarily with fixes that add support for JMX entries and
publish additional artifacts to the Maven repository.
Release Notes - River - Version River_2.2.2
** Bug
implementation regarding mutation, these only come
to light are spending hours working through the code.
I have considered rewriting Reggie, after an unsuccessful refactoring attempt.
Regards,
Peter.
- Original message -
https://issues.apache.org/jira/browse/RIVER-336?page=com.atlassian.jira
Thanks Greg, much appreciated.
Peter.
- Original message -
Author: gtrasuk
Date: Thu Aug 8 04:24:55 2013
New Revision: 1511579
URL: http://svn.apache.org/r1511579
Log:
Fix RIVER-423.
Added:
net.jini.lookup.entry.Host
net.jini.lookup.entry.jmx.JMXProperty
it. As I've said before, (speaking just
for me, not as PMC chair) I'm impressed with the amount of work that
Peter has done on concurrency practices, but the manager in me is a
little nervous about the magnitude of the code changes.
Opinions?
Thanks for the compliment.
It'll probably
of tests determine whether a services is
stilll available is by events, if these events aren't recieved, the test
fails.
I could really use a hand, I'm not able to generate the test failures on
my own hardware, so am reliant on Jenkins, which makes debugging almost
impossible.
Cheers,
Peter
causing the arm test
failures, will get back to it later.
Be nice to have some help tho.
Cheers,
Peter.
- Original message -
Original Message
Subject: River-QA-windows build leaving zombie JVMs
Date: Sat, 16 Mar 2013 10:15:26 +0100
From: Niklas Gustavsson nik
changed timing or is directly influencing it.
Please have a look and see what you think:
http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/com/sun/jini/outrigger/OperationJournal.java?view=log
Regards,
Peter.
- Original message -
See comments below...
Greg.
On Tue
rock solid, reliable, predictable and ready for release.
Regards,
Peter.
- Original message -
I was hoping to announce the qa tests were sorted, having just fixed outrigger
(please peer review outrigger changes in skunk/qa-refactor), however an issue
with Reggie has decided to rear its
, provided it occurs before
sharing with other threads. It would allow Entry's to be shared safely among
threads, as long as their public fields aren't mutable, eg: an array.
Regards,
Peter.
manifest on Windows too), they come back when something unrelated is fixed,
they appear to be sensitive to timing.
These bugs require a superhero / genius dev. I'm finding this a frustrating
long drawn out exercise.
Regards,
Peter.
- Original message -
Hi Peter,
I'm curious
threads.
To avoid potential deadlock from dependant tasks executing out of order JERI
always creates a new thread if no free threads are available in its internal
thread pool.
Regards,
Peter.
- Original message -
On Tue, 2013-06-11 at 08:23, Peter wrote:
I've been thinking about how
distributed nodes, one
more local copy won't hurt.
I'm thinking about a best practices web page for user devs.
Regards,
Peter.
- Original message -
On Tue, 2013-06-11 at 08:23, Peter wrote:
I've been thinking about how Entry objects are immutable in serialized form
and of course
blog post that proposed immutable arrays as a feature in a
future Java version.
Thanks,
Peter.
- Original message -
It is very important for us to get this publish stuff nailed down so that
there are no problems that keep resurfacing because of this important part of
the JMM.
We might
progress. The positive discussion about these
issues is heartening.
I did see an Oracle blog post that proposed immutable arrays as a feature in a
future Java version.
Thanks,
Peter.
- Original message -
It is very important for us to get this publish stuff nailed down so
will of course be appreciated.
Regards,
Peter.
behaviour writing Entry's to the space in
deployment? Eg entry's going missing, not matching, or update
notifications not occurring? It's likely this could have been confused
with network failure, which the Jini infrastructure handles quite well.
Regards,
Peter.
on code simplification
and correctness to really make our codebase solid, so it's easier to
understand and develop, if we're fortunate enough, wiser, more
experienced (not to mention modest) developers will be tempted to jump
in and do some really great work.
Regards,
Peter.
Greg,
I've forwarded you a copy.
Brian's been very helpful running tests on OSX for me. I cc'd the previous
email to the list.
Regards,
Peter.
- Original message -
Bryan:
I can't find your original email to Peter re these test failures on the
dev list archives. I know people
,
Peter.
On 29/05/2013 5:01 AM, Bryan Thompson wrote:
Peter, see attached. Summary below.
Thanks,
Bryan
Revision: 1486719
[java]
[java] # of tests started = 1406
[java] # of tests completed = 1406
[java] # of tests skipped = 52
[java] # of tests passed= 1405
- Original message -
On 5/27/2013 4:45 PM, Peter wrote:
...
For example the last test failure on arm was caused by it. I couldn't
reproduce it on other architectures, but arm had a high frequency of
failure.
...
Could this be related to ARM's relaxed memory model which reorders
Yes we really should standardise these conventions, Dennis, have you had
any thoughts about doing some standards docs?
I'd also like to see Rivers deployment jars be updated to follow these
conventions.
Regards,
Peter.
On 27/05/2013 9:29 PM, Dennis Reedy wrote:
Greg,
You could take
On 27/05/2013 10:05 PM, Dennis Reedy wrote:
On May 27, 2013, at 737AM, Peter Firmstone wrote:
Yes we really should standardise these conventions, Dennis, have you had any
thoughts about doing some standards docs?
No, I really haven't. What would make it standards docs?
A place among
Well done Greg, hey I noticed you've got an annotation called Init, this
would allow a service to be exported and have any threads started after
construction wouldn't it?
Regards,
Peter.
On 27/05/2013 6:28 PM, Greg Trasuk wrote:
Hi all:
As you know, I've been working for some time
Sounds like a good proposal, River 3.0.
Thoughts?
Peter.
- Original message -
My startnow project on java.net, has always provide a separation of
construction and start of the service export. However, the usage of that API
is
supposed to be something like the following.
public
Now I remember why I stopped testing on Solaris, there's a port conflict.
On 17/05/2013 2:56 PM, Apache Jenkins Server wrote:
Seehttps://builds.apache.org/job/river-qa-refactor-solaris/1/
--
[...truncated 16091 lines...]
[java] Test Passed: OK
the bug database and have ignored my requests
to obtain access.
Anyone know someone at Oracle who may have a sympathetic ear?
Regards,
Peter.
. Review changes.
7. Release trial candidate for wider testing.
8. Release.
Regards,
Peter.
Thanks for the reminder I'll get it uploaded before River 2.3.0 is released.
The library can be found at
http://sourceforge.net/projects/custard-apple/?source=directory
River 2.2.1, our most recent release, doesn't depend on the library.
Regards,
Peter.
- Original message
process with command:
'C:\Program Files\Java\jdk1.6.0_26\jre\bin\java'
-Djava.security.manager=org.apache.river.api.security.CombinerSecurityManager
-Djava.security.policy=file:/C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/qa/harness/policy/defaulttest.policy
On 7/05/2013 8:17 PM, Peter Firmstone wrote:
This test smells broken?
I modified the output to read in milliseconds.
Relevant ServiceDiscoveryManager method under test:
public ServiceItem[] lookup(ServiceTemplate tmpl,
int minMatches
if it returns in the waitDur time window.
I think the ms time ranges you've mentioned are more appropriate, they are
achievable in practise (I checked).
I'll submit a patch for review.
Peter.
- Original message -
Hi Peter:
I'd certainly apply some tolerance band to the test result
,
nRemovedExpected = 1
Local Failure:
Starting test in separate process with command:
'C:\Program Files\Java\jdk1.6.0_26\jre\bin\java'
-Djava.security.manager=org.apache.river.api.security.CombinerSecurityManager
-Djava.security.policy=file:/C:/Users/peter/Documents/NetBeansProjects
) deserialized from the stream
until proxy verification has been performed?
The challenge is, how can we do this and retain backward compatibility
in marshalled object streams?
If there's an answer to those questions, it's the security grail for
Jini the Sun team was looking for.
Cheers,
Peter.
Hmm, yes we actually need to completely avoid Serialization and RMI
until we've authenticated the remote end, I've been thinking about
developing a ServiceLocator, that can be constructed from a string, that
isn't serializable, but allows a service connection to be authenticated,
prior to
that much of the Jini code was
written prior to 2004, before the JMM was ratified.
There are still well designed features in Jini API.
Regards,
Peter.
On 30/04/2013 7:24 AM, Dennis Reedy wrote:
If we dont have a process wrt RTC, then it doesn't really matter what tools or
SCMs you bring
and must not allow
registration of untrusted services and proxy's themselves need to use
secure connections also. (I know you know that Gregg, I just thought
I'd reiterate it for the benefit of others).
Cheers,
Peter.
On 29/04/2013 12:18 AM, Gregg Wonderly wrote:
The obvious issue
to know precisely what the changes are.
This commercial enterprise is not likely to be an early adopter? Is
good Javadoc sufficient?
Peter.
resources are needed to perform this work?
How many releases are you proposing in this time frame?
Keep in mind there are a lot of very important race conditon / visibility fixes
that need to make it to release sooner rather than later.
Peter.
- Original message -
Hi Jeff:
Interesting
All qa suite tests are now passing
All jtreg tests that are known to pass are passing (those that depend on
a Kerberos Domain server and Squid do not as expected).
To address concurrency,the issue of threads starting during service
server construction (River-418), a new interface has been
On 27/04/2013 11:26 AM, Greg Trasuk wrote:
On Fri, 2013-04-26 at 16:58, Peter Firmstone wrote:
Checked RIVER-[404], the jtreg test certs still fail.
It's been fixed in trunk, we need to remove it from the release notes
for 2.2.1
I don't think River-[403] or River-[417] made it into 2.2.1
on
ThreadPool threads. I reasoned it could be and that was sufficient
justification to not use setName().
Cheers,
Peter.
On 27/04/2013 1:20 AM, Patricia Shanahan wrote:
I've looked at the source code. The field name that is shared
between threads doing getName or setName on a given Thread
Based on your reasoning and because all tests are passing reliably without
failure now, it should be safe to uncomment it.
Peter.
- Original message -
I also don't see the particular concern with toString(). It uses
getName(), so it does all its work with a particular char
way to perform that operation safely, the likelihood of error remains low and
I believe there is a good chance it'll be fixed in the next version of Java.
Peter.
Peter wrote:
Based on your reasoning and because all tests are passing reliably without failure now, it should be safe to
uncomment
-Dcom.sun.jini.qa.harness.runkitserver=true
-Djava.security.properties=file:/opt/src/river/trunk/qa/harness/trust/dynamic-policy.properties
-Dcom.sun.jini.qa.harness.testhosts=
-Djava.util.logging.config.file=/home/peter/logging.properties
-Dcom.sun.jini.test.home=/opt/src/river/trunk/qa
that was left unfinished.
River-[403] really needs to be included though.
Regards,
Peter.
*** Start test: Sat Apr 27 06:46:43 EST 2013
[jtreg] Test 1: TestRMI$TestClientSubjectAfterSwitchConstraints:
[jtreg] FAIL: Unexpected exception: java.lang.IllegalStateException:
no object exported via
+1 conditional on removal of River-[403] and River-[404] from release notes.
Greg Trasuk wrote:
On Fri, 2013-04-26 at 14:24, Greg Trasuk wrote:
Apache River 2.2.1 is a maintenance release based on the Apache River
2.2 branch, primarily with fixes that correct incompatibilities with
Oracle
wants a copy of the profiler results, just ask.
Or checkout the code and try it for yourself. If someone's got the time
the hardware, I'd love to see how it goes on recent hardware with 8 or
more cores.
Cheers,
Peter.
River 2.2.0
Hot Spots - Method Self time [%] Self time
to
test out the 2.2 branch. However, that is likely to conflict with the
testing that Peter is doing on his qa_refactor branch. Does Jenkins
have a way of arbitrating access so that the test runs will not be
concurrent, thus avoiding any port conflicts?
Don't worry too much about conflicts
I wonder if a garbage collection might also cause some latency?
On 18/04/2013 9:27 PM, Peter Firmstone wrote:
This test appears to fail due to asynchronicity
The abort task is submitted to the TaskManager before the test thread
sleeps for 1 second, but the abort task attempts to execute
always the
option of running a 2.2 maintenance branch for those who'd like to wait
longer before upgrading.
Regards,
Peter.
On 11/04/2013 2:00 AM, Gregg Wonderly wrote:
I just want to extend this conversation a bit by saying that nearly everything about River is
concurrently accessed
On 10/04/2013 7:46 PM, Simon IJskes - QCG wrote:
On 10-04-13 09:44, Peter Firmstone wrote:
I wonder if there's a way to detect RLIMIT_NOFILE from java?
Other then spawning a shell with 'ulimit -n' i can't tell.
In order to find the open port and do a 'lsof -i :4160' we need root
access
Greg,
Are you testing on Java 7?
The last release was only tested with Java 5 and 6.
Can you test with Java 6?
Regards,
Peter.
On 10/04/2013 6:32 AM, Greg Trasuk wrote:
On Tue, 2013-04-09 at 15:29, Peter Firmstone wrote:
This was being discussed in two separate threads:
Greg,
Are you
On 10/04/2013 9:16 PM, Simon IJskes - QCG wrote:
On 10-04-13 13:09, Peter Firmstone wrote:
Where shall i put it? It's a single class.
The qa suite package com.sun.jini.test.share looks like a good
candidate.
http://svn.apache.org/viewvc/river/jtsk/skunk/sijskes/SimpleJeri/Heapdumper.java
test process responsible?
Regards,
Peter.
Greg Trasuk wrote:
On Mon, 2013-04-08 at 15:59, Peter wrote:
Greg,
I apologise again for my outburst, I was wrong about your leadership skills.
I couldn't help but notice the number of test failures, did they have an error
message like the number
specify a particular port, you get 4160 and the portInUse
method is supposed to work around that.
When a test finds a port in use, it updates the registrar wanted to an
available port. If it thinks 4160 is available, when it isn't, boom,
test failed.
Regards,
Peter.
Greg Trasuk wrote:
I
find it.
Sim wrote:
On 09-04-13 11:44, Peter Firmstone wrote:
I've never experienced the issue locally (I see it on Jenkins quite a
lot), but I suspect a stale registrar process left from another test may
be stopping the socket from closing. Not that registrars are also
simulated for discovery
.
Regards,
Peter.
Peter Firmstone wrote:
This was being discussed in two separate threads:
Greg,
Are you able to find which process is using a port? Perhaps jvisualvm
might help determine which test it is? If you can narrow it down to a
bunch of test definitions sharing a test class
.
Regards,
Peter.
- Original message -
On 4/7/2013 7:03 PM, Greg Trasuk wrote:
I'm honestly and truly not passing judgement on the quality of the code. I
honestly don't know if it's good or bad. I have to confess that, given that
Jini was written as a top-level project at Sun
documented and should be easy to read,
I've followed Kent Beck's recommendations for code readability.
I hope this helps.
Regards,
Peter.
Greg Trasuk wrote:
OK, so in my last message I talked about how (speaking only for myself) I'm a
little nervous about the state of the trunk.
So what now
thorough to minimise surprises.
The Levels show stopper (caused by our dependency on the internal
serialized form of Levels) has increased pressure to produce a release.
I'd be interested to learn more about your experience with Git if you're
interested in sharing ;)
Cheers,
Peter.
Jeff
own personal development and
an opportunity to grow as a leader.
You also hold the future of this project in your hands, so I hope you find
strength to let go.
Regards,
Peter.
- Original message -
OK, so in my last message I talked about how (speaking only for myself) I'm a
little
by downstream users.
Regards,
Peter.
Dan Creswell wrote:
On 6 April 2013 14:44, Dennis Reedy dennis.re...@gmail.com wrote:
On Apr 6, 2013, at 532AM, Dan Creswell wrote:
Right so we're into brutal tradeoffs aren't we?
It's beginning to smell like none of the available branches are suitable
probably consider each case individually, I noticed there's a
configuration property that allows a TaskManager instance to be injected on a
number of occasions too, which suggests there might be some sharing.
Peter.
On 4/3/2013 2:04 PM, Dan Creswell wrote:
I'm with you. My first step was going
? I'm going to try this
after we've fixed TaskManager.
Regards,
Peter.
- Original message -
Notes on the commit I just did -- Holy Macinaw, there's been a lot of
changes checked in since our last release (2.2.0). Enough to make me a
little nervous about 2.3 - Ideally we would release
Dennis Reedy wrote:
On Apr 5, 2013, at 956PM, Peter wrote:
We can't afford to hold up 2.3.0 much longer, the 2.2.0 release has numerous
synchronization bugs, these will become more apparent on multicore hardware.
The longer we wait the more likely they'll present in deployed systems
Gut feeling suggests the solution will be executor based, so you're asking good
questions, I think we need to understand the use cases better and probably
redesign dependant code too.
One example of retry, the task will continue attemtping to retry for an entire
day.
We might need some kind
I've appended Patricia's notes in html so we don't lose the table
formatting, hopefully it will be accepted by the mailer.
On 2/04/2013 1:38 PM, Patricia Shanahan wrote:
I've sent Peter some notes that I hope he can make available - I don't
think I can send attachments to the list.
Rereading
On 1/04/2013 8:14 PM, Peter Firmstone wrote:
The attachments will be removed from the list, so I've cc'd you,
anyone who's interested, let me know I can forward the attachments.
They can be opened with jvisualvm.
The profiling isn't perfect, the test runs for about 8.5 minutes, so
hotspot
give up waiting after a reasonable amount of time.
Anyone have time to assist investigating a solution?
Regards,
Peter.
On 3/04/2013 1:01 AM, Patricia Shanahan wrote:
My concern with RetryTask is related to your point about If a task
completes before another task which it's supposed to runAfter
Food for thought: After our pending release, it might be an idea to
make a combined effort to identify and address as many concurrency
issues as possible, we need to modernize our implementation code so we
stay relevant.
An important task will be updating all our service implementations so
Dan Creswell wrote:
On 1 April 2013 08:11, Peter Firmstone j...@zeus.net.au wrote:
Food for thought: After our pending release, it might be an idea to make
a combined effort to identify and address as many concurrency issues as
possible, we need to modernize our implementation code so we
701 - 800 of 1121 matches
Mail list logo
