[GitHub] incubator-edgent pull request #201: [WIP] Edgent-251 adapt Eclipse to not us...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-edgent/pull/201


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (EDGENT-251) [gradle] initial work for developing Edgent runtime with gradle in Eclipse

[Dale LaBossiere (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EDGENT-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale LaBossiere resolved EDGENT-251.

Resolution: Fixed

> [gradle] initial work for developing Edgent runtime with gradle in Eclipse
> --
>
> Key: EDGENT-251
> URL: https://issues.apache.org/jira/browse/EDGENT-251
> Project: Edgent
>  Issue Type: Task
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>
> An Eclipse-based Edgent runtime development enviroment depends on the 3rd 
> party jars currently present in the Edgent repository (the Eclipse .classpath 
> files present in the repository depend on them)
> Those jars will be removed, replaced by a gradle based build environment, 
> when all of the pieces are in place  - EDGENT-139.
> Summary: (changes in PR-201)
> - The user must run "./gradlew setupExternalJars" to satisfy the projects' 
> .classpath jar references
> - Read DEVELOPMENT.md - 
> https://github.com/apache/incubator-edgent/blob/master/DEVELOPMENT.md
> Removal of the 3rd party jars from our repo will be covered by a separate 
> issue.
> Note: My initial experience trying to use the Buildship gradle/Eclipse
> integration came up short. The way it created/updated .classpath files
> as a result of the way dependencies are expressed in our build.gradle
> files was problematic. So, I scoped back to the approach here to get to
> the end-goal (removal of dependency of 3rd party jars in the repo) asap.
> Should revisit the buildship env later to see if things can be made to
> work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (EDGENT-251) [gradle] initial work for developing Edgent runtime with gradle in Eclipse

[Dale LaBossiere (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EDGENT-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale LaBossiere updated EDGENT-251:
---
Description: 
An Eclipse-based Edgent runtime development enviroment depends on the 3rd party 
jars currently present in the Edgent repository (the Eclipse .classpath files 
present in the repository depend on them)

Those jars will be removed, replaced by a gradle based build environment, when 
all of the pieces are in place  - EDGENT-139.

Summary: (changes in PR-201)
- The user must run "./gradlew setupExternalJars" to satisfy the projects' 
.classpath jar references
- Read DEVELOPMENT.md - 
https://github.com/apache/incubator-edgent/blob/master/DEVELOPMENT.md

Removal of the 3rd party jars from our repo will be covered by a separate issue.

Note: My initial experience trying to use the Buildship gradle/Eclipse
integration came up short. The way it created/updated .classpath files
as a result of the way dependencies are expressed in our build.gradle
files was problematic. So, I scoped back to the approach here to get to
the end-goal (removal of dependency of 3rd party jars in the repo) asap.
Should revisit the buildship env later to see if things can be made to
work.

  was:
An Eclipse-based Edgent runtime development enviroment depends on the 3rd party 
jars currently present in the Edgent repository (the Eclipse .classpath files 
present in the repository depend on them)

Those jars will be removed, replaced by a gradle based build environment, when 
all of the pieces are in place  - EDGENT-139.

This issue is for working towards getting an Eclipse based development 
environment working in the absence of 3rd-party jars in the repo, utilizing the 
integration with gradle to achieve that.


> [gradle] initial work for developing Edgent runtime with gradle in Eclipse
> --
>
> Key: EDGENT-251
> URL: https://issues.apache.org/jira/browse/EDGENT-251
> Project: Edgent
>  Issue Type: Task
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>
> An Eclipse-based Edgent runtime development enviroment depends on the 3rd 
> party jars currently present in the Edgent repository (the Eclipse .classpath 
> files present in the repository depend on them)
> Those jars will be removed, replaced by a gradle based build environment, 
> when all of the pieces are in place  - EDGENT-139.
> Summary: (changes in PR-201)
> - The user must run "./gradlew setupExternalJars" to satisfy the projects' 
> .classpath jar references
> - Read DEVELOPMENT.md - 
> https://github.com/apache/incubator-edgent/blob/master/DEVELOPMENT.md
> Removal of the 3rd party jars from our repo will be covered by a separate 
> issue.
> Note: My initial experience trying to use the Buildship gradle/Eclipse
> integration came up short. The way it created/updated .classpath files
> as a result of the way dependencies are expressed in our build.gradle
> files was problematic. So, I scoped back to the approach here to get to
> the end-goal (removal of dependency of 3rd party jars in the repo) asap.
> Should revisit the buildship env later to see if things can be made to
> work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Heads up: changes to Eclipse based Edgent runtime development environment

[Dale LaBossiere]

I’ve merged EDGENT-251 / PR-201 which changes how Eclipse builds deal with 
references to 3rd-party jars.
When you rebase and pickup commit bd71ad8 your Eclipse based Edgent runtime 
builds will fail until you take the necessary action.
See EDGENT-251 for details: https://issues.apache.org/jira/browse/EDGENT-251 
 

— Dale

[jira] [Created] (EDGENT-257) samples.scenarios.iotp no longer functional

[Dale LaBossiere (JIRA)]

Dale LaBossiere created EDGENT-257:
--

 Summary: samples.scenarios.iotp no longer functional
 Key: EDGENT-257
 URL: https://issues.apache.org/jira/browse/EDGENT-257
 Project: Edgent
  Issue Type: Bug
Reporter: Dale LaBossiere
Assignee: Dale LaBossiere
Priority: Minor


samples/scenarios/iotp/range/sensor/README is inaccurate in light of using a 
gradle tooling generated build as well as an older "iotf" => "iotp" rename.

samples/.classpath also needs tweaking now that the sample is always built and 
the build now includes Pi4J.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] incubator-edgent pull request #203: Edgent-257 cleanup samples/scenarios/iot...

[dlaboss]

GitHub user dlaboss opened a pull request:

https://github.com/apache/incubator-edgent/pull/203

Edgent-257 cleanup samples/scenarios/iotp

See EDGENT-257 for details

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dlaboss/incubator-edgent fixIotpScenarioSample

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-edgent/pull/203.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #203


commit 2cea0dd90af7f75c047b65f680ccd1cba179ed5c
Author: Dale LaBossiere 
Date:   2016-09-30T16:18:38Z

Edgent-257 cleanup samples/scenarios/iotp




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (EDGENT-257) samples.scenarios.iotp no longer functional

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/EDGENT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536386#comment-15536386
 ] 

ASF GitHub Bot commented on EDGENT-257:
---

GitHub user dlaboss opened a pull request:

https://github.com/apache/incubator-edgent/pull/203

Edgent-257 cleanup samples/scenarios/iotp

See EDGENT-257 for details

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dlaboss/incubator-edgent fixIotpScenarioSample

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-edgent/pull/203.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #203


commit 2cea0dd90af7f75c047b65f680ccd1cba179ed5c
Author: Dale LaBossiere 
Date:   2016-09-30T16:18:38Z

Edgent-257 cleanup samples/scenarios/iotp




> samples.scenarios.iotp no longer functional
> ---
>
> Key: EDGENT-257
> URL: https://issues.apache.org/jira/browse/EDGENT-257
> Project: Edgent
>  Issue Type: Bug
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>Priority: Minor
>
> samples/scenarios/iotp/range/sensor/README is inaccurate in light of using a 
> gradle tooling generated build as well as an older "iotf" => "iotp" rename.
> samples/.classpath also needs tweaking now that the sample is always built 
> and the build now includes Pi4J.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] incubator-edgent pull request #204: [gradle] more doc and cleanup

[dlaboss]

GitHub user dlaboss opened a pull request:

https://github.com/apache/incubator-edgent/pull/204

[gradle] more doc and cleanup



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dlaboss/incubator-edgent 
moreGradleDocAndCleanup

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-edgent/pull/204.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #204


commit 7961bb52434177453321c7d7f0e9aa046733920c
Author: Dale LaBossiere 
Date:   2016-09-30T16:09:08Z

[gradle] more doc and cleanup




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (EDGENT-179) console: oplet coloring gradients "too close"

[Queenie Ma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EDGENT-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Queenie Ma resolved EDGENT-179.
---
Resolution: Fixed

> console: oplet coloring gradients "too close"
> -
>
> Key: EDGENT-179
> URL: https://issues.apache.org/jira/browse/EDGENT-179
> Project: Edgent
>  Issue Type: Bug
>  Components: Console
>Reporter: Dale LaBossiere
>Assignee: Queenie Ma
>Priority: Minor
> Attachments: EDGENT-179_oplet_colors.png, Screen Shot 2016-09-19 at 
> 2.22.00 PM.png
>
>
> The oplet color generator ends up yielding two light purple-ish colors for 
> two different kinds of (adjacent) oplets and one can't tell them apart.  One 
> is a Sink the other is a subtype of Peek - a StreamScope.
> I was seeing this in a ParallelBalancedRecipe app of mine.  I can provide it 
> if really necessary to repro/improve this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (EDGENT-178) console: stream hover should report "alias" in addition to tags; maybe oplet hover too

[Queenie Ma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EDGENT-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Queenie Ma resolved EDGENT-178.
---
Resolution: Resolved

> console: stream hover should report "alias" in addition to tags; maybe oplet 
> hover too
> --
>
> Key: EDGENT-178
> URL: https://issues.apache.org/jira/browse/EDGENT-178
> Project: Edgent
>  Issue Type: Improvement
>  Components: Console
>Reporter: Dale LaBossiere
>Assignee: Queenie Ma
>Priority: Minor
>  Labels: newbie
> Attachments: alias_stream_hover.png, oplet_hover.png, 
> oplet_hover2.png, oplet_properties.png
>
>
> TStream.alias("someAlias") manifests itself in graph.Connector similar to 
> tags. I'm pretty sure the graph json captures the alias already.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] incubator-edgent pull request #204: [gradle] more doc and cleanup

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-edgent/pull/204


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (EDGENT-257) samples.scenarios.iotp no longer functional

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/EDGENT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536619#comment-15536619
 ] 

ASF GitHub Bot commented on EDGENT-257:
---

Github user dlaboss closed the pull request at:

https://github.com/apache/incubator-edgent/pull/203


> samples.scenarios.iotp no longer functional
> ---
>
> Key: EDGENT-257
> URL: https://issues.apache.org/jira/browse/EDGENT-257
> Project: Edgent
>  Issue Type: Bug
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>Priority: Minor
>
> samples/scenarios/iotp/range/sensor/README is inaccurate in light of using a 
> gradle tooling generated build as well as an older "iotf" => "iotp" rename.
> samples/.classpath also needs tweaking now that the sample is always built 
> and the build now includes Pi4J.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] incubator-edgent pull request #203: Edgent-257 cleanup samples/scenarios/iot...

[dlaboss]

Github user dlaboss closed the pull request at:

https://github.com/apache/incubator-edgent/pull/203


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (EDGENT-258) testMultiTopologyPollWithError failure; CME in TrackingScheduledExecutor.cancelAllAsyncTasks()

[Dale LaBossiere (JIRA)]

Dale LaBossiere created EDGENT-258:
--

 Summary: testMultiTopologyPollWithError failure; CME in 
TrackingScheduledExecutor.cancelAllAsyncTasks()
 Key: EDGENT-258
 URL: https://issues.apache.org/jira/browse/EDGENT-258
 Project: Edgent
  Issue Type: Bug
  Components: Runtime, Test
Reporter: Dale LaBossiere


This happened in an (ant) travis-ci run.

The DirectTStreamTest.testMultiTopologyPollWithError() test failed with a 
CancellationException (end of the traces below).  Perhaps that was fallout from 
a CME reported within TrackingScheduledExecutor.cancelAllAsyncTasks() on the 
iteration of asyncTasks @ TrackingScheduledExecutor:121 which is the line:
for (RunnableScheduledFuture task : asyncTasks) {

(there's also an InterruptedException below)

But I don't see how that CME can happen.  asyncTasks is a (private) 
SynchronizedSet and all iteration on it in TrackingScheduledExecutor does the 
required "synchronized(asyncTasks) { iterate... }" pattern.  The 
SynchronizedSet methods all synchronize on the SynchronizedSet object 
(asyncTasks) too so 
an operation like add() or remove() can't occur during that synchronized 
iteration. All access to the underlying set is via the SynchronizedSet.  So how 
can that CME happen???

The only possible non-CME-inducing flaw I see is in removeTrack() where there's 
the non-synchronized sequential access:
asyncTasks.remove();
if (asyncTasks.isEmpty() ...   // hence may not reflect state following 
preceeding remove()

Note, there should normally only be 4 instances reporting "Expected Test 
Exception" but there a 8 (maybe due to removeTrack()?).  Trust me, they're all 
from this test method execution.  I've triple checked :-)

I'm also confused a bit by the thread pool/thread ids reported on those 8 
instances.  Would have expected them to all be associated with the test's 
allocated fixed thread pool and would have expected that to have a single pool 
with 4 thread.  But that doesn't seem to be the case?

Here's the various msgs from the test's execution.  Maybe someone else can 
figure it out.

[junit] Sep 30, 2016 4:37:46 PM 
org.apache.edgent.runtime.etiao.TrackingScheduledExecutor afterExecute
[junit] SEVERE: Thread: 
pool-5-thread-7-0a765e86-37c1-4299-9655-118420e3f1be: task terminated with 
exception : 
[junit] java.lang.RuntimeException: java.lang.RuntimeException: Expected 
Test Exception
[junit] at 
org.apache.edgent.oplet.core.PeriodicSource.run(PeriodicSource.java:83)
[junit] at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[junit] at 
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
[junit] at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
[junit] at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
[junit] at 
org.apache.edgent.runtime.etiao.TrackingScheduledExecutor$TrackedFuture.run(TrackingScheduledExecutor.java:205)
[junit] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit] at 
org.apache.edgent.runtime.etiao.ThreadFactoryTracker$2.run(ThreadFactoryTracker.java:87)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit] Caused by: java.lang.RuntimeException: Expected Test Exception
[junit] at 
org.apache.edgent.test.topology.TStreamTest.lambda$null$5f279479$1(TStreamTest.java:774)
[junit] at 
org.apache.edgent.test.topology.TStreamTest$$Lambda$8/2070622949.accept(Unknown 
Source)
[junit] at 
org.apache.edgent.function.Functions$ThreadSafeConsumer.accept(Functions.java:204)
[junit] at 
org.apache.edgent.runtime.etiao.SettableForwarder.accept(SettableForwarder.java:54)
[junit] at org.apache.edgent.oplet.core.FanOut.accept(FanOut.java:50)
[junit] at 
org.apache.edgent.runtime.etiao.SettableForwarder.accept(SettableForwarder.java:54)
[junit] at org.apache.edgent.oplet.core.Source.submit(Source.java:47)
[junit] at 
org.apache.edgent.oplet.functional.SupplierPeriodicSource.fetchTuples(SupplierPeriodicSource.java:52)
[junit] at 
org.apache.edgent.oplet.core.PeriodicSource.run(PeriodicSource.java:81)
[junit] ... 9 more



   [junit] Sep 30, 2016 4:37:46 PM 
org.apache.edgent.runtime.etiao.ThreadFactoryTracker 
trackedThreadUncaughtException
[junit] SEVERE: Uncaught exception in thread 
pool-5-thread-7-0a765e86-37c1-4299-9655-118420e3f1be
[junit] java.util.ConcurrentModificationException
[junit] at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
[junit] at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
   

[jira] [Updated] (EDGENT-258) testMultiTopologyPollWithError failure; CME in TrackingScheduledExecutor.cancelAllAsyncTasks()

[Dale LaBossiere (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EDGENT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale LaBossiere updated EDGENT-258:
---
Description: 
This happened in an (ant) travis-ci run.

The DirectTStreamTest.testMultiTopologyPollWithError() test failed with a 
CancellationException (end of the traces below).  Perhaps that was fallout from 
a CME reported within TrackingScheduledExecutor.cancelAllAsyncTasks() on the 
iteration of asyncTasks @ TrackingScheduledExecutor:121 which is the line:
for (RunnableScheduledFuture task : asyncTasks) {

(there's also an InterruptedException below)

But I don't see how that CME can happen.  asyncTasks is a (private) 
SynchronizedSet and all iteration on it in TrackingScheduledExecutor does the 
required "synchronized(asyncTasks) { iterate... }" pattern.  The 
SynchronizedSet methods all synchronize on the SynchronizedSet object 
(asyncTasks) too so 
an operation like add() or remove() can't occur during that synchronized 
iteration. All access to the underlying set is via the SynchronizedSet.  So how 
can that CME happen???

The only possible non-CME-inducing flaw I see is in removeTrack() where there's 
the non-synchronized sequential access:
asyncTasks.remove();
if (asyncTasks.isEmpty() ...   // hence may not reflect state following 
preceeding remove()

Note, there should normally only be 4 instances reporting "Expected Test 
Exception" but there a 8 (maybe due to removeTrack()?).  Trust me, they're all 
from this test method execution.  I've triple checked :-)

I'm also confused a bit by the thread pool/thread ids reported on those 8 
instances.  Would have expected them to all be associated with the test's 
allocated fixed thread pool and would have expected that to have a single pool 
with 4 thread.  But that doesn't seem to be the case?

Here's the various msgs from the test's execution.  Maybe someone else can 
figure it out.  From 
https://travis-ci.org/apache/incubator-edgent/builds/164076026

[junit] Sep 30, 2016 4:37:46 PM 
org.apache.edgent.runtime.etiao.TrackingScheduledExecutor afterExecute
[junit] SEVERE: Thread: 
pool-5-thread-7-0a765e86-37c1-4299-9655-118420e3f1be: task terminated with 
exception : 
[junit] java.lang.RuntimeException: java.lang.RuntimeException: Expected 
Test Exception
[junit] at 
org.apache.edgent.oplet.core.PeriodicSource.run(PeriodicSource.java:83)
[junit] at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[junit] at 
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
[junit] at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
[junit] at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
[junit] at 
org.apache.edgent.runtime.etiao.TrackingScheduledExecutor$TrackedFuture.run(TrackingScheduledExecutor.java:205)
[junit] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit] at 
org.apache.edgent.runtime.etiao.ThreadFactoryTracker$2.run(ThreadFactoryTracker.java:87)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit] Caused by: java.lang.RuntimeException: Expected Test Exception
[junit] at 
org.apache.edgent.test.topology.TStreamTest.lambda$null$5f279479$1(TStreamTest.java:774)
[junit] at 
org.apache.edgent.test.topology.TStreamTest$$Lambda$8/2070622949.accept(Unknown 
Source)
[junit] at 
org.apache.edgent.function.Functions$ThreadSafeConsumer.accept(Functions.java:204)
[junit] at 
org.apache.edgent.runtime.etiao.SettableForwarder.accept(SettableForwarder.java:54)
[junit] at org.apache.edgent.oplet.core.FanOut.accept(FanOut.java:50)
[junit] at 
org.apache.edgent.runtime.etiao.SettableForwarder.accept(SettableForwarder.java:54)
[junit] at org.apache.edgent.oplet.core.Source.submit(Source.java:47)
[junit] at 
org.apache.edgent.oplet.functional.SupplierPeriodicSource.fetchTuples(SupplierPeriodicSource.java:52)
[junit] at 
org.apache.edgent.oplet.core.PeriodicSource.run(PeriodicSource.java:81)
[junit] ... 9 more



   [junit] Sep 30, 2016 4:37:46 PM 
org.apache.edgent.runtime.etiao.ThreadFactoryTracker 
trackedThreadUncaughtException
[junit] SEVERE: Uncaught exception in thread 
pool-5-thread-7-0a765e86-37c1-4299-9655-118420e3f1be
[junit] java.util.ConcurrentModificationException
[junit] at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
[junit] at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
[junit] at 
org.apache.edgent.runtime.etiao.TrackingScheduledExecutor.cancelAllAsyncTasks(TrackingScheduledExecutor.java:121)
[junit

[GitHub] incubator-edgent pull request #203: Edgent-257 cleanup samples/scenarios/iot...

[dlaboss]

GitHub user dlaboss reopened a pull request:

https://github.com/apache/incubator-edgent/pull/203

Edgent-257 cleanup samples/scenarios/iotp

See EDGENT-257 for details

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dlaboss/incubator-edgent fixIotpScenarioSample

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-edgent/pull/203.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #203


commit 2cea0dd90af7f75c047b65f680ccd1cba179ed5c
Author: Dale LaBossiere 
Date:   2016-09-30T16:18:38Z

Edgent-257 cleanup samples/scenarios/iotp

commit 7677cbb63c7a5f955cb5d047a87558dd49b62df0
Author: Dale LaBossiere 
Date:   2016-09-30T16:33:50Z

[ci-skip] address incorrect developerworks link




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (EDGENT-257) samples.scenarios.iotp no longer functional

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/EDGENT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536916#comment-15536916
 ] 

ASF GitHub Bot commented on EDGENT-257:
---

GitHub user dlaboss reopened a pull request:

https://github.com/apache/incubator-edgent/pull/203

Edgent-257 cleanup samples/scenarios/iotp

See EDGENT-257 for details

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dlaboss/incubator-edgent fixIotpScenarioSample

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-edgent/pull/203.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #203


commit 2cea0dd90af7f75c047b65f680ccd1cba179ed5c
Author: Dale LaBossiere 
Date:   2016-09-30T16:18:38Z

Edgent-257 cleanup samples/scenarios/iotp

commit 7677cbb63c7a5f955cb5d047a87558dd49b62df0
Author: Dale LaBossiere 
Date:   2016-09-30T16:33:50Z

[ci-skip] address incorrect developerworks link




> samples.scenarios.iotp no longer functional
> ---
>
> Key: EDGENT-257
> URL: https://issues.apache.org/jira/browse/EDGENT-257
> Project: Edgent
>  Issue Type: Bug
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>Priority: Minor
>
> samples/scenarios/iotp/range/sensor/README is inaccurate in light of using a 
> gradle tooling generated build as well as an older "iotf" => "iotp" rename.
> samples/.classpath also needs tweaking now that the sample is always built 
> and the build now includes Pi4J.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (EDGENT-256) keyedTimeBatchWindowTest got a CME

[Dale LaBossiere (JIRA)]

[ 
https://issues.apache.org/jira/browse/EDGENT-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15537164#comment-15537164
 ] 

Dale LaBossiere commented on EDGENT-256:


hit again today

> keyedTimeBatchWindowTest got a CME
> --
>
> Key: EDGENT-256
> URL: https://issues.apache.org/jira/browse/EDGENT-256
> Project: Edgent
>  Issue Type: Test
>Reporter: Dale LaBossiere
>Priority: Minor
>
> The keyedTimeBatchWindowTest got a CME (vintage 2016-09-28 code) in a 
> travis-ci build.
> Note an earlier PR-172 related to this test: 
> https://github.com/apache/incubator-edgent/pull/172
> Below, line 425 refers to:
>   assertTrue("Values:" + batch.toString(), 
> withinTolerance(1000.0, l.doubleValue(), tolerance));
> Perhaps a wait or delay is needed following the sf.cancel(true)?
> [junit] Testcase: 
> keyedTimeBatchWindowTest(org.apache.edgent.test.window.WindowTest): 
> Caused an ERROR
> [junit] null
> [junit] java.util.ConcurrentModificationException
> [junit]   at 
> java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:966)
> [junit]   at java.util.LinkedList$ListItr.next(LinkedList.java:888)
> [junit]   at 
> java.util.AbstractCollection.toString(AbstractCollection.java:461)
> [junit]   at 
> org.apache.edgent.test.window.WindowTest.keyedTimeBatchWindowTest(WindowTest.java:425)
> [junit] 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] incubator-edgent pull request #203: Edgent-257 cleanup samples/scenarios/iot...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-edgent/pull/203


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (EDGENT-257) samples.scenarios.iotp no longer functional

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/EDGENT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15537168#comment-15537168
 ] 

ASF GitHub Bot commented on EDGENT-257:
---

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-edgent/pull/203


> samples.scenarios.iotp no longer functional
> ---
>
> Key: EDGENT-257
> URL: https://issues.apache.org/jira/browse/EDGENT-257
> Project: Edgent
>  Issue Type: Bug
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>Priority: Minor
>
> samples/scenarios/iotp/range/sensor/README is inaccurate in light of using a 
> gradle tooling generated build as well as an older "iotf" => "iotp" rename.
> samples/.classpath also needs tweaking now that the sample is always built 
> and the build now includes Pi4J.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (EDGENT-257) samples.scenarios.iotp no longer functional

[Dale LaBossiere (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EDGENT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale LaBossiere resolved EDGENT-257.

Resolution: Fixed

addressed with PR-203

> samples.scenarios.iotp no longer functional
> ---
>
> Key: EDGENT-257
> URL: https://issues.apache.org/jira/browse/EDGENT-257
> Project: Edgent
>  Issue Type: Bug
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>Priority: Minor
>
> samples/scenarios/iotp/range/sensor/README is inaccurate in light of using a 
> gradle tooling generated build as well as an older "iotf" => "iotp" rename.
> samples/.classpath also needs tweaking now that the sample is always built 
> and the build now includes Pi4J.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)