I can't get a Pubnub presence timeout to reliably use the heartbeat value - what am I missing? - pubnub

We have a variety of pubnub clients: javascript, ruby, actionscript
Its important that I know if/when clients leave a channel; even if a browser or desktop application (Native Air app) crashes. I'm updating the ActionScript library to support presence, so I cribbed from the JavaScript and Ruby implementations, I have presence working when everything is behaving nicely, but heartbeat doesn't appear to work in detecting clients that crash in my version.
So, I tried the following in Ruby using irb (gem version 3.6.7):
require 'pubnub'
pn = Pubnub.new(:subscribe_key => 'my_sub_key', :uuid => 'my_uuid', :heartbeat => 30)
pn.subscribe(:channel => 'my_channel') { |d| d.msg }
Then I entered the subscribe_key and channel into the Pubnub console. As expected, my subscription was there.
I exited out of irb and waited. I expected to see a presence timeout at about the 30 second mark, but needed to have to wait the entire 6 minutes before I received the timeout.
Note also: things do appear to work with the Javascript client.
Do I need to turn something else on beyond 'presence' to get this to work as expected, or am I misunderstanding what heartbeat does?

After looking at the difference between what Javascript sets up and Ruby 3.6.7 I noticed that the Ruby heartbeat posts were not passing the heartbeat as a parameter.
When I added the heartbeat parameter to my ActionScript version, it began working as it should.
I'm still puzzled as to why the Ruby gem works for others though.

I just did the same test, using our web console at http://www.pubnub.com/console/?channel=my_channel&origin=pubsub.pubnub.com&sub=demo-36&pub=demo-36 (using the demo keys)
I ran your above code, then CTRL-D out of IRB.
And it works as expected, 30s after:
Fri Oct 31 2014 15:35:38:597 : <my_channel
{"action":"timeout","timestamp":1414794938,"uuid":"my_uuid","occupancy":1}
Fri Oct 31 2014 15:35:08:527 : <my_channel>
{"action":"join","timestamp":1414794908,"uuid":"my_uuid","occupancy":2}
Which version of the gem are you on? I just tested with 3.6.7 from RubyGems.
geremy

Related

Could not get HttpClient cache - No ThreadContext available for thread id=1

I'm working on upgrading our service to use 3.63.0 (upgrading from 3.57.0) and I've noticed the following warning (with stack trace) shows up in the logs that wasn't there on the previous version:
2022-02-18 14:03:41.038 WARN 1088 --- [ main] c.s.c.s.c.c.AbstractHttpClientCache : Could not get HttpClient cache.
com.sap.cloud.sdk.cloudplatform.thread.exception.ThreadContextAccessException: No ThreadContext available for thread id=1.
at com.sap.cloud.sdk.cloudplatform.thread.ThreadLocalThreadContextFacade.lambda$tryGetCurrentContext$0(ThreadLocalThreadContextFacade.java:39) ~[cloudplatform-core-3.63.0.jar:na]
at io.vavr.Value.toTry(Value.java:1414) ~[vavr-0.10.4.jar:na]
at com.sap.cloud.sdk.cloudplatform.thread.ThreadLocalThreadContextFacade.tryGetCurrentContext(ThreadLocalThreadContextFacade.java:37) ~[cloudplatform-core-3.63.0.jar:na]
at io.vavr.control.Try.flatMapTry(Try.java:490) ~[vavr-0.10.4.jar:na]
at io.vavr.control.Try.flatMap(Try.java:472) ~[vavr-0.10.4.jar:na]
at com.sap.cloud.sdk.cloudplatform.thread.ThreadContextAccessor.tryGetCurrentContext(ThreadContextAccessor.java:84) ~[cloudplatform-core-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.RequestScopedHttpClientCache.getCache(RequestScopedHttpClientCache.java:28) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.AbstractHttpClientCache.tryGetOrCreateHttpClient(AbstractHttpClientCache.java:78) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.AbstractHttpClientCache.tryGetHttpClient(AbstractHttpClientCache.java:46) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.HttpClientAccessor.tryGetHttpClient(HttpClientAccessor.java:153) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.HttpClientAccessor.getHttpClient(HttpClientAccessor.java:131) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.octanner.mca.service.MarketingCloudApiContactService.uploadContacts(MarketingCloudApiContactService.java:138) ~[classes/:na]
...
This happens when the following calls are made...
Using the lower level API
HttpClient httpClient = HttpClientAccessor.getHttpClient(destination); // warning happens here
ODataRequestResultMultipartGeneric batchResult = requestBatch.execute(httpClient);
Using the higher level API
service
.getAllContactOriginData()
.withQueryParameter("$expand", "AdditionalIDs")
.top(size)
.filter(filter)
.executeRequest(destination)); // warning happens here
Even though this warning shows up in the logs the service requests do continue to work as expected. It's just a little concerning to see this and I'm wondering if maybe I have something misconfigured. I reviewed all of the java docs and the troubleshooting page and didn't see anything out of the ordinary other than how I am fetching my destination, but even using the DestinationAccessor didn't seem to make a difference. Also, I'm not doing any asynchronous or multi-tenant processing.
Any help you or guidance you can give on this would be appreciated!
Cheers!
Such an issue is often the result of missing Spring Boot annotations - especially in synchronous executions.
Please refer to our documentation to learn more about the SAP Cloud SDK Spring Boot integration.
Edit Feb. 28th 2022
It is safe to ignore the logged warning if your application does not need any of the SAP Cloud SDK's multitenancy features.
Error Cause
The SAP Cloud SDK for Java recently (in version 3.63.0) introduced a change to the thread propagation behavior of the HttpClientCache.
With that change, we also adapted the logging in case the propagation didn't work as expected - this is often caused by not using the ThreadContextExecutor for wrapping asynchronous operations.
This is the reason for logs like the one described by the issue author.
Planned Mitigation
In the meanwhile, we realized that these WARN logs are causing confusion on the consumer side.
We are working on improving the situation by degrading the log level to INFO for the message and to DEBUG for the exception.

