Datastore Validation

[AdamRepsher]

Is anyone having any problems with Registered ArcGIS Servers?  I was troubleshooting another issue when I saw this occur.  Within 30 minutes, my logs filled with an error repeated 23 times within the same second - every 2 or three minutes.

When the error was occuring, I would go to the Data Stores page on the GEP Manager site and see that ArcGIS Server was not validated.  My Feature Service Outputs were still working, but when I opened the edit window on any of them, the page did not display any Service Name or Layer.  The drop-downs were empty.

After restart, everything concerning that issue appears to be fine.

Should I be submitting bug tickets with this and the other issues that I am posting here about?

Thanks,
--Adam

Here is one entry in the log that I think is attached to this issue:

com.esri.ges.manager.stream.internal.OutboundTransportProxy

Failed to set Transport (com.esri.ges.transport.outbound/FeatureService/10.2.0) properties:     com.esri.ges.core.validation.ValidationException: com.esri.ges.transport.featureService.FeatureServiceOutboundTransport properties validation failed: Mandatory property 'datastore' is not set. Mandatory property 'serviceName' is not set.        at com.esri.ges.core.property.PropertyCollectionBase.validate(PropertyCollectionBase.java:184)        at com.esri.ges.manager.stream.internal.OutboundTransportProxy.initTransport(OutboundTransportProxy.java:68)        at com.esri.ges.manager.stream.internal.TransportProxyBase.installTransport(TransportProxyBase.java:359)        at com.esri.ges.manager.stream.internal.TransportProxyBase.setTransportUri(TransportProxyBase.java:70)        at com.esri.ges.manager.stream.internal.StreamBase.setTransportUri(StreamBase.java:200)        at com.esri.ges.manager.stream.internal.StreamManagerImpl.newStream(StreamManagerImpl.java:196)        at com.esri.ges.manager.stream.internal.StreamManagerImpl.queueStream(StreamManagerImpl.java:307)        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]        at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]        at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:50)        at org.apache.aries.proxy.impl.DefaultWrapper.invoke(DefaultWrapper.java:31)        at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:78)        at com.sun.proxy.$Proxy94.queueStream(Unknown Source)        at com.esri.ges.persistence.file.stream.FileStreamDAO.register(FileStreamDAO.java:131)        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]        at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]        at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:225)[15:org.apache.aries.blueprint:0.3.2]        at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:838)[15:org.apache.aries.blueprint:0.3.2]        at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:638)[15:org.apache.aries.blueprint:0.3.2]        at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:726)[15:org.apache.aries.blueprint:0.3.2]        at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[15:org.apache.aries.blueprint:0.3.2]        at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)[15:org.apache.aries.blueprint:0.3.2]        at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:147)[15:org.apache.aries.blueprint:0.3.2]        at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:631)[15:org.apache.aries.blueprint:0.3.2]        at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:337)[15:org.apache.aries.blueprint:0.3.2]        at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:230)[15:org.apache.aries.blueprint:0.3.2]        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_17]        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]        at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)[:1.7.0_17]        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)[:1.7.0_17]        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17]        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17]        at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]

[RJSunderman]

Hey Adam -

Thank you for the details and including the error from the GEP logs.  It may be that that your feature service output (at an instant in time) didn't have one or more required properties. I've seen this "validation failed" error message however when I know that the object in question is fully defined ... so I'm not going to focus too much on this particular error message.

I'm more interested in your report that when you open the Data Stores page in Manager you see that the registered server connection displays as not valid. If you click the 'Validate All' button at this point, can the connection be validated? (If the GEP cannot access the registered data store to locate the service folder, I"?d expect that opening the configuration page for the output connector would display empty fields for the "?Service Name"?, "?Layer"? and (if updating features) the "?Unique Field Identifier"?.)

To your comment that restarting appears to fix the issue - are you restarting the GEP Windows service?  I'm wondering if it is possible that an attempt by GEP to connect to the AGS site using the configured Server connection failed, but restarting GEP forced a second attempt which then succeeded...

I think we may be dealing with a Server connection which is intermittently unavailable. Is there a way you can manually verify the connection from your GEP server to your AGS server when you are seeing this issue (outside of GEP Manager)?

To your question of submitting incidents/tickets with Esri Technical Support - yes, if we have an issue that can be reproduced (since that is what Esri Support is supposed to do), then please open a new Support incident. Otherwise, posting to the forum as you are gets the issue in front of the development team and we can help diagnose it as quickly as we can make time for the investigation. Thanks for working with us ...

/RJ

[AdamRepsher]

Thank you for the response RJ,

To be completely clear:

• This is the one and only time that this specific issue has ever happened to me.


• The restart that I refer to IS the GEP Windows service.


• Before I restarted the GEP Windows service, every time I pressed the Validate button, it would NOT get vaildated.  Also, ALL of the output connector setups in manager would display empty fields.  BUT still, with no restart, the outputs were actually WORKING.


• If I saved a output connector setup while seeing these faults, the output connector would fail.  (should be obvious, but I just wanated to document that I tried it.)


• After I restarted the GEP Windows service, everything returned to normal.

I would think that manual verification would have not been needed, just because all of my feature services were being updated when I was seeing these problems.  Is it possible that GEP is functioning correctly, but reporting the incorrect information to the Manager?

BUT, since you mention:

I think we may be dealing with a Server connection which is intermittently unavailable.

In another recent Forum post of mine, I am almost convinced that may be the issue to this completely separate issue.  Read it and tell me what you think.  All of the ArcGIS Server services are set to recycle at midnight by default (pic follows):
[ATTACH=CONFIG]27117[/ATTACH]