[Aerogear-users] UPS load on startup

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Aerogear-users] UPS load on startup

Kelvin Lunsford
I'm developing a mobile app and testing USP 1.0.2 on Wildfly 8.2.0.

Runs great but I've noticed that when the server is restarted registration requests from my mobile app fail until I try to access the ag-push console with a browser and bring up a login page.  Then registration works.

Anyone noticed this?

- Kelvin


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Aerogear-users] UPS load on startup

Matthias Wessendorf
hrm,

that's strange - not noticed so far.
Any details on the error message ? Is that reproducable w/ something like curl ? 

On Fri, Jun 12, 2015 at 3:05 AM, Kelvin Lunsford <[hidden email]> wrote:
I'm developing a mobile app and testing USP 1.0.2 on Wildfly 8.2.0.

Runs great but I've noticed that when the server is restarted registration requests from my mobile app fail until I try to access the ag-push console with a browser and bring up a login page.  Then registration works.

Anyone noticed this?

- Kelvin


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users



--

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Aerogear-users] UPS load on startup

Kelvin Lunsford
I restarted Wildfly and I had to log into the UPS console to stop the registration errors.

The error callback for the plugin push.register() function returns the message "The server returned the error code 500".

- Kelvin

 

---------------------------------------------------------------------------

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthias Wessendorf
Sent: Friday, June 12, 2015 12:01 AM
To: [hidden email]
Subject: Re: [Aerogear-users] UPS load on startup

hrm,

that's strange - not noticed so far.
Any details on the error message ? Is that reproducable w/ something like curl ? 

On Fri, Jun 12, 2015 at 3:05 AM, Kelvin Lunsford <[hidden email]> wrote:
I'm developing a mobile app and testing USP 1.0.2 on Wildfly 8.2.0.

Runs great but I've noticed that when the server is restarted registration requests from my mobile app fail until I try to access the ag-push console with a browser and bring up a login page.  Then registration works.

Anyone noticed this?

- Kelvin


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Aerogear-users] UPS load on startup

Matthias Wessendorf
any chance of stack trace?

On Saturday, June 13, 2015, Kelvin Lunsford <[hidden email]> wrote:
I restarted Wildfly and I had to log into the UPS console to stop the registration errors.

The error callback for the plugin push.register() function returns the message "The server returned the error code 500".

- Kelvin



---------------------------------------------------------------------------

From: <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;aerogear-users-bounces@lists.jboss.org&#39;)">aerogear-users-bounces@... [mailto:<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;aerogear-users-bounces@lists.jboss.org&#39;)">aerogear-users-bounces@...] On Behalf Of Matthias Wessendorf
Sent: Friday, June 12, 2015 12:01 AM
To: <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;aerogear-users@lists.jboss.org&#39;)">aerogear-users@...
Subject: Re: [Aerogear-users] UPS load on startup

hrm,

that's strange - not noticed so far.
Any details on the error message ? Is that reproducable w/ something like curl ? 

On Fri, Jun 12, 2015 at 3:05 AM, Kelvin Lunsford <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;kelvin@qantel.com&#39;)">kelvin@...> wrote:
I'm developing a mobile app and testing USP 1.0.2 on Wildfly 8.2.0.

Runs great but I've noticed that when the server is restarted registration requests from my mobile app fail until I try to access the ag-push console with a browser and bring up a login page.  Then registration works.

Anyone noticed this?

- Kelvin


_______________________________________________
Aerogear-users mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Aerogear-users@lists.jboss.org&#39;)">Aerogear-users@...
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Aerogear-users@lists.jboss.org&#39;)">Aerogear-users@...
https://lists.jboss.org/mailman/listinfo/aerogear-users


--
Sent from Gmail Mobile

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Aerogear-users] UPS load on startup

Alex Ballesté
Hi, I noticed the same behaviour in my aerogear test server, but I thought that was something related with openshift. If service is not used for a while seems like it become suspended until you access again.

I tried to reproduce restarting the server but I couldn't... Just found something in the logs this morning after 2 days without using it. (At 2:51 I sent the notification)

Log was
-----------------------------
2015/06/13 00:00:00,109 INFO  [GCMPushNotificationSender] (EJB default - 2) Deleting [&apos;0&apos;] outdated PushMessageInformation objects
2015/06/13 12:05:30,766 INFO  [org.jboss.as.osgi] (MSC service thread 1-5) JBAS011942: Stopping OSGi Framework
2015/06/15 02:51:14,161 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 35) JBAS016200: Activating ConfigAdmin Subsystem
2015/06/15 02:51:14,264 INFO  [org.jboss.as.jacorb] (ServerService Thread Pool -- 41) JBAS016300: Activating JacORB Subsystem
2015/06/15 02:51:14,356 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) JBAS013101: Activating Security Subsystem
2015/06/15 02:51:14,258 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 40) JBAS010280: Activating Infinispan subsystem.
...
...
-------------------------------------
   
It seem like on saturday 13 service was stopped. And started again on monday 16 at 2:51 (by my notification???) . I also got this error during the startup process

