1- Unexpected behaviour- Session custom properties dissapear & are unbindable by other objects within views or scripts, However if you re-create the same object name back and click the binding button the binding is still maintained. (have only had it occur on objects and arrays)
2- Expected behaviour - properties to persist.
4- Details:
Version - b2018121802
Is there anything unique about the binding to those custom properties? There is an internal ticket for properties disappearing if they have invalid bindings when they are loaded. Is it is bound to something that doesnât exist or something that is created from a script or something that takes a couple seconds?
If doesnât sound like any of that, you can send the project backup directly to me and Iâll take a look.
I also have experienced disappearing component custom properties (not session.custom) with valid indirect tag bindings - (at least the bindings work at runtime, though the expression editor shows âBad_NotFoundâ) Recreating the missing properties also retains the bindings.
This issue was fixed in the build that was uploaded on 1/17. Please let us know if you continue to see this behavior after upgrading.
I was not able to replicate this issue. However, from the sound of it it should be fixed by the same changes for the original post. If you continue to see this happen though, Iâd like to know what components you were using and the way that you configured the indirect tag binding.
GâDay,
The issue is still present for me on a number of bindingsâŚ
The binding is using a http binding point towards a 7.9.10 gateway using the sepasoft webservice provider. (Reason being is outdated SAP (SOAP) calls need the webservice module AUTH).
The binding refreshes when I create the same object custom property and click the binding button.
Getting this error below:
java.lang.NullPointerException: null
at com.inductiveautomation.perspective.gateway.binding.transforms.script.ScriptTransform.compile(ScriptTransform.java:68)
at com.inductiveautomation.perspective.gateway.binding.transforms.script.ScriptTransform.create(ScriptTransform.java:33)
at com.inductiveautomation.perspective.gateway.binding.BindingRegistryImpl.createTransform(BindingRegistryImpl.java:113)
at com.inductiveautomation.perspective.gateway.model.AbstractBindingHarness.(AbstractBindingHarness.java:70)
at com.inductiveautomation.perspective.gateway.model.ElementBindingHarness.(ElementBindingHarness.java:23)
at com.inductiveautomation.perspective.gateway.session.AbstractSession.lambda$new$1(AbstractSession.java:147)
at com.inductiveautomation.perspective.gateway.model.BindingCollection.create(BindingCollection.java:59)
at com.inductiveautomation.perspective.gateway.session.AbstractSession.(AbstractSession.java:145)
at com.inductiveautomation.perspective.gateway.session.PerspectiveDesignSession.(PerspectiveDesignSession.java:61)
at com.inductiveautomation.perspective.gateway.session.PerspectiveSessionCollection.createAndStartupSession(PerspectiveSessionCollection.java:236)
at java.base/java.util.HashMap.computeIfAbsent(Unknown Source)
at java.base/java.util.Collections$SynchronizedMap.computeIfAbsent(Unknown Source)
at com.inductiveautomation.perspective.gateway.session.PerspectiveSessionCollection.getOrCreateSession(PerspectiveSessionCollection.java:259)
at com.inductiveautomation.perspective.gateway.PerspectiveModuleRpcImpl.designerStartup(PerspectiveModuleRpcImpl.java:65)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at com.inductiveautomation.ignition.gateway.servlets.gateway.functions.ModuleInvoke.invoke(ModuleInvoke.java:165)
at com.inductiveautomation.ignition.gateway.servlets.Gateway.doPost(Gateway.java:409)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at com.inductiveautomation.ignition.gateway.bootstrap.MapServlet.service(MapServlet.java:86)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:530)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
at java.base/java.lang.Thread.run(Unknown Source)
Hey, I was able to reproduce with the same stacktrace as you. It looks like this issue is actually caused by another known issue that we were not aware affected this area. I will see about bumping the priority of this issue because this seems like something that will be run into a lot as people make more use of binding custom session properties.
This issue should be fixed in the latest build.
Please let us know if you continue to see this behavior after upgrading.
We saw this the other day in v8.1.36 in a dev environment. All of our session custom props just disappeared. I checked the json file and the bindings were still present, but the custom object was blank custom: {}
Very concerning as we had a lot of custom session props. We managed to salvage most of them (not all, we added some after the most recent backup), but if we didn't have the backup we would be screwed.
I did collect the wrapper logs from the time, but not sure what else would help you guys/gals diagnose?
I also noticed the loss of session custom props, I had version 8.1.28. Initially, I attributed it to my own oversight, and without further investigation, I restored these properties from a backup. Is this issue widespread? Certain functionalities crucial to me rely on these properties."
Same here, although this is the first time I've seen it
I saw this happen for the first time this week in our dev system which is running 8.1.43.
Coincidentally, I just saw it again happen today on a customer's prod system running 8.1.37. We were able to restore gateway backups to get them back, but this seems to still be an issue.
The above issue was resolved way back in 8.0.x days. I'm curious if this is something new if you are seeing it in 8.1. We haven't had reports of it occurring since then that I am aware of.
Does there happen to be anything special about these properties? Do they have bindings and/or are they set as Persistent? They just values or are they more complex objects?
If you scroll up, numerous people including me have had this issue occur in numerous versions of 8.1.x. For me, it happened on the entire session custom tree, where I had static props and bound props. When it happened, the entire session.custom became empty
Interesting, I can open up a new bug. Do you happen to have a session props resource that is in this state where you don't see them appear but their bindings are still in the json? That would help up narrow down what happened.
I do now! It happened again. I will PM you a link to download the files I collected
Well well well.... it has happened again @osolorzano
I am also experiencing this issue in Ignition 8.1.43. In my case, the Session Custom fields in Perspective Modules have disappeared from the Designer, but they still seem to exist on the Gateway, as the customer UI elements referencing them continue to function correctly.
Key details of my situation:
It seems similar to what others have reported in previous versions. Has there been any further progress on identifying the root cause? Is there a workaround to restore visibility in the Designer without recreating all session properties manually?
Looking forward to any insights or updates.
Thanks,
Jarrod
We're also having issues here with some of our custom props disappearing. It does affect the client as the properties cannot be found, the UI components end up with broken bindings. This has happened on 3 different pages now and we're still unsure of what is initially triggering this behavior. When we recreate the missing custom prop objects with the same name, the binding comes back. We save the page, close and re-open it in the designer and the custom prop is "gone" again.
Missing custom props custom.snapshot.selected.data
Custom props and bindings still in view export.
