APAPE
Members-
Content Count
7 -
Joined
-
Last visited
Everything posted by APAPE
-
Hi I do not know, what's going wrong and why. Using the TIcsMqttClient component, it is not possible for me to send any payload. When I debug the code, i found out, that in procedure TCustomWSocket.TryToSend in line 7365 -> Count := RealSend(Data, Len); the return value (count) is always: -1 I am using V9 beta 3, but tried it also with 9.2 Thx for helping
-
TIcsMQTTClient.Publish does nothing for me.
APAPE replied to APAPE's topic in ICS - Internet Component Suite
Yes, MQTT is working, as long as https://test.mosquitto.org/ is not used. It would be great if the ICS MQTT client would work with Mosquitto MQTT server also. Thx. -
TIcsMQTTClient.Publish does nothing for me.
APAPE replied to APAPE's topic in ICS - Internet Component Suite
No, I did not build / used the OverbyteIcsMQTTst sample. But now I did 🙂. With it I found out, that using the "https://test.mosquitto.org/" it can be connected, but the client (sample application) does not get "online". Regardless, which port I use (?). Then I tried "public.mqtthq.com". Here it connected and went online. But sending or receiving messages did not work for me. Then I tried "broker.emqx.io". Connection worked fine, but sending or receiving messages also did not work. Same with "mqtt.eclipseprojects.io". That was curios! After playing a little bit with the topic names for sending and receiving message, I found out, that these public MQTT Server accept all topics, but only send the messages when the topic is not longer than 14 characters. I did not find any hint for that behavior on there web sites. After rethinking about it, it's clear why. The reason why using Mosquitto does not let the sample application go online with the TIcsMQTTClient component / ICS Library, I have no idea. But yesterday I used only this MQTT broker and wondered why I could not send or receive any message. Thank's to the sample application, now it's clear why: not online. Hope, this helps others. Topic can be closed. -
After 2 years :-) there is no answer to the question, if there is an webhook example. I am using Delphi 2007. And now I would like to connect to a server side WebHook (the server should inform me). If the ICS components can not be used for it, how can it be realized in D2007? If ICS can be used, how? Please post an example code here as a starting point, or a link to an example. Thanks
-
I have build a thread (using TIdThread), which can be startet multiple times to get data from different places. Each thread processes accesses one place / Url. I'm using a thread for each place to get the data of each of them totally as quick as possible. So the longest time is just the one which needs the longest time to retrieve the data. I set the property "MultiThreaded" to true in the component. Calling the .Post method does not work. I always get a timeout. If the same code is executed not as a self running thread, it works fine. I did not find any help on the internet. Does anybody knows why this timeout appears and how it can be moved away (so the thread does it's job)? I'm using Delphi 2007 and the main application also uses THttpCli components. Please help. Thx.
-
I have debugged a little bit. In the unit "OverbyteIcsHttpProt" in class "THttpCli" in method "DoRequestSync", and in the while FState <> httpReady do loop the state (FState) is always "httpDnsLookupDone", but does not change any more. I looked a little bit deeper into unit "OverbyteIcsWSocket" into procedure TCustomWSocket.Connect where the method "WSocket_Synchronized_Connect" is being called, and this method returns 10035. I searched again in the internet and found the following site: https://stackoverflow.com/questions/16488603/overbyteics-http-timeout-when-used-in-different-threads And the S O L U T I O N is very simple: DO NOT CREATE THE ICS OBJECTS AT THREAD CREATION TIME, create and destroy them every time you need them in the thread! Hope, this helps to save others time in future
-
I'm using the TIdThread object for many years, because it can be started and stopped without needing to destroy and recreate it. It is very handy. It does not make any difference, if I use a normal "TThread" or "TIdThread" for execution. The THttpCli object always throws an timeout exception and the requested URL is never been called. I do not use Indy for other things. I just use the TIdThread object.