--------------------------
2015/06/15 02:51:46,443 INFO  [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] (MSC service thread 1-5) **** using /WEB-INF/keycloak.json
2015/06/15 02:51:46,760 INFO  [JPAPushMessageInformationDao] (EJB default - 2) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,951 INFO  [org.keycloak.services.resources.KeycloakApplication] (MSC service thread 1-1) Not importing realm aerogear from resource /WEB-INF/ups-realm.json.  It already exists.
2015/06/15 02:51:46,954 INFO  [JPAPushMessageInformationDao] (EJB default - 1) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,966 WARN  [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a21a655:16c5d4f8:557e75e5:f, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@d8bbe6 >: javax.persistence.OptimisticLockException: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:1402) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1308) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1481) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:109) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
------------------------

Later another generated message at 2:57 was received an processed fine. I don't know if it's something related with hosting or with UPS. I'm running 1.0.2 too.

Sorry if this information is not relevant

Alex Ballesté

El 13/06/15 a les 08:01, Matthias Wessendorf ha escrit:
any chance of stack trace?

On Saturday, June 13, 2015, Kelvin Lunsford <[hidden email]> wrote:
I restarted Wildfly and I had to log into the UPS console to stop the registration errors.

The error callback for the plugin push.register() function returns the message "The server returned the error code 500".

- Kelvin



---------------------------------------------------------------------------

From: <a moz-do-not-send="true" href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-users-bounces@lists.jboss.org')">aerogear-users-bounces@... [mailto:<a moz-do-not-send="true" href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-users-bounces@lists.jboss.org')">aerogear-users-bounces@...] On Behalf Of Matthias Wessendorf
Sent: Friday, June 12, 2015 12:01 AM
To: <a moz-do-not-send="true" href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-users@lists.jboss.org')">aerogear-users@...
Subject: Re: [Aerogear-users] UPS load on startup

hrm,

that's strange - not noticed so far.
Any details on the error message ? Is that reproducable w/ something like curl ? 

On Fri, Jun 12, 2015 at 3:05 AM, Kelvin Lunsford <<a moz-do-not-send="true" href="javascript:;" onclick="_e(event, 'cvml', 'kelvin@qantel.com')">kelvin@...> wrote:
I'm developing a mobile app and testing USP 1.0.2 on Wildfly 8.2.0.

Runs great but I've noticed that when the server is restarted registration requests from my mobile app fail until I try to access the ag-push console with a browser and bring up a login page.  Then registration works.

Anyone noticed this?

- Kelvin


_______________________________________________
Aerogear-users mailing list
<a moz-do-not-send="true" href="javascript:;" onclick="_e(event, 'cvml', 'Aerogear-users@lists.jboss.org')">Aerogear-users@...
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
<a moz-do-not-send="true" href="javascript:;" onclick="_e(event, 'cvml', 'Aerogear-users@lists.jboss.org')">Aerogear-users@...
https://lists.jboss.org/mailman/listinfo/aerogear-users


--
Sent from Gmail Mobile


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


--

Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
====================
Universitat de Lleida

Àrea de sistemes d'Informació i Comunicacions

Analista/Programador


University of Lleida

Information and Communication Systems Service


Tlf: +34 973 702148

Fax: +34 973 702130

=====================

Avís legal/Aviso legal/Avertiment legal/Legal notice


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Aerogear-users] UPS load on startup

Matthias Wessendorf
Hi,

yes, openshift gets susspended after 48 hours (I think) of inactivity - but I think your error is different to Kevin's 

Kevin any chance to get a log file / stack-trace from the 500 ? 

Is that just on Android/Cordova, or does that also reproduce w/ doing (test) registration w/ curl, like:

Thanks

On Mon, Jun 15, 2015 at 12:29 PM, Alex Ballesté <[hidden email]> wrote:
Hi, I noticed the same behaviour in my aerogear test server, but I thought that was something related with openshift. If service is not used for a while seems like it become suspended until you access again.

I tried to reproduce restarting the server but I couldn't... Just found something in the logs this morning after 2 days without using it. (At 2:51 I sent the notification)

Log was
-----------------------------
2015/06/13 00:00:00,109 INFO  [GCMPushNotificationSender] (EJB default - 2) Deleting [&apos;0&apos;] outdated PushMessageInformation objects
2015/06/13 12:05:30,766 INFO  [org.jboss.as.osgi] (MSC service thread 1-5) JBAS011942: Stopping OSGi Framework
2015/06/15 02:51:14,161 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 35) JBAS016200: Activating ConfigAdmin Subsystem
2015/06/15 02:51:14,264 INFO  [org.jboss.as.jacorb] (ServerService Thread Pool -- 41) JBAS016300: Activating JacORB Subsystem
2015/06/15 02:51:14,356 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) JBAS013101: Activating Security Subsystem
2015/06/15 02:51:14,258 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 40) JBAS010280: Activating Infinispan subsystem.
...
...
-------------------------------------
   
It seem like on saturday 13 service was stopped. And started again on monday 16 at 2:51 (by my notification???) . I also got this error during the startup process

--------------------------
2015/06/15 02:51:46,443 INFO  [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] (MSC service thread 1-5) **** using /WEB-INF/keycloak.json
2015/06/15 02:51:46,760 INFO  [JPAPushMessageInformationDao] (EJB default - 2) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,951 INFO  [org.keycloak.services.resources.KeycloakApplication] (MSC service thread 1-1) Not importing realm aerogear from resource /WEB-INF/ups-realm.json.  It already exists.
2015/06/15 02:51:46,954 INFO  [JPAPushMessageInformationDao] (EJB default - 1) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,966 WARN  [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a21a655:16c5d4f8:557e75e5:f, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@d8bbe6 >: javax.persistence.OptimisticLockException: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:1402) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1308) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1481) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:109) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
------------------------

