Activate changes in Oracle Service Bus does not work

When deploying services from  Oracle Service Bus (OSB) Console, and after when activate the  changes, this  fails ,showing the next message:

1

 

The background error descripted in log of AdminServer is the next:


com.bea.wli.config.deployment.server.ServerDeploymentConflictException

<15/07/2016 15h'56 ART> <Error> <ConfigFwk> <BEA-390101> <Fallo de activación de la sesión weblogic: com.bea.wli.config.deployment.server.ServerDeploymentConflictException: No se ha podido activar la sesión debido a un conflicto con otro trabajo en curso. Vuelva a intentarlo. com.bea.wli.config.deployment.server.ServerDeploymentConflictException: No se ha podido activar la sesión debido a un conflicto con otro trabajo en curso. Vuelva a intentarlo.         at com.bea.wli.config.deployment.server.ServerDeploymentInitiator.commitViaEditService(ServerDeploymentInitiator.java:603)         at com.bea.wli.config.deployment.server.ServerDeploymentInitiator.__serverCommit(ServerDeploymentInitiator.java:535)         at com.bea.wli.config.deployment.server.ServerDeploymentInitiator.access$200(ServerDeploymentInitiator.java:90)         at com.bea.wli.config.deployment.server.ServerDeploymentInitiator$1.run(ServerDeploymentInitiator.java:382)         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)         Truncated. see log file for complete stacktrace >
<15/07/2016 15h'56 ART> <Error> <ALSB Console> <BEA-494002> <Se ha producido un error interno en la consola de OSB: null java.lang.reflect.InvocationTargetException         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)         at java.lang.reflect.Method.invoke(Method.java:597)         at com.bea.alsb.console.support.ConsoleSideMBeanInvocationHandler.__invoke(ConsoleSideMBeanInvocationHandler.java:113)         Truncated. see log file for complete stacktrace Caused By: com.bea.wli.config.deployment.server.ServerDeploymentConflictException: No se ha podido activar la sesión debido a un conflicto con otro trabajo en curso. Vuelva a intentarlo.         at com.bea.wli.config.deployment.server.ServerDeploymentInitiator.commitViaEditService(ServerDeploymentInitiator.java:603)         at com.bea.wli.config.deployment.server.ServerDeploymentInitiator.__serverCommit(ServerDeploymentInitiator.java:535)         at com.bea.wli.config.deployment.server.ServerDeploymentInitiator.access$200(ServerDeploymentInitiator.java:90)         at com.bea.wli.config.deployment.server.ServerDeploymentInitiator$1.run(ServerDeploymentInitiator.java:382)         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)         Truncated. see log file for complete stacktrace >

 

The reason for this error, is the fact the OSB is configured for automatic apply of changes made OSB. This option is default in OSB 10gR3 and should be switched off. This can be done via the WLS console.

  • Logon to Console
  • Select Preferences
  • Uncheck the option “Automatically Acquire Lock and Activate Changes”:
  • Restart OSB nodes, and AdminServer

2

 

greats from Ecuador&Chile

BEA-000388 – JVM called WLS shutdown hook. The server will force shutdown now

Issue:

The WLS shuts down with the similar errors in log files:

<Apr 24, 2009 12:10:44 PM PDT> <Notice> <WebLogicServer> <BEA-000388> <JVM called WLS shutdown hook. The server will force shutdown now>

<Apr 24, 2009 12:10:44 PM PDT> <Alert> <WebLogicServer> <BEA-000396> <Server shutdown has been requested by <WLS Kernel>>

<Apr 24, 2009 12:10:44 PM PDT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN>

Possible Cause and Solution:

I have the following suggestion for you for the below error:

<Apr 24, 2009 12:10:44 PM PDT> <Notice> <WebLogicServer> <BEA-000388> <JVM called WLS shutdown hook. The server will force shutdown now>

1.) It seems like some component is sending the wrong signal to the JVM and this issue is occurring. JVM monitors and catches OS signals, like: CTRL +C event, Log off event, shutdown event.When JVM catches one of the stated above signals, it shutdowns all java processes.

