You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/ISSUE_TEMPLATE/bug-report.yml
+2-1Lines changed: 2 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -39,10 +39,11 @@ body:
39
39
required: true
40
40
attributes:
41
41
label: In which mode are you using the docker container?
42
-
description: If you have `USE_NATIVE=1` set in your `docker-compose.yml` filethen you are using the native mode.
42
+
description: Please have a look at the `MODE` parameter in you `docker-compose.yml` file. If you do not have the `MODE` parameter explicitly set, then you are running in normal mode.
Copy file name to clipboardExpand all lines: README.md
+36-17Lines changed: 36 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,41 @@ At the moment, the following functionality is exposed via REST:
15
15
16
16
and [many more](https://bbernhard.github.io/signal-cli-rest-api/)
17
17
18
-
## Examples
18
+
## Modes
19
+
20
+
The `signal-cli-rest-api` supports three different modes:
21
+
22
+
* Normal Mode: In normal mode, the `signal-cli` executable is invoked for every REST API request. As `signal-cli` is a Java application, a significant amount of time is spent in the JVM (Java Virtual Machine) startup - which makes this mode pretty slow.
23
+
* Native Mode: Instead of calling a Java executable for every REST API request, a native image (compiled with GraalVM) is called. This mode therefore usually performs better than the normal mode.
24
+
* JSON-RPC Mode: In JSON-RPC mode, a single `signal-cli` instance is spawned in daemon mode. The communication happens via JSON-RPC. This mode is usually the fastest.
1. If the signal-cli-rest-api docker container is started on an armv7 system in native mode, it automatically falls back to the normal mode.
43
+
44
+
## Auto Receive Schedule
45
+
46
+
> :warning: This setting is only needed in normal/native mode!
47
+
48
+
[signal-cli](https://github.com/AsamK/signal-cli), which this REST API wrapper is based on, recommends to call `receive` on a regular basis. So, if you are not already calling the `receive` endpoint regularily, it is recommended to set the `AUTO_RECEIVE_SCHEDULE` parameter in the docker-compose.yml file. The `AUTO_RECEIVE_SCHEDULE` accepts cron schedule expressions and automatically calls the `receive` endpoint at the given time. e.g: `0 22 * * *` calls `receive` daily at 10pm. If you are not familiar with cron schedule expressions, you can use this [website](https://crontab.guru).
49
+
50
+
**WARNING** Calling `receive` will fetch all the messages for the registered Signal number from the Signal Server! So, if you are using the REST API for receiving messages, it's _not_ a good idea to use the `AUTO_RECEIVE_SCHEDULE` parameter, as you might lose some messages that way.
51
+
52
+
## Example
19
53
20
54
Sample `docker-compose.yml`file:
21
55
@@ -25,7 +59,7 @@ services:
25
59
signal-cli-rest-api:
26
60
image: bbernhard/signal-cli-rest-api:latest
27
61
environment:
28
-
- USE_NATIVE=0
62
+
- MODE=normal #supported modes: json-rpc, native, normal
29
63
#- AUTO_RECEIVE_SCHEDULE=0 22 * * * #enable this parameter on demand (see description below)
30
64
ports:
31
65
- "8080:8080"#map docker port 8080 to host port 8080.
@@ -34,21 +68,6 @@ services:
34
68
35
69
```
36
70
37
-
## Auto Receive Schedule
38
-
39
-
[signal-cli](https://github.com/AsamK/signal-cli), which this REST API wrapper is based on, recommends to call `receive` on a regular basis. So, if you are not already calling the `receive` endpoint regularily, it is recommended to set the `AUTO_RECEIVE_SCHEDULE` parameter in the docker-compose.yml file. The `AUTO_RECEIVE_SCHEDULE` accepts cron schedule expressions and automatically calls the `receive` endpoint at the given time. e.g: `0 22 * * *` calls `receive` daily at 10pm. If you are not familiar with cron schedule expressions, you can use this [website](https://crontab.guru).
40
-
41
-
**WARNING** Calling `receive` will fetch all the messages for the registered Signal number from the Signal Server! So, if you are using the REST API for receiving messages, it's _not_ a good idea to use the `AUTO_RECEIVE_SCHEDULE` parameter, as you might lose some messages that way.
42
-
43
-
44
-
## Native Image (EXPERIMENTAL)
45
-
46
-
On Systems like the Raspberry Pi, some operations like sending messages can take quite a while. That's because signal-cli is a Java application and a significant amount of time is spent in the JVM (Java Virtual Machine) startup. signal-cli recently added the possibility to compile the Java application to a native binary (done via GraalVM).
47
-
48
-
By adding `USE_NATIVE=1` as environmental variable to the `docker-compose.yml` file the native mode will be enabled.
49
-
50
-
In case there's no native binary available (e.g on a 32 bit Raspian OS), it will fall back to the signal-cli Java application. The native mode only works on a 64bit system, when the native mode is enabled on a 32bit system, it falls back to the Java application.
0 commit comments