Later another generated message at 2:57 was received an processed fine. I don't know if it's something related with hosting or with UPS. I'm running 1.0.2 too.

Sorry if this information is not relevant

Alex Ballesté

El 13/06/15 a les 08:01, Matthias Wessendorf ha escrit:
any chance of stack trace?

On Saturday, June 13, 2015, Kelvin Lunsford <[hidden email]> wrote:
I restarted Wildfly and I had to log into the UPS console to stop the registration errors.

The error callback for the plugin push.register() function returns the message "The server returned the error code 500".

- Kelvin



---------------------------------------------------------------------------

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthias Wessendorf
Sent: Friday, June 12, 2015 12:01 AM
To: [hidden email]
Subject: Re: [Aerogear-users] UPS load on startup

hrm,

that's strange - not noticed so far.
Any details on the error message ? Is that reproducable w/ something like curl ? 

On Fri, Jun 12, 2015 at 3:05 AM, Kelvin Lunsford <[hidden email]> wrote:
I'm developing a mobile app and testing USP 1.0.2 on Wildfly 8.2.0.

Runs great but I've noticed that when the server is restarted registration requests from my mobile app fail until I try to access the ag-push console with a browser and bring up a login page.  Then registration works.

Anyone noticed this?

- Kelvin


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


--
Sent from Gmail Mobile


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


--

Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
====================
Universitat de Lleida

Àrea de sistemes d'Informació i Comunicacions

Analista/Programador


University of Lleida

Information and Communication Systems Service


Tlf: <a href="tel:%2B34%20973%20702148" value="+34973702148" target="_blank">+34 973 702148

Fax: <a href="tel:%2B34%20973%20702130" value="+34973702130" target="_blank">+34 973 702130

=====================

Avís legal/Aviso legal/Avertiment legal/Legal notice


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Aerogear-users] UPS load on startup

Kelvin Lunsford
I tried to add UPS logging by following the instructions in the UPS user guide but couldn't get it working.

This is what I see in the server.log file.

...

2015-06-16 15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
2015-06-16 15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
2015-06-16 15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" started in 13573ms - Started 579 of 637 services (101 services are lazy, passive or on-demand)
2015-06-16 15:50:27,011 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ag-push/rest/registry/device: java.lang.RuntimeException: Unable to resolve realm public key remotely, status = 404
        at org.keycloak.adapters.AdapterDeploymentContext.resolveRealmKey(AdapterDeploymentContext.java:69) [keycloak-adapter-core-1.0.4.Final.jar:]
        at org.keycloak.adapters.AdapterDeploymentContext.resolveDeployment(AdapterDeploymentContext.java:55) [keycloak-adapter-core-1.0.4.Final.jar:]
        at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:54) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_71]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_71]
        at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_71]


The error occurs each time I try to do a registration after server restart, until I log into the UPS console, then the errors stop.

- Kelvin

 


----------------------------------------------------------------------------------

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthias Wessendorf
Sent: Monday, June 15, 2015 4:10 AM
To: [hidden email]
Subject: Re: [Aerogear-users] UPS load on startup

Hi,

yes, openshift gets susspended after 48 hours (I think) of inactivity - but I think your error is different to Kevin's 

Kevin any chance to get a log file / stack-trace from the 500 ? 

Is that just on Android/Cordova, or does that also reproduce w/ doing (test) registration w/ curl, like:
https://aerogear.org/docs/specs/aerogear-unifiedpush-rest-1.0.x/registry/device/index.html#POST

Thanks

On Mon, Jun 15, 2015 at 12:29 PM, Alex Ballesté <[hidden email]> wrote:
Hi, I noticed the same behaviour in my aerogear test server, but I thought that was something related with openshift. If service is not used for a while seems like it become suspended until you access again.

I tried to reproduce restarting the server but I couldn't... Just found something in the logs this morning after 2 days without using it. (At 2:51 I sent the notification)

Log was
-----------------------------
2015/06/13 00:00:00,109 INFO  [GCMPushNotificationSender] (EJB default - 2) Deleting [&apos;0&apos;] outdated PushMessageInformation objects
2015/06/13 12:05:30,766 INFO  [org.jboss.as.osgi] (MSC service thread 1-5) JBAS011942: Stopping OSGi Framework
2015/06/15 02:51:14,161 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 35) JBAS016200: Activating ConfigAdmin Subsystem
2015/06/15 02:51:14,264 INFO  [org.jboss.as.jacorb] (ServerService Thread Pool -- 41) JBAS016300: Activating JacORB Subsystem
2015/06/15 02:51:14,356 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) JBAS013101: Activating Security Subsystem
2015/06/15 02:51:14,258 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 40) JBAS010280: Activating Infinispan subsystem.
...
...
-------------------------------------
   
It seem like on saturday 13 service was stopped. And started again on monday 16 at 2:51 (by my notification???) . I also got this error during the startup process

--------------------------
2015/06/15 02:51:46,443 INFO  [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] (MSC service thread 1-5) **** using /WEB-INF/keycloak.json
2015/06/15 02:51:46,760 INFO  [JPAPushMessageInformationDao] (EJB default - 2) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,951 INFO  [org.keycloak.services.resources.KeycloakApplication] (MSC service thread 1-1) Not importing realm aerogear from resource /WEB-INF/ups-realm.json.  It already exists.
2015/06/15 02:51:46,954 INFO  [JPAPushMessageInformationDao] (EJB default - 1) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,966 WARN  [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a21a655:16c5d4f8:557e75e5:f, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@d8bbe6 >: javax.persistence.OptimisticLockException: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:1402) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1308) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1481) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:109) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
------------------------

