Hi Megabyzus,

1.a There is no limit to the number of subscriptions a LightstreamerClient object can request.
Obviously considerations regarding the performance of the client application must also be taken into account; but in this case more than the number of subscriptions the metric to consider is the total input throughput that the application can sustain.

1.b There are many good reasons to prefer multiple subscriptions over a single subscription request, and in some cases it is just mandatory to have multiple ones.
For example, if the Items you subscribe to are provided by different Data Adapters it is necessary to use different subscriptions since the Data Adapter is a unique element for the subscription object.
Even if the Items come from the same Data Adapter but require different subscription modes (MERGE, DISTINCT, COMMAND or RAW) then you have to use different subscriptions.
However, even if your case is not one of the above, there are very good reasons to still prefer different subscriptions:
- with multiple subscriptions you can dynamically subscribe and unsubscribe groups of Items, since your application does not necessarily need all the data at all times.
Think about an application managed in pages, when the user changes page you can dynamically unsubscribe the Items necessary for the old page and subscribe those necessary for the new one.
- Groups of Items need different operating parameters, for example some Items you want to receive them with a frequency of 2 updates per second others with an update every 10 seconds, this is possible by setting a different max frequency for the two different subscriptions.

1.c As I said before (point 1.a) from the client's point of view it doesn't change much, what matters is the total inbound throughput of all subscriptions. Especially considering the websocket transport making a request to the server for the client is very inexpensive.
As for the server, on the other hand, the number of requests to handle can become a potential load problem.
But you should consider the total load of the server in terms of number of clients, number of requests from the client, frequency of these requests and total outbound throughput. All this compared with the hw characteristics of the server.

2.a The correct sequence is:
1. call the unsubscribe method of the LightstreamerClient for the original subscription object
2. wait inactive state for the subscription
3. made all the changes you need (setItems, setFields, ... )
4.call subscribe method of the LightstreamerClient

2.b In a scenario like the one described I would opt to have two separate subscriptions, then leave the first subscription unchanged and create a new one for module 2.
Please consider that having multiple subscriptions is absolutely normal for real-world client applications.
Indeed, the scenario with a single subscription applies only in extreme cases where the application needs a fairly limited set of Items always with the same characteristics and for the entire duration of the life cycle.

1.d The recommended approach is a trade off which depends a lot on the type and the specifics of the application.
However let me point out that you don't have to be too hesitant to have more subscriptions, it is absolutely normal to have a decent number of subscriptions for a client.
You should only worry if the number of subscriptions is high, much higher than ten per client, and especially if the frequency with which a client requests subscriptions and unsubcriptions is very high.

Regards,
Giuseppe