Please try these possible solutions of this problem:

  • Specify -Xrs parameter in the JAVA startup arguments and start the admin server
  • -Xrs
  • Note: -Xrs is a non-standard option developed by Sun Microsystems for their HotSpot JVM. BEA JRockit continues to support this option; however the BEA JRockit non-standard option -XnoHup provides the same functionality. -Xrs reduces usage of operating-system signals by the JVM. If the JVM is run as a service (for example, the servlet engine for a web server), it can receive CTRL_LOGOFF_EVENT but should not initiate shutdown since the operating system will not actually terminate the process. To avoid possible interference such as this, the -Xrs command-line option does not install a console control handler, implying that it does not watch for or process CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, or CTRL_SHUTDOWN_EVENT Operation.

2.) If the issue recurs again even after trying the above option then can you please apply thefollowing JAVA_OPTION:

  • Depending on the JVM version, it may be possible to get a thread dump before the process exits
  • HotSpot supports the command-line option -XX:+ShowMessageBoxOnError
  • The corresponding JRockit option is -Djrockit.waitonerror
  • While the JVM< goes down, it may prompt the user: “Do you want to debug the problem?”
  • This pauses the JVM, thereby creating an opportunity to generate a thread dump (a stack trace of every thread in the JVM), attach a debugger, or perform some other debugging activity.

Chunked Streaming with http protocol on Oracle Service Bus 11g

He tenido la grata experiencia de trabajar con OSB y llevar muchas de mis soluciones a ambientes productivos en grandes fierros como Oracle Exalogic, una de mis experiencias que mas recuerdo es aquella en la cual casi siempre se caían o no respondían los servicios en OSB, acá les dejo el síntoma y la solución.

OSB

OSB

Antecedentes:

Se implemento cientos de servicios en OSB que permitían a uno de nuestros grandes clientes obtener una capa de integración entre sus nuevos canales y sus backends anticuados, todos los servicios se conectaban a servicios soap via http.

Debido a que en realidad la cantidad resultante de servicios por desarrollar rebasaban las 1000 proyectos osb, se decidió implementar una linea de fábrica que usando metadata obtenida en la etapa de análisis nos permita generar automáticamente todos los servicios OSB de manera “gratuita”, en fin el caso fue un éxito!, así que en teoría todos los servicios son similares o cumplen un patrón especifico de diseño.

El problema:

Una vez deployados en OSB cada cierto tiempo obteníamos varios errores que estaban dentro de los siguientes tipos:

1. Client requests get a read timed out error

2. The BEA-380000 error “Request Entity Too Large” appears in the logs

Explicación:

Los desarrolladores de los canales o el administrador del sistema siempre estaban reportando:”Los servicios no siempre estan disponibles”, “Es culpa de la red”, “Existente intermitencia en la respuesta de los servicios osb o de backend”.

El gran causante era que los servicios de negocio http en OSB tenían activado el modo “chunked streaming”.

Pero porque?

De acuerdo a la documentación Chunked streaming Mode permite a la los clientes analizar dinamicamente la data inmediatamente despues de leer el primer “fragmento” recibido, esto suele ser muy eficaz, sin embargo  Oracle menciona ademas que no debe usarse este modo cuando se usa la opción “Folow HTTP Redirects option”, pero en este caso todos los servicios tenia desactivado esta última opción, sin embargo debido a que los servicios de backend estaban en un cluster habiamos decidido usar Oracle Http Server para “canonizar” la url de estos servicios, lo cual forma la receta ideal para obtener una problemática como la comentada

La solución fue desactivar el modo “chunked streaming” en todos los servicios de negocio http desplegados en OSB, obteniendo grandes resultados

saludos cordiales

 

 

 

 

Error on log4.xml : The content of element type “log4j:configuration” must match “(renderer*,throwableRenderer?,appender*,plugin*,(category|logger)*,root?,(categoryFactory|loggerFactory)?)

Error:

The content of element type “log4j:configuration” must match “(renderer*,throwableRenderer?,appender*,plugin*,(category|logger)*,root?,(categoryFactory|loggerFactory)?)

If your application is logging the following:

log4j:WARN The content of element type "log4j:configuration" must match "(renderer*,throwableRenderer?,appender*,plugin*,(category|logger)*,root?,(categoryFactory|loggerFactory)?)"

The reason is that your log4j.xml is not having the element tags in proper order. They should be in the order as indicated by the warning message:

renderer
throwableRenderer
appender
plugin
category OR logger
root
categoryFactory OR loggerFactory

In my log4j.xml I wasn’t having logger element before the root element which was causing this warning to be printed out.

 

de Ricardo R Publicado en ADF, java