Later another generated message at 2:57 was received an processed fine. I don't know if it's something related with hosting or with UPS. I'm running 1.0.2 too.

Sorry if this information is not relevant

Alex Ballesté

El 13/06/15 a les 08:01, Matthias Wessendorf ha escrit:
any chance of stack trace?

On Saturday, June 13, 2015, Kelvin Lunsford <[hidden email]> wrote:
I restarted Wildfly and I had to log into the UPS console to stop the registration errors.

The error callback for the plugin push.register() function returns the message "The server returned the error code 500".

- Kelvin



---------------------------------------------------------------------------

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthias Wessendorf
Sent: Friday, June 12, 2015 12:01 AM
To: [hidden email]
Subject: Re: [Aerogear-users] UPS load on startup

hrm,

that's strange - not noticed so far.
Any details on the error message ? Is that reproducable w/ something like curl ? 

On Fri, Jun 12, 2015 at 3:05 AM, Kelvin Lunsford <[hidden email]> wrote:
I'm developing a mobile app and testing USP 1.0.2 on Wildfly 8.2.0.

Runs great but I've noticed that when the server is restarted registration requests from my mobile app fail until I try to access the ag-push console with a browser and bring up a login page.  Then registration works.

Anyone noticed this?

- Kelvin


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


--
Sent from Gmail Mobile

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
====================
Universitat de Lleida
Àrea de sistemes d'Informació i Comunicacions
Analista/Programador

University of Lleida
Information and Communication Systems Service

Tlf: +34 973 702148
Fax: +34 973 702130
=====================
Avís legal/Aviso legal/Avertiment legal/Legal notice

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Aerogear-users] UPS load on startup

Matthias Wessendorf
Hi Kevin,

thanks for the feedback! Here is what I did to reproduce your issue (w/o success):

* I have deployed UPS 1.0.2 into a (full profile) WF 8.2. 
* start the server (reset the admin password)
* create app and (dummy) variant (for Android), and noted the variantID:secret
* shutdown WF
* start WF
* did a curl agains the registration endpoint (got a 200)
* logged in, and seeing one device is registered.

Here is the CURL, I used (note the -u value ;-))

curl -u "variantID:secret" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"deviceToken" : "a152f21a-d327-4303-99d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1"}' http://127.0.0.1:8080/ag-push/rest/registry/device


That worked fine. My question is: does _this_ also generate you the 404 error? Or is that something you are "just" seeing from the AeroGear Registration SDK? (e.g. for Android/iOS or Cordova).

PS: the same 'test' passes with the 1.1.0-Final-SNAPSHOT build I did locally

Thanks!
Matthias




On Wed, Jun 17, 2015 at 3:31 AM, Kelvin Lunsford <[hidden email]> wrote:
I tried to add UPS logging by following the instructions in the UPS user guide but couldn't get it working.

This is what I see in the server.log file.

...

2015-06-16 15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on <a href="http://127.0.0.1:9990/management 2015-06-16" rel="noreferrer" target="_blank">http://127.0.0.1:9990/management
2015-06-16 15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
2015-06-16 15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" started in 13573ms - Started 579 of 637 services (101 services are lazy, passive or on-demand)
2015-06-16 15:50:27,011 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ag-push/rest/registry/device: java.lang.RuntimeException: Unable to resolve realm public key remotely, status = 404
        at org.keycloak.adapters.AdapterDeploymentContext.resolveRealmKey(AdapterDeploymentContext.java:69) [keycloak-adapter-core-1.0.4.Final.jar:]
        at org.keycloak.adapters.AdapterDeploymentContext.resolveDeployment(AdapterDeploymentContext.java:55) [keycloak-adapter-core-1.0.4.Final.jar:]
        at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:54) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_71]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_71]
        at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_71]


The error occurs each time I try to do a registration after server restart, until I log into the UPS console, then the errors stop.

- Kelvin




----------------------------------------------------------------------------------

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthias Wessendorf
Sent: Monday, June 15, 2015 4:10 AM
To: [hidden email]
Subject: Re: [Aerogear-users] UPS load on startup

Hi,

yes, openshift gets susspended after 48 hours (I think) of inactivity - but I think your error is different to Kevin's 

Kevin any chance to get a log file / stack-trace from the 500 ? 

Is that just on Android/Cordova, or does that also reproduce w/ doing (test) registration w/ curl, like:
https://aerogear.org/docs/specs/aerogear-unifiedpush-rest-1.0.x/registry/device/index.html#POST

Thanks

On Mon, Jun 15, 2015 at 12:29 PM, Alex Ballesté <[hidden email]> wrote:
Hi, I noticed the same behaviour in my aerogear test server, but I thought that was something related with openshift. If service is not used for a while seems like it become suspended until you access again.

I tried to reproduce restarting the server but I couldn't... Just found something in the logs this morning after 2 days without using it. (At 2:51 I sent the notification)