Problem with DocuSign Signature appliances DSA Rest Examples

I want to integrate automatic digital signature capabilities in my application. I signed-up for DocuSign sandbox account and tried to build and run example code from https://github.com/docusign/docusign-signature-appliance-api-recipes/tree/master/dsa-rest/Hello-World-examples
While running java hello-world example I am getting error as
Feb 09, 2021 9:01:00 AM org.apache.http.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://prime-dsa-devctr.docusign.net:8081: Connection reset by peer: socket write error
Feb 09, 2021 9:01:00 AM org.apache.http.impl.execchain.RetryExec execute
I tried running C# code also , but get similar error in calling REST Endpoint "https://prime-dsa-devctr.docusign.net:8081/sapiws/v1/digital_signature"
The underlying connection was closed: An unexpected error occurred on a receive
am I missing something here? I tried changing user credential used in code, but still error does not change.
Update: the issue should be resolved now.
The DSA team is working on this, this is not your issue. It's down at least when I'm typing this answer. I'll update it as soon as it's back up.

visual studio code - debugging with inspector protocol

I have been using VS code for a bit and suddenly, today, it starter to behave strangely when I debug...
in the debug condole it says
Debugging with inspector protocol because Node.js v8.9.1 was detected.
node --inspect-brk=3193 app.js
Debugger listening on ws://127.0.0.1:3193/c89636e0-f77a-40ab-9046-da1ddaaaf31c
and is keep stopping and looping on a specific function without me having put any breakpoint:
function createScript(code, options) {
return new Script(code, options);
}
I don't know if I have deleted or modified by mistake anything.....
interesting enough if I run the code in the console, it runs without trowing errors... while with the debug it seems I cannot finish the debugging (keep looping)...
I noticed in the debug console the message above.... not sure if that is normal....
any suggestion???
thanks all
Msg told you two things
First one is informational, tells you what protocol it's going with. Inspector is the latest and default protocol.
Second one looping on createScript is a problem. Is it from your own file or a package file?

Using memcached failover servers in nodejs app

I'm trying to set up a robust memcached configuration for a nodejs app with the node-memcached driver, but it does not seem to use the specified failover servers when one server dies.
My local experiment goes as follows:
shell
memcached -p 11212
node
MC = require('memcached')
c = new MC('localhost:11211', //this process does not exist
{failOverServers: ['localhost:11212']})
c.get('foo', console.log) //this will eventually time out
c.get('foo', console.log) //repeat 5 or 6 times to exceed the retries number
//wait until all the connection errors appear in the console
//at this point, the failover server should be in use
c.get('foo', console.log) //this still times out :(
Any ideas of what might we be doing wrong?
It seems that the failover feature is somewhat buggy in node-memcached.
To enable failover you must set the remove options:
c = new MC('localhost:11211', //this process does not exist
{failOverServers: ['localhost:11212'],
remove : true})
Unfortunately, this is not going to work because of the following error:
[depricated] HashRing#replaceServer is removed.
[depricated] the API has no replacement
That is, when trying to replace a dead server with a replacement from the failover list, node-memcached outputs a deprecation error from the HashRing library (which, in turn, is maintained by the same author of node-memcached). IMHO, feel free to open a bug :-)
This is come when your nodejs server not getting any session id from memcached
Please check properly in php.ini file you are setting properly or not for memcached
session.save = 'memcache'
session.path = 'tcp://localhost:11212'

xpages error message: unknown resource ID

How do I go about beginning to even trouble shoot this error message:
[1920:000F-1C08] 25/03/2014 04:53:08 PM HTTP JVM: !warn.DojoDependencyList.Internalerrorunknownresourceid0!
Background: xpages form developed in 8.5 and ran perfectly last year, now using the exact form again, but that error message appears in Domino server console when you load the page and when you attempt to submit it (it won't submit.)
The only thing obviously thing that has changed in the picture here in the past year is that the server has been upgraded to domino 9.02 fp 2.
Any ideas on how to even start pinning down what's up gratefully received, I'm sure it's something small and non-obvious.
Domino 9.0 uses Dojo 1.8 so my guess is there's an issue/conflict with your app and its use of Dojo.
Try forcing your app to use Dojo 1.6.1 by setting xsp.client.script.dojo.version to 1.6.1 in xsp.properties.

Resources