i’m using cometVisu to visualise my items. Since there are a lot oh items accessible in cometVisu, the requests to poll for updates are rather large. I’m hitting the 8192 request header size limit. In OH1 i was able to adjust that limit in jetty.xml, however this no longer seems to be possible in oh2.
The jetty.xml shipping with the official docker already contains a “requestHeaderSize” value, changing it however doesn’t have any impact. I’m still hitting the 8192 default limit.
Any guidance how to properly override this setting?
Why don’t you read up on pax-web then, which is the web server used in Karaf? There is nothing special in the OH2 distro, what is not pax-web/karaf standard.
@joltcoke For cometvisu the problem is that it subscribes to events for items with concatenating it’s names to one url. Therefore, you simly reach this limit.
The better way may be to establish some wildcard pattern. If your item names follow some schema like eg_kitchen_... you may subscribe ?a=eg_* to subscribe to all items which start with eg_.
Thats not implemented, yet. I saw the code for this in the backend where it would be easy to add, but I have no clue about cometvisu frontend. Maybe @tbraeutigam has an idea.
@Kai Ok, I thought I have to add some jetty config. Karaf is still ‘Neuland’.
Introducing the wildcard pattern on the client side would be quite a task. You have to build some kind of pattern recognizer, which can aggregate those wildcards from a list of item names. And in the end it would be just a workaround. The “cleaner” way IMHO would be just to use a POST request to subscribe to the item updates. Needs some changes on both sides, but would be “future proof”.
Oops, just forget what I just wrote. Somehow I forgot about the Server-sent-events communication. So we would need an additional POST request to tell the server which item updates should be send to the client via SSE. Ok a little bit more complicated then, but still they preferred way for me.
Just got a hint from the founder of the CometVisu that there is already a mechanism defined in the CometVisu protocol for this use-case, called filters. You can create a named filter, which contains a list of item names and then use this filter in the query string. The only problem is, that is must be implemented on client and server side and currently I don’t have the time to do that. So any volunteers are very welcome.
Ok, first of all: No POST. Thats the wrong verb. We don’t want to create something! E.g. POSTs cannot be cached. At first sight, we don’t want caching here at all, but if you look at the implementation on the ESH Backend, you see that every time such a “subscribe request” comes in, the event bus client subscribes to all single items ins a loop and unsubscribed after request ended. It would be more efficient to keep those subscriptions for a while and just attach request to those groups of subscriptions. Of course we need to identify them. That can be done either by wildcarding, which may be sufficient IMHO, or create a new resource for groups of items.
In openHAB we have this resource already: A sitemap! Clients of ClassicUI subscribe to a sitemap page-id which automatically contain all item names of a single view. I think this is a good pattern for this particular use case.
@tbraeutigam I have to look into those filters, maybe thats exactly what we need.