Log was
-----------------------------
2015/06/13 00:00:00,109 INFO  [GCMPushNotificationSender] (EJB default - 2) Deleting [&apos;0&apos;] outdated PushMessageInformation objects
2015/06/13 12:05:30,766 INFO  [org.jboss.as.osgi] (MSC service thread 1-5) JBAS011942: Stopping OSGi Framework
2015/06/15 02:51:14,161 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 35) JBAS016200: Activating ConfigAdmin Subsystem
2015/06/15 02:51:14,264 INFO  [org.jboss.as.jacorb] (ServerService Thread Pool -- 41) JBAS016300: Activating JacORB Subsystem
2015/06/15 02:51:14,356 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) JBAS013101: Activating Security Subsystem
2015/06/15 02:51:14,258 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 40) JBAS010280: Activating Infinispan subsystem.
...
...
-------------------------------------
   
It seem like on saturday 13 service was stopped. And started again on monday 16 at 2:51 (by my notification???) . I also got this error during the startup process

--------------------------
2015/06/15 02:51:46,443 INFO  [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] (MSC service thread 1-5) **** using /WEB-INF/keycloak.json
2015/06/15 02:51:46,760 INFO  [JPAPushMessageInformationDao] (EJB default - 2) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,951 INFO  [org.keycloak.services.resources.KeycloakApplication] (MSC service thread 1-1) Not importing realm aerogear from resource /WEB-INF/ups-realm.json.  It already exists.
2015/06/15 02:51:46,954 INFO  [JPAPushMessageInformationDao] (EJB default - 1) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,966 WARN  [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a21a655:16c5d4f8:557e75e5:f, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@d8bbe6 >: javax.persistence.OptimisticLockException: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:1402) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1308) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1481) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:109) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
------------------------

Later another generated message at 2:57 was received an processed fine. I don't know if it's something related with hosting or with UPS. I'm running 1.0.2 too.

Sorry if this information is not relevant

Alex Ballesté

El 13/06/15 a les 08:01, Matthias Wessendorf ha escrit:
any chance of stack trace?

On Saturday, June 13, 2015, Kelvin Lunsford <[hidden email]> wrote:
I restarted Wildfly and I had to log into the UPS console to stop the registration errors.

The error callback for the plugin push.register() function returns the message "The server returned the error code 500".

- Kelvin



---------------------------------------------------------------------------

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthias Wessendorf
Sent: Friday, June 12, 2015 12:01 AM
To: [hidden email]
Subject: Re: [Aerogear-users] UPS load on startup

hrm,

that's strange - not noticed so far.
Any details on the error message ? Is that reproducable w/ something like curl ? 

On Fri, Jun 12, 2015 at 3:05 AM, Kelvin Lunsford <[hidden email]> wrote:
I'm developing a mobile app and testing USP 1.0.2 on Wildfly 8.2.0.

Runs great but I've noticed that when the server is restarted registration requests from my mobile app fail until I try to access the ag-push console with a browser and bring up a login page.  Then registration works.

Anyone noticed this?

- Kelvin


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


--
Sent from Gmail Mobile

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
====================
Universitat de Lleida
Àrea de sistemes d'Informació i Comunicacions
Analista/Programador

University of Lleida
Information and Communication Systems Service

Tlf: <a href="tel:%2B34%20973%20702148" value="+34973702148">+34 973 702148
Fax: <a href="tel:%2B34%20973%20702130" value="+34973702130">+34 973 702130
=====================
Avís legal/Aviso legal/Avertiment legal/Legal notice

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users



--

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Aerogear-users] UPS load on startup

Kelvin Lunsford

Thanks for the help Matt,

 

I used curl and discovered the startup failure only occurred when UPS was accessed from outside our firewall.  It was a proxy configuration problem.

 

Or at least I was able to avoid the problem with some changes to our reverse proxy. 

 

By turning on  the RequestDumpingHandler in Wildfly I was able to see what was happening. 

 

Turns out the first time UPS is accessed after startup Wildfly does an http access to get an aerogear token.  Accessing the Aerogear console also loaded the token, which is why everything worked fine after the console was accessed.

 

Wildfly seems to be using the contents of the 'host' header in the original request to set the host and port used  to access /auth/realms/aerogear.  The original 'host' header value did not include a port which caused port 80 to be used , and the auth URL was not accessible with those values.  

 

I was able to configure our proxy to set the 'host' header of the proxied requests to a host:port value used by wildfly, and everything works great now.

 

This will probably work differently when Keycloak and UPS are separated. Bridges to cross.

 

Again, thanks for your help.

 

- Kelvin

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthias Wessendorf
Sent: Wednesday, June 17, 2015 2:07 AM
To: [hidden email]
Subject: Re: [Aerogear-users] UPS load on startup

 

Hi Kevin,

 

thanks for the feedback! Here is what I did to reproduce your issue (w/o success):

 

* I have deployed UPS 1.0.2 into a (full profile) WF 8.2. 

* start the server (reset the admin password)

* create app and (dummy) variant (for Android), and noted the variantID:secret

* shutdown WF

* start WF

* did a curl agains the registration endpoint (got a 200)

* logged in, and seeing one device is registered.

 

Here is the CURL, I used (note the -u value ;-))

 

curl -u "variantID:secret" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"deviceToken" : "a152f21a-d327-4303-99d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1"}' http://127.0.0.1:8080/ag-push/rest/registry/device

 

 

That worked fine. My question is: does _this_ also generate you the 404 error? Or is that something you are "just" seeing from the AeroGear Registration SDK? (e.g. for Android/iOS or Cordova).

 

PS: the same 'test' passes with the 1.1.0-Final-SNAPSHOT build I did locally

 

Thanks!

Matthias

 

 

 

 

On Wed, Jun 17, 2015 at 3:31 AM, Kelvin Lunsford <[hidden email]> wrote:

I tried to add UPS logging by following the instructions in the UPS user guide but couldn't get it working.

This is what I see in the server.log file.

...

2015-06-16 15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
2015-06-16
15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
2015-06-16 15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" started in 13573ms - Started 579 of 637 services (101 services are lazy, passive or on-demand)
2015-06-16 15:50:27,011 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ag-push/rest/registry/device: java.lang.RuntimeException: Unable to resolve realm public key remotely, status = 404
        at org.keycloak.adapters.AdapterDeploymentContext.resolveRealmKey(AdapterDeploymentContext.java:69) [keycloak-adapter-core-1.0.4.Final.jar:]
        at org.keycloak.adapters.AdapterDeploymentContext.resolveDeployment(AdapterDeploymentContext.java:55) [keycloak-adapter-core-1.0.4.Final.jar:]
        at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:54) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_71]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_71]
        at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_71]


The error occurs each time I try to do a registration after server restart, until I log into the UPS console, then the errors stop.

- Kelvin




----------------------------------------------------------------------------------

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthias Wessendorf
Sent: Monday, June 15, 2015 4:10 AM

To: [hidden email]
Subject: Re: [Aerogear-users] UPS load on startup

Hi,

yes, openshift gets susspended after 48 hours (I think) of inactivity - but I think your error is different to Kevin's 

Kevin any chance to get a log file / stack-trace from the 500 ? 

Is that just on Android/Cordova, or does that also reproduce w/ doing (test) registration w/ curl, like:
https://aerogear.org/docs/specs/aerogear-unifiedpush-rest-1.0.x/registry/device/index.html#POST

Thanks

On Mon, Jun 15, 2015 at 12:29 PM, Alex Ballesté <[hidden email]> wrote:
Hi, I noticed the same behaviour in my aerogear test server, but I thought that was something related with openshift. If service is not used for a while seems like it become suspended until you access again.

I tried to reproduce restarting the server but I couldn't... Just found something in the logs this morning after 2 days without using it. (At 2:51 I sent the notification)

Log was
-----------------------------
2015/06/13 00:00:00,109 INFO  [GCMPushNotificationSender] (EJB default - 2) Deleting [&apos;0&apos;] outdated PushMessageInformation objects
2015/06/13 12:05:30,766 INFO  [org.jboss.as.osgi] (MSC service thread 1-5) JBAS011942: Stopping OSGi Framework
2015/06/15 02:51:14,161 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 35) JBAS016200: Activating ConfigAdmin Subsystem
2015/06/15 02:51:14,264 INFO  [org.jboss.as.jacorb] (ServerService Thread Pool -- 41) JBAS016300: Activating JacORB Subsystem
2015/06/15 02:51:14,356 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) JBAS013101: Activating Security Subsystem
2015/06/15 02:51:14,258 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 40) JBAS010280: Activating Infinispan subsystem.
...
...
-------------------------------------
   
It seem like on saturday 13 service was stopped. And started again on monday 16 at 2:51 (by my notification???) . I also got this error during the startup process

--------------------------
2015/06/15 02:51:46,443 INFO  [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] (MSC service thread 1-5) **** using /WEB-INF/keycloak.json
2015/06/15 02:51:46,760 INFO  [JPAPushMessageInformationDao] (EJB default - 2) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,951 INFO  [org.keycloak.services.resources.KeycloakApplication] (MSC service thread 1-1) Not importing realm aerogear from resource /WEB-INF/ups-realm.json.  It already exists.
2015/06/15 02:51:46,954 INFO  [JPAPushMessageInformationDao] (EJB default - 1) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,966 WARN  [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a21a655:16c5d4f8:557e75e5:f, [hidden email] >: javax.persistence.OptimisticLockException: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:1402) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1308) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1481) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:109) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
------------------------

Later another generated message at 2:57 was received an processed fine. I don't know if it's something related with hosting or with UPS. I'm running 1.0.2 too.

Sorry if this information is not relevant

Alex Ballesté

El 13/06/15 a les 08:01, Matthias Wessendorf ha escrit:
any chance of stack trace?

On Saturday, June 13, 2015, Kelvin Lunsford <[hidden email]> wrote:
I restarted Wildfly and I had to log into the UPS console to stop the registration errors.

The error callback for the plugin push.register() function returns the message "The server returned the error code 500".

- Kelvin



---------------------------------------------------------------------------

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthias Wessendorf
Sent: Friday, June 12, 2015 12:01 AM
To: [hidden email]
Subject: Re: [Aerogear-users] UPS load on startup

hrm,

that's strange - not noticed so far.
Any details on the error message ? Is that reproducable w/ something like curl ? 

On Fri, Jun 12, 2015 at 3:05 AM, Kelvin Lunsford <[hidden email]> wrote:
I'm developing a mobile app and testing USP 1.0.2 on Wildfly 8.2.0.

Runs great but I've noticed that when the server is restarted registration requests from my mobile app fail until I try to access the ag-push console with a browser and bring up a login page.  Then registration works.

Anyone noticed this?

