Is device.commands(new String[0]) the blocking call here?

I commented out all code except the following:
1)  simulated sensor to generate data
2)  send to iotf
3)  a device.commands(new String[0]) call to receive command - I am not
doing anything with the command.

If I have this device.commands call in the topology, then it hangs.

On Fri, Apr 8, 2016 at 5:36 PM, Daniel John Debrunner (JIRA) <
[email protected]> wrote:

>
>     [
> https://issues.apache.org/jira/browse/QUARKS-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15233000#comment-15233000
> ]
>
> Daniel John Debrunner commented on QUARKS-130:
> ----------------------------------------------
>
> Each topology has a Java thread pool, around line 65 of
> TrackingScheduledExecutor is is created. You could try changing the 4 to
> something higher.
>
> If that fixes it, it most likely means that something that is using the
> thread pool, which is really an executor is trying to execute a task that
> blocks, which is not good practice.
>
> > Application hangs when trying to read commands from iotf
> > --------------------------------------------------------
> >
> >                 Key: QUARKS-130
> >                 URL: https://issues.apache.org/jira/browse/QUARKS-130
> >             Project: Quarks
> >          Issue Type: Bug
> >          Components: Runtime
> >    Affects Versions: 0.4.0
> >         Environment: RaspberryPi 2
> >            Reporter: Samantha Chan
> >
> > In my application, I have this:
> >      IotDevice device =  new IotfDevice(topology, new
> File("./device.cfg"));
> >
> >  TStream<JsonObject> json = dry.map(v -> {
> >               Reading reading = new Reading(v, soil.isSprinklerOn());
> >               return reading.toJsonObject();
> >         });
> >
> >         device.events(json, "waterRequest", QoS.FIRE_AND_FORGET);
> >
> >         // receive commands from IotF
> >        TStream<JsonObject> responses = device.commands(new String[0]);
> >        responses.print();
> >
> > This application runs fine on my macbook.  But the same code cannot be
> run on Raspberry Pi.
> > The application seems to just hang.
> > If I comment out the call `device.command`, the application will run.
> > Here's the java log for the hanging application:
> > Full thread dump Java HotSpot(TM) Client VM (25.65-b01 mixed mode):
> > "pool-1-thread-21-1c8392d5-ef47-402c-8a81-71dec0a61598_JOB_0" #28 prio=5
> os_prio=0 tid=0x00893400 nid=0xddb waiting on condition [0x63d4e000]
> >    java.lang.Thread.State: TIMED_WAITING (sleeping)
> >       at java.lang.Thread.sleep(Native Method)
> >       at quarks.oplet.functional.Events.lambda$start$0(Events.java:56)
> >       at quarks.oplet.functional.Events$$Lambda$23/20593183.run(Unknown
> Source)
> >       at
> quarks.runtime.etiao.ThreadFactoryTracker$2.run(ThreadFactoryTracker.java:70)
> >       at java.lang.Thread.run(Thread.java:745)
> >       at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> >       at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >       at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> >       at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> >       at
> quarks.runtime.etiao.TrackingScheduledExecutor$TrackedFuture.run(TrackingScheduledExecutor.java:188)
> >       at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> >       at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> >       at
> quarks.runtime.etiao.ThreadFactoryTracker$2.run(ThreadFactoryTracker.java:70)
> >       at java.lang.Thread.run(Thread.java:745)
> > "pool-1-thread-13-1c8392d5-ef47-402c-8a81-71dec0a61598_JOB_0" #20 prio=5
> os_prio=0 tid=0x6451e000 nid=0xdda waiting on condition [0x63d9e000]
> >    java.lang.Thread.State: WAITING (parking)
> >       at sun.misc.Unsafe.park(Native Method)
> >       - parking to wait for  <0x6a6b6cf8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> >       at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> >       at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> >       at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> >       at quarks.oplet.plumbing.Isolate.run(Isolate.java:54)
> >       at
> quarks.runtime.etiao.ThreadFactoryTracker$2.run(ThreadFactoryTracker.java:70)
> >       at java.lang.Thread.run(Thread.java:745)
> > "DestroyJavaVM" #8 prio=5 os_prio=0 tid=0x76107800 nid=0xdc0 waiting on
> condition [0x00000000]
> >    java.lang.Thread.State: RUNNABLE
> > "Service Thread" #6 daemon prio=9 os_prio=0 tid=0x76182c00 nid=0xdc6
> runnable [0x00000000]
> >    java.lang.Thread.State: RUNNABLE
> > "C1 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x7617f800 nid=0xdc5
> waiting on condition [0x00000000]
> >    java.lang.Thread.State: RUNNABLE
> > "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x7617e000 nid=0xdc4
> waiting on condition [0x00000000]
> >    java.lang.Thread.State: RUNNABLE
> > "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x76162800 nid=0xdc3 in
> Object.wait() [0x64f9d000]
> >    java.lang.Thread.State: WAITING (on object monitor)
> >       at java.lang.Object.wait(Native Method)
> >       - waiting on <0x6a5f4480> (a java.lang.ref.ReferenceQueue$Lock)
> >       at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> >       - locked <0x6a5f4480> (a java.lang.ref.ReferenceQueue$Lock)
> >       at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> >       at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
> > "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x76161000 nid=0xdc2
> in Object.wait() [0x64fed000]
> >    java.lang.Thread.State: WAITING (on object monitor)
> >       at java.lang.Object.wait(Native Method)
> >       - waiting on <0x6a5f4620> (a java.lang.ref.Reference$Lock)
> >       at java.lang.Object.wait(Object.java:502)
> >       at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
> >       - locked <0x6a5f4620> (a java.lang.ref.Reference$Lock)
> > "VM Thread" os_prio=0 tid=0x7615dc00 nid=0xdc1 runnable
> > "VM Periodic Task Thread" os_prio=0 tid=0x76184c00 nid=0xdc7 waiting on
> condition
> > JNI global references: 330
> > Heap
> >  def new generation   total 4864K, used 4260K [0x65800000, 0x65d40000,
> 0x6a540000)
> >   eden space 4352K,  86% used [0x65800000, 0x65ba9158, 0x65c40000)
> >   from space 512K,  99% used [0x65cc0000, 0x65d3ffe8, 0x65d40000)
> >   to   space 512K,   0% used [0x65c40000, 0x65c40000, 0x65cc0000)
> >  tenured generation   total 11008K, used 3407K [0x6a540000, 0x6b000000,
> 0x74000000)
> >    the space 11008K,  30% used [0x6a540000, 0x6a893d18, 0x6a893e00,
> 0x6b000000)
> >  Metaspace       used 6095K, capacity 6329K, committed 6424K, reserved
> 6448K
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Reply via email to