- Kelvin


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


--
Sent from Gmail Mobile

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
====================
Universitat de Lleida
Àrea de sistemes d'Informació i Comunicacions
Analista/Programador

University of Lleida
Information and Communication Systems Service

Tlf: <a href="tel:%2B34%20973%20702148">+34 973 702148
Fax: <a href="tel:%2B34%20973%20702130">+34 973 702130
=====================
Avís legal/Aviso legal/Avertiment legal/Legal notice

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users



 

--


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Aerogear-users] UPS load on startup

Matthias Wessendorf
Hi Kelvin!

thanks for the details! I will try this here too for abetter understanding!



On Wednesday, July 1, 2015, Kelvin Lunsford <[hidden email]> wrote:

Thanks for the help Matt,

 

I used curl and discovered the startup failure only occurred when UPS was accessed from outside our firewall.  It was a proxy configuration problem.

 

Or at least I was able to avoid the problem with some changes to our reverse proxy. 

 

By turning on  the RequestDumpingHandler in Wildfly I was able to see what was happening. 

 

Turns out the first time UPS is accessed after startup Wildfly does an http access to get an aerogear token.  Accessing the Aerogear console also loaded the token, which is why everything worked fine after the console was accessed.

 

Wildfly seems to be using the contents of the 'host' header in the original request to set the host and port used  to access /auth/realms/aerogear.  The original 'host' header value did not include a port which caused port 80 to be used , and the auth URL was not accessible with those values.  

 

I was able to configure our proxy to set the 'host' header of the proxied requests to a host:port value used by wildfly, and everything works great now.

 

This will probably work differently when Keycloak and UPS are separated. Bridges to cross.

 

Again, thanks for your help.

 

- Kelvin

 

 

From: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-users-bounces@lists.jboss.org&#39;);" target="_blank">aerogear-users-bounces@... [mailto:<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-users-bounces@lists.jboss.org&#39;);" target="_blank">aerogear-users-bounces@...] On Behalf Of Matthias Wessendorf
Sent: Wednesday, June 17, 2015 2:07 AM
To: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-users@lists.jboss.org&#39;);" target="_blank">aerogear-users@...
Subject: Re: [Aerogear-users] UPS load on startup

 

Hi Kevin,

 

thanks for the feedback! Here is what I did to reproduce your issue (w/o success):

 

* I have deployed UPS 1.0.2 into a (full profile) WF 8.2. 

* start the server (reset the admin password)

* create app and (dummy) variant (for Android), and noted the variantID:secret

* shutdown WF

* start WF

* did a curl agains the registration endpoint (got a 200)

* logged in, and seeing one device is registered.

 

Here is the CURL, I used (note the -u value ;-))

 

curl -u "variantID:secret" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"deviceToken" : "a152f21a-d327-4303-99d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1a152f21a-d327-4303-989d-7118c353eca1"}' http://127.0.0.1:8080/ag-push/rest/registry/device

 

 

That worked fine. My question is: does _this_ also generate you the 404 error? Or is that something you are "just" seeing from the AeroGear Registration SDK? (e.g. for Android/iOS or Cordova).

 

PS: the same 'test' passes with the 1.1.0-Final-SNAPSHOT build I did locally

 

Thanks!

Matthias

 

 

 

 

On Wed, Jun 17, 2015 at 3:31 AM, Kelvin Lunsford <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;kelvin@qantel.com&#39;);" target="_blank">kelvin@...> wrote:

I tried to add UPS logging by following the instructions in the UPS user guide but couldn't get it working.

This is what I see in the server.log file.

...

2015-06-16 15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
2015-06-16
15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
2015-06-16 15:49:52,284 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" started in 13573ms - Started 579 of 637 services (101 services are lazy, passive or on-demand)
2015-06-16 15:50:27,011 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ag-push/rest/registry/device: java.lang.RuntimeException: Unable to resolve realm public key remotely, status = 404
        at org.keycloak.adapters.AdapterDeploymentContext.resolveRealmKey(AdapterDeploymentContext.java:69) [keycloak-adapter-core-1.0.4.Final.jar:]
        at org.keycloak.adapters.AdapterDeploymentContext.resolveDeployment(AdapterDeploymentContext.java:55) [keycloak-adapter-core-1.0.4.Final.jar:]
        at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:54) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_71]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_71]
        at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_71]


The error occurs each time I try to do a registration after server restart, until I log into the UPS console, then the errors stop.

- Kelvin




----------------------------------------------------------------------------------

From: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-users-bounces@lists.jboss.org&#39;);" target="_blank">aerogear-users-bounces@... [mailto:<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-users-bounces@lists.jboss.org&#39;);" target="_blank">aerogear-users-bounces@...] On Behalf Of Matthias Wessendorf
Sent: Monday, June 15, 2015 4:10 AM

To: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-users@lists.jboss.org&#39;);" target="_blank">aerogear-users@...
Subject: Re: [Aerogear-users] UPS load on startup

Hi,

yes, openshift gets susspended after 48 hours (I think) of inactivity - but I think your error is different to Kevin's 

Kevin any chance to get a log file / stack-trace from the 500 ? 

Is that just on Android/Cordova, or does that also reproduce w/ doing (test) registration w/ curl, like:
https://aerogear.org/docs/specs/aerogear-unifiedpush-rest-1.0.x/registry/device/index.html#POST

Thanks

On Mon, Jun 15, 2015 at 12:29 PM, Alex Ballesté <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;alexandre.balleste@udl.cat&#39;);" target="_blank">alexandre.balleste@...> wrote:
Hi, I noticed the same behaviour in my aerogear test server, but I thought that was something related with openshift. If service is not used for a while seems like it become suspended until you access again.

I tried to reproduce restarting the server but I couldn't... Just found something in the logs this morning after 2 days without using it. (At 2:51 I sent the notification)

Log was
-----------------------------
2015/06/13 00:00:00,109 INFO  [GCMPushNotificationSender] (EJB default - 2) Deleting [&apos;0&apos;] outdated PushMessageInformation objects
2015/06/13 12:05:30,766 INFO  [org.jboss.as.osgi] (MSC service thread 1-5) JBAS011942: Stopping OSGi Framework
2015/06/15 02:51:14,161 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 35) JBAS016200: Activating ConfigAdmin Subsystem
2015/06/15 02:51:14,264 INFO  [org.jboss.as.jacorb] (ServerService Thread Pool -- 41) JBAS016300: Activating JacORB Subsystem
2015/06/15 02:51:14,356 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) JBAS013101: Activating Security Subsystem
2015/06/15 02:51:14,258 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 40) JBAS010280: Activating Infinispan subsystem.
...
...
-------------------------------------
   
It seem like on saturday 13 service was stopped. And started again on monday 16 at 2:51 (by my notification???) . I also got this error during the startup process

--------------------------
2015/06/15 02:51:46,443 INFO  [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] (MSC service thread 1-5) **** using /WEB-INF/keycloak.json
2015/06/15 02:51:46,760 INFO  [JPAPushMessageInformationDao] (EJB default - 2) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,951 INFO  [org.keycloak.services.resources.KeycloakApplication] (MSC service thread 1-1) Not importing realm aerogear from resource /WEB-INF/ups-realm.json.  It already exists.
2015/06/15 02:51:46,954 INFO  [JPAPushMessageInformationDao] (EJB default - 1) Deleting [&apos;2&apos;] outdated PushMessageInformation objects
2015/06/15 02:51:46,966 WARN  [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a21a655:16c5d4f8:557e75e5:f, <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@d8bbe6&#39;);" target="_blank"> org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@d8bbe6 >: javax.persistence.OptimisticLockException: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:1402) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1308) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1481) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:109) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
    at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
------------------------

Later another generated message at 2:57 was received an processed fine. I don't know if it's something related with hosting or with UPS. I'm running 1.0.2 too.

Sorry if this information is not relevant

Alex Ballesté

El 13/06/15 a les 08:01, Matthias Wessendorf ha escrit:
any chance of stack trace?

On Saturday, June 13, 2015, Kelvin Lunsford <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;kelvin@qantel.com&#39;);" target="_blank">kelvin@...> wrote:
I restarted Wildfly and I had to log into the UPS console to stop the registration errors.

The error callback for the plugin push.register() function returns the message "The server returned the error code 500".

- Kelvin



---------------------------------------------------------------------------

From: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-users-bounces@lists.jboss.org&#39;);" target="_blank">aerogear-users-bounces@... [mailto:<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-users-bounces@lists.jboss.org&#39;);" target="_blank">aerogear-users-bounces@...] On Behalf Of Matthias Wessendorf
Sent: Friday, June 12, 2015 12:01 AM
To: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-users@lists.jboss.org&#39;);" target="_blank">aerogear-users@...
Subject: Re: [Aerogear-users] UPS load on startup

hrm,

that's strange - not noticed so far.
Any details on the error message ? Is that reproducable w/ something like curl ? 

On Fri, Jun 12, 2015 at 3:05 AM, Kelvin Lunsford <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;kelvin@qantel.com&#39;);" target="_blank">kelvin@...> wrote:
I'm developing a mobile app and testing USP 1.0.2 on Wildfly 8.2.0.

Runs great but I've noticed that when the server is restarted registration requests from my mobile app fail until I try to access the ag-push console with a browser and bring up a login page.  Then registration works.

Anyone noticed this?

- Kelvin


_______________________________________________
Aerogear-users mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Aerogear-users@lists.jboss.org&#39;);" target="_blank">Aerogear-users@...
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Aerogear-users@lists.jboss.org&#39;);" target="_blank">Aerogear-users@...
https://lists.jboss.org/mailman/listinfo/aerogear-users


--
Sent from Gmail Mobile

_______________________________________________
Aerogear-users mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Aerogear-users@lists.jboss.org&#39;);" target="_blank">Aerogear-users@...
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
====================
Universitat de Lleida
Àrea de sistemes d'Informació i Comunicacions
Analista/Programador

University of Lleida
Information and Communication Systems Service

Tlf: <a href="tel:%2B34%20973%20702148" target="_blank">+34 973 702148
Fax: <a href="tel:%2B34%20973%20702130" target="_blank">+34 973 702130
=====================
Avís legal/Aviso legal/Avertiment legal/Legal notice

_______________________________________________
Aerogear-users mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Aerogear-users@lists.jboss.org&#39;);" target="_blank">Aerogear-users@...
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
Aerogear-users mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Aerogear-users@lists.jboss.org&#39;);" target="_blank">Aerogear-users@...
https://lists.jboss.org/mailman/listinfo/aerogear-users



 

--



--
Sent from Gmail Mobile

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Loading...