Concurrent GC Behavior?

We are testing the use of Coherence in an 8 machine cluster where incoming requests can come to any node and get distributed by the invocable map interface to be updated on any other node in a distributed cache. When I set all 8 nodes to use concurrent GC and parallel collection (-Xmx1024m -Xms1024m -server -XX:+UseParNewGC -XX:+UseConcMarkSweepGC) the nodes have a 50-60% CPU overhead (x 2 cores means that more than 1 core is used by the process at all time!) except for the one node that gets few requests (it has about 30% CPU overhead).
Now the odd thing is this: I restarted one node using the classic GC behavior (just -Xmx1024m -Xms1024m -server) and... all the other nodes quickly dropped to almost zero CPU overhead, but that one node was at 50% CPU overhead. When I restarted it again with the parallel and concurrent GC settings, the other nodes picked up to 60% overhead (30% for the non-request node) and the restarted node hit 40% overhead. This is with a 32 bit Sun 1.5.0_11 vm on Linux.
I'm wondering what explains this behavior, how Tangosol responds to parallel and concurrent GC, and if there are guidelines for tuning GC that are particular to Tangosol. Also, this level of overhead does seem high to me, granting that the system hasn't been tuned yet. The servers are processing about 400 updates per second each, so about 3000 updates per second in total. What ballpark of CPU overhead on a modern Linux server would you expect to see?
Thanks,
Ron

I actually had already size limited the cache, with the maximum memory for the front of the distributed cache to 256 mb (i.e., the serialized data should be 1/4 of max heap size), using the simple disk spillover storage. A couple of other observations:
* when running all nodes with the concurrent collector, the system eventually settles down so that 1 core of 1 node is pegged and all other nodes are basically free. I've included a stack trace below
* We restarted our cluster yesterday and JMX data on that node shows:
- the one busy node has burned 19 hours 43 minutes of CPU.
- The ConcurrentMarkSweep collector has run 0 times using 0 seconds
- The ParNew collector has run 68000 times using 16 minutes
- The process heap has grown to 832 million bytes, less than the 1048 million byte maximum allowed, so it clearly isn't running out of memory
- Cache hits: 44000
- Cache misses: 36000
- Cache misses millis: 25
- Packets sent: 3.7 million
- PublisherSuccessRate: .9985
- ReceiverSuccessRate: .9990
- PacketPublisher Cpu 70126ms (0.1%)
Sometimes we see big spikes in network activity after a node goes up or down (e.g., we had 4 hours of 20 mb/s) but in this mode we are seeing extremely low network activity (basically no increase over the level we'd see without this process running)
Here's a sample thread dump on the busy node. Any idea why the CPU is pegged? The call to size() was a debugging call which we're removing to avoid any influence from that. We are seeing that these size calls aren't terminating, which itself is surprising to me.
Full thread dump Java HotSpot(TM) Server VM (1.5.0_11-b03 mixed mode):
"Thread-64" prio=1 tid=0x080cd298 nid=0x5703 waiting on condition [0xa5669000..0
xa566a050]
at java.lang.Thread.sleep(Native Method)
at com.quantcast.distiller.PixelLogReaderThread.run(PixelLogReaderThread
.java:76)
"Thread-63" prio=1 tid=0x080cb3b8 nid=0x56fa waiting for monitor entry [0xa56ea0
00..0xa56eafd0]
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.calculateOldestSUID(Service.CDB:6)
- waiting to lock <0xae065260> (a com.tangosol.util.SparseArray)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.getOldestPendingRequestSUID(Service.CDB:1)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache.createRequestContext(DistributedCache.CDB:6)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache$BinaryMap.invoke(DistributedCache.CDB:8)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache$ViewMap.invoke(DistributedCache.CDB:15)
at com.tangosol.coherence.component.util.SafeNamedCache.invoke(SafeNamedCache.CDB:1)
<our code>
[about 30-40 threads blocked like this]
"Thread-9" prio=1 tid=0x08a208f0 nid=0x786e waiting for monitor entry [0xa79fc00
0..0xa79fd0d0]
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.calculateOldestSUID(Service.CDB:6)
- waiting to lock <0xae065260> (a com.tangosol.util.SparseArray)
"Thread-8" prio=1 tid=0x085323c0 nid=0x6ecf in Object.wait() [0xa8efe000..0xa8ef
f050]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.p
oll(Service.CDB:31)
- locked <0xb88e7890> (a com.tangosol.coherence.component.net.message.re
questMessage.DistributedCacheKeyRequest$Poll)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.p
oll(Service.CDB:18)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.D
istributedCache$BinaryMap.invoke(DistributedCache.CDB:35)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.D
istributedCache$ViewMap.invoke(DistributedCache.CDB:15)
at com.tangosol.coherence.component.util.SafeNamedCache.invoke(SafeNamed
Cache.CDB:1)
<our code>
(thread 6 looks like thread 8)
"Thread-5" prio=1 tid=0x08a19488 nid=0x6701 runnable [0xa8196000..0xa8196ed0]
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0xadfbe970> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at com.sun.jmx.remote.socket.SocketConnectionServer.accept(SocketConnect
ionServer.java:213)
at com.sun.jmx.remote.generic.SynchroMessageConnectionServerImpl.accept(
SynchroMessageConnectionServerImpl.java:87)
at javax.management.remote.generic.GenericConnectorServer$Receiver.run(G
enericConnectorServer.java:380)
"Timer-2" daemon prio=1 tid=0x08661ad8 nid=0x6700 in Object.wait() [0xa85ae000..
0xa85aee50]
at java.lang.Object.wait(Native Method)
- waiting on <0xafe77e38> (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:474)
at java.util.TimerThread.mainLoop(Timer.java:483)
- locked <0xafe77e38> (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:462)
"Timer-1" prio=1 tid=0x0865fe98 nid=0x66ff in Object.wait() [0xa87f8000..0xa87f9
1d0]
at java.lang.Object.wait(Native Method)
- waiting on <0xcf2e9560> (a java.util.HashSet)
at java.lang.Object.wait(Object.java:474)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache$BinaryMap.waitPolls(DistributedCache.CDB:17)
- locked <0xcf2e9560> (a java.util.HashSet)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache$BinaryMap.sendPartitionedRequest(DistributedCache.CDB:110)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache$BinaryMap.size(DistributedCache.CDB:13)
at com.tangosol.util.ConverterCollections$ConverterMap.size(ConverterCollections.java:1248)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache$ViewMap.size(DistributedCache.CDB:1)
at com.tangosol.coherence.component.util.SafeNamedCache.size(SafeNamedCache.CDB:1)
at com.quantcast.realtime.user.DefaultUserProfileService.logStatistics(DefaultUserProfileService.java:228)
at com.quantcast.realtime.user.DefaultUserProfileService.setOutFile(DefaultUserProfileService.java:203)
at com.quantcast.distiller.LogRoller$RollTimerTask.run(LogRoller.java:29
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
"DistributedCache" daemon prio=1 tid=0xa8f69eb8 nid=0x66fe runnable [0xa8cfa000.
.0xa8cfb150]
at com.tangosol.util.SparseArray.iterator(SparseArray.java:589)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.u
nregisterRequestInfoRange(Service.CDB:12)
- locked <0xae065260> (a com.tangosol.util.SparseArray)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache.onInvokeRequest(DistributedCache.CDB:21)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache$InvokeRequest.run(DistributedCache.CDB:1)
at com.tangosol.coherence.component.net.message.requestMessage.DistributedCacheKeyRequest.onReceived(DistributedCacheKeyRequest.CDB:16)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.onMessage(Service.CDB:9)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.onNotify(Service.CDB:123)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache.onNotify(DistributedCache.CDB:3)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:35)
at java.lang.Thread.run(Thread.java:595)
"Invocation:Management" daemon prio=1 tid=0xa8b082f8 nid=0x66fd in Object.wait()
[0xa8d7b000..0xa8d7c0d0]
at java.lang.Object.wait(Native Method)
at com.tangosol.coherence.component.util.Daemon.onWait(Daemon.CDB:11)
- locked <0xadc280c8> (a com.tangosol.coherence.component.util.queue.con
currentQueue.DualQueue)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.o
nWait(Service.CDB:2)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:32)
"Invocation:Management:EventDispatcher" daemon prio=1 tid=0xa8b03f98 nid=0x66fc
in Object.wait() [0xa8dfc000..0xa8dfd050]
at java.lang.Object.wait(Native Method)
at com.tangosol.coherence.component.util.Daemon.onWait(Daemon.CDB:11)
- locked <0xadf2f640> (a com.tangosol.coherence.component.util.daemon.queueProcessor.Service$EventDispatcher$Queue)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:32)
at java.lang.Thread.run(Thread.java:595)
"TcpRingListener" daemon prio=1 tid=0xa8b03890 nid=0x66fb runnable [0xa8e7d000..
0xa8e7dfd0]
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0xadc2c8c8> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at com.tangosol.coherence.component.net.socket.TcpSocketAccepter.accept(TcpSocketAccepter.CDB:18)
at com.tangosol.coherence.component.util.daemon.TcpRingListener.acceptConnection(TcpRingListener.CDB:10)
at com.tangosol.coherence.component.util.daemon.TcpRingListener.onNotify(TcpRingListener.CDB:1)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:35)
at java.lang.Thread.run(Thread.java:595)
"Cluster" daemon prio=1 tid=0xa8b024a0 nid=0x66f9 in Object.wait() [0xa8879000..0xa8879ed0]
at java.lang.Object.wait(Native Method)
at com.tangosol.coherence.component.util.Daemon.onWait(Daemon.CDB:11)
- locked <0xadc276f8> (a com.tangosol.coherence.component.util.queue.concurrentQueue.DualQueue)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.onWait(Service.CDB:2)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:32)
at java.lang.Thread.run(Thread.java:595)
"PacketSpeaker" daemon prio=1 tid=0xa8b058d0 nid=0x66f8 in Object.wait() [0xa88fa000..0xa88fae50]
at java.lang.Object.wait(Native Method)
- waiting on <0xadc39998> (a com.tangosol.coherence.component.net.Cluster$PacketSpeaker$BundlingQueue)
at com.tangosol.coherence.component.util.queue.ConcurrentQueue.waitForEntry(ConcurrentQueue.CDB:16)
- locked <0xadc39998> (a com.tangosol.coherence.component.net.Cluster$PacketSpeaker$BundlingQueue)
at com.tangosol.coherence.component.util.queue.ConcurrentQueue.remove(ConcurrentQueue.CDB:10)
at com.tangosol.coherence.component.util.daemon.queueProcessor.packetProcessor.PacketSpeaker.onNotify(PacketSpeaker.CDB:62)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:35)
at java.lang.Thread.run(Thread.java:595)
"PacketPublisher" daemon prio=1 tid=0xa8b052f8 nid=0x66f7 in Object.wait() [0xa897c000..0xa897c1d0]
at java.lang.Object.wait(Native Method)
at com.tangosol.coherence.component.util.Daemon.onWait(Daemon.CDB:11)
- locked <0xadc78e50> (a com.tangosol.coherence.component.net.Cluster$PacketPublisher$InQueue)
at com.tangosol.coherence.component.util.daemon.queueProcessor.packetProcessor.PacketPublisher.onWait(PacketPublisher.CDB:2)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:32)
at java.lang.Thread.run(Thread.java:595)
"PacketReceiver" daemon prio=1 tid=0xa8b04d50 nid=0x66f6 in Object.wait() [0xa89fc000..0xa89fd150]
at java.lang.Object.wait(Native Method)
at com.tangosol.coherence.component.util.Daemon.onWait(Daemon.CDB:11)
- locked <0xaded3f10> (a com.tangosol.coherence.component.net.Cluster$PacketReceiver$InQueue)
at com.tangosol.coherence.component.util.daemon.queueProcessor.packetProcessor.PacketReceiver.onWait(PacketReceiver.CDB:2)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:32)
at java.lang.Thread.run(Thread.java:595)
"PacketListener1" daemon prio=1 tid=0xa8b04878 nid=0x66f5 runnable [0xa8a7d000..0xa8a7e0d0]
at java.net.PlainDatagramSocketImpl.receive0(Native Method)
at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
- locked <0xadeddb48> (a java.net.PlainDatagramSocketImpl)
at java.net.DatagramSocket.receive(DatagramSocket.java:712)
- locked <0xae13ef20> (a java.net.DatagramPacket)
- locked <0xadf01940> (a java.net.DatagramSocket)
at com.tangosol.coherence.component.net.socket.UdpSocket.receive(UdpSocket.CDB:20)
at com.tangosol.coherence.component.net.UdpPacket.receive(UdpPacket.CDB:4)
at com.tangosol.coherence.component.util.daemon.queueProcessor.packetProcessor.PacketListener.onNotify(PacketListener.CDB:19)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:35)
at java.lang.Thread.run(Thread.java:595)
"PacketListenerN" daemon prio=1 tid=0xa8b043f0 nid=0x66f4 runnable [0xa8afe000..0xa8aff050]
at java.net.PlainDatagramSocketImpl.receive0(Native Method)
at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
- locked <0xadeddb88> (a java.net.PlainDatagramSocketImpl)
at java.net.DatagramSocket.receive(DatagramSocket.java:712)
- locked <0xae109460> (a java.net.DatagramPacket)
- locked <0xadf00230> (a java.net.MulticastSocket)
at com.tangosol.coherence.component.net.socket.UdpSocket.receive(UdpSocket.CDB:20)
at com.tangosol.coherence.component.net.UdpPacket.receive(UdpPacket.CDB:
4)
at com.tangosol.coherence.component.util.daemon.queueProcessor.packetProcessor.PacketListener.onNotify(PacketListener.CDB:19)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:35)
at java.lang.Thread.run(Thread.java:595)
"Logger@9263394 3.3/387" daemon prio=1 tid=0xa95c0578 nid=0x66f3 in Object.wait() [0xa90a5000..0xa90a5fd0]
at java.lang.Object.wait(Native Method)
at com.tangosol.coherence.component.util.Daemon.onWait(Daemon.CDB:11)
- locked <0xadc59e58> (a com.tangosol.coherence.component.application.console.Coherence$Logger$Queue)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:32)
at java.lang.Thread.run(Thread.java:595)
"RMI TCP Accept-0" daemon prio=1 tid=0xa95b71d8 nid=0x66f1 runnable [0xa91a7000..0xa91a7ed0]
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0xadc21fb8> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:340)
at java.lang.Thread.run(Thread.java:595)
"Timer-0" daemon prio=1 tid=0xa95b5558 nid=0x66f0 in Object.wait() [0xa9228000..0xa9228e50]
at java.lang.Object.wait(Native Method)
- waiting on <0xadc23b10> (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:474)
at java.util.TimerThread.mainLoop(Timer.java:483)
- locked <0xadc23b10> (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:462)
"Low Memory Detector" daemon prio=1 tid=0x0813bd50 nid=0x66ef runnable [0x00000000..0x00000000]
"CompilerThread1" daemon prio=1 tid=0x0813a878 nid=0x66ee waiting on condition [0x00000000..0xaa3b2378]
"CompilerThread0" daemon prio=1 tid=0x081397c8 nid=0x66ed waiting on condition [0x00000000..0xaa4332f8]
"AdapterThread" daemon prio=1 tid=0x08138648 nid=0x66ec waiting on condition [0x00000000..0x00000000]
"Signal Dispatcher" daemon prio=1 tid=0x081376a0 nid=0x66eb waiting on condition [0x00000000..0x00000000]
"Surrogate Locker Thread (CMS)" daemon prio=1 tid=0x08136910 nid=0x66ea waiting on condition [0x00000000..0xaa5b70fc]
"Finalizer" daemon prio=1 tid=0x0812c0b8 nid=0x66e9 in Object.wait() [0xaa837000..0xaa837ed0]
at java.lang.Object.wait(Native Method)
- waiting on <0xadc23b20> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked <0xadc23b20> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=1 tid=0x0812bbb8 nid=0x66e8 in Object.wait() [0x
aa8b8000..0xaa8b8e50]
at java.lang.Object.wait(Native Method)
- waiting on <0xadc23b30> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0xadc23b30> (a java.lang.ref.Reference$Lock)
"main" prio=1 tid=0x0805db58 nid=0x66e3 waiting on condition [0xfff9d000..0xfff9d3f8]
at java.lang.Thread.sleep(Native Method)
<oiur code>
"VM Thread" prio=1 tid=0x08129698 nid=0x66e7 runnable
"Gang worker#0 (Parallel GC Threads)" prio=1 tid=0x0806d000 nid=0x66e4 runnable
"Gang worker#1 (Parallel GC Threads)" prio=1 tid=0x0806dc48 nid=0x66e5 runnable
"Concurrent Mark-Sweep GC Thread#0" prio=1 tid=0x080b0a68 nid=0x66e6 runnable
"VM Periodic Task Thread" prio=1 tid=0xa95bafd8 nid=0x66f2 waiting on condition

Similar Messages

Thoughts on adding ConcurrentMap methods to StoredMap?

as far as i can tell, StoredMap has the potential to implement the extra methods in the jdk 1.5 ConcurrentMap interface. Database already has a putNoOverwrite method which would be the implementation of putIfAbsent. Personally, however, i am more interested in the other methods, all of which basically do their work only if the current value matches a given old value. this enables safe concurrent updates to a StoredMap even outside of transactions, basically using an optimistic scenario:
- read existing key,value (hold no locks)
- copy current value and modify the copy
- write modified value only if current value matches what is now in the database (this line within the context of a RMW lock)
any idea if this could be incorporated in the je codebase anytime soon? i may end up implementing it in our codebase, although the je api is not easy to extend as most classes/useful methods are package protected (arg!).

hey,
just wanted to follow up on this a little. after using the concurrent implementation for a while (with transactions enabled), i experimented with extending the api to add a "transaction-like" extension to the concurrentmap api. this basically blends the concurrentmap api with the option of better performance when transactions are enabled in the underlying bdb. there are three methods added, which basically allow for "locking" a given key and "committing" or "rolling back" the updates as appropriate (if transactions are not enabled, the new methods are largely no-ops, and you get normal concurrent map behavior). thought i'd post the new code in case you were interested in providing this facility to other users (or, you could just stick with the original version posted above).
Example usage:
Object key;
try {
Object value = map.getForUpdate(key);
// ... run concurrent ops on value ...
map.replace(key, value, newValue);
map.completeUpdate(key);
} finally {
map.closeUpdate(key);
}New implementation:
public class StoredConcurrentMap extends StoredMap
private final ThreadLocal<UpdateState> _updateState =
    new ThreadLocal<UpdateState>();
public StoredConcurrentMap(
      Database database, EntryBinding keyBinding,
      EntryBinding valueEntityBinding, boolean writeAllowed)
    super(database, keyBinding, valueEntityBinding, writeAllowed);
public Object getForUpdate(Object key)
    if(_updateState.get() != null) {
      throw new IllegalStateException(
          "previous update still outstanding for key " +
          _updateState.get()._key);
    UpdateState updateState = new UpdateState(key, beginAutoCommit());
    _updateState.set(updateState);
    DataCursor cursor = null;
    Object value = null;
    try {
      cursor = new DataCursor(view, true, key);
      if(OperationStatus.SUCCESS == cursor.getNextNoDup(true)) {
        // takeover ownership of the cursor
        value = updateState.loadCurrentValue(cursor);
        cursor = null;
      closeCursor(cursor);
    } catch (Exception e) {
      closeCursor(cursor);
      throw handleException(e, false);
    return value;
public void completeUpdate(Object key)
    UpdateState updateState = getUpdateState(key);
    if(updateState != null) {
      try {
        updateState.clearCurrentValue(this);
        commitAutoCommit(updateState._doAutoCommit);
        // only clear the reference if everything succeeds
        _updateState.set(null);
      } catch(DatabaseException e) {
        throw new RuntimeExceptionWrapper(e);
public void closeUpdate(Object key)
    UpdateState updateState = getUpdateState(key);
    if(updateState != null) {
      // this op failed, abort (clear the reference regardless of what happens
      // below)
      _updateState.set(null);
      try {
        updateState.clearCurrentValue(this);
        view.getCurrentTxn().abortTransaction();
      } catch(DatabaseException ignored) {
public Object putIfAbsent(Object key, Object value)
    UpdateState updateState = getUpdateState(key);
    if(valueExists(updateState)) {
      return updateState._curValue;
    Object oldValue = null;
    DataCursor cursor = null;
    boolean doAutoCommit = beginAutoCommit();
    try {
      cursor = new DataCursor(view, true);
      while(true) {
        if(OperationStatus.SUCCESS ==
           cursor.putNoOverwrite(key, value, false)) {
          // we succeeded
          break;
        } else if(OperationStatus.SUCCESS ==
                  cursor.getSearchKey(key, null, false)) {
          // someone else beat us to it
          oldValue = cursor.getCurrentValue();
          break;
        // we couldn't put and we couldn't get, try again
      closeCursor(cursor);
      commitAutoCommit(doAutoCommit);
    } catch (Exception e) {
      closeCursor(cursor);
      throw handleException(e, doAutoCommit);
    return oldValue;
public boolean remove(Object key, Object value)
    UpdateState updateState = getUpdateState(key);
    if(valueExists(updateState)) {
      if(ObjectUtils.equals(updateState._curValue, value)) {
        try {
          updateState._cursor.delete();
          updateState.clearCurrentValue(this);
          return true;
        } catch (Exception e) {
          throw handleException(e, false);
      } else {
        return false;
    boolean removed = false;
    DataCursor cursor = null;
    boolean doAutoCommit = beginAutoCommit();
    try {
      cursor = new DataCursor(view, true, key);
      if(OperationStatus.SUCCESS == cursor.getNextNoDup(true)) {
        Object curValue = cursor.getCurrentValue();
        if(ObjectUtils.equals(curValue, value)) {
          cursor.delete();
          removed = true;
      closeCursor(cursor);
      commitAutoCommit(doAutoCommit);
    } catch (Exception e) {
      closeCursor(cursor);
      throw handleException(e, doAutoCommit);
    return removed;
public boolean replace(Object key, Object oldValue, Object newValue)
    UpdateState updateState = getUpdateState(key);
    if(valueExists(updateState)) {
      if(ObjectUtils.equals(updateState._curValue, oldValue)) {
        try {
          updateState.replaceCurrentValue(newValue);
          return true;
        } catch (Exception e) {
          throw handleException(e, false);
      } else {
        return false;
    boolean replaced = false;
    DataCursor cursor = null;
    boolean doAutoCommit = beginAutoCommit();
    try {
      cursor = new DataCursor(view, true, key);
      if(OperationStatus.SUCCESS == cursor.getNextNoDup(true)) {
        Object curValue = cursor.getCurrentValue();
        if(ObjectUtils.equals(curValue, oldValue)) {
          cursor.putCurrent(newValue);
          replaced = true;
      closeCursor(cursor);
      commitAutoCommit(doAutoCommit);
    } catch (Exception e) {
      closeCursor(cursor);
      throw handleException(e, doAutoCommit);
    return replaced;
public Object replace(Object key, Object value)
    UpdateState updateState = getUpdateState(key);
    if(valueExists(updateState)) {
      try {
        return updateState.replaceCurrentValue(value);
      } catch (Exception e) {
        throw handleException(e, false);
    Object curValue = null;
    DataCursor cursor = null;
    boolean doAutoCommit = beginAutoCommit();
    try {
      cursor = new DataCursor(view, true, key);
      if(OperationStatus.SUCCESS == cursor.getNextNoDup(true)) {
        curValue = cursor.getCurrentValue();
        cursor.putCurrent(value);
      closeCursor(cursor);
      commitAutoCommit(doAutoCommit);
    } catch (Exception e) {
      closeCursor(cursor);
      throw handleException(e, doAutoCommit);
    return curValue;
   * @return the current UpdateState for the given key, if any, {@code null}
   *         otherwise.
private UpdateState getUpdateState(Object key)
    UpdateState updateState = _updateState.get();
    if((updateState != null) && (ObjectUtils.equals(updateState._key, key))) {
      return updateState;
    return null;
   * @return {@code true} if the update state exists and found a value (which
   *         is currently locked)
private boolean valueExists(UpdateState updateState)
    return((updateState != null) && (updateState._cursor != null));
   * Maintains state about an object loaded in a
   * {@link StoredConcurrentMap#getForUpdate} call.
private static class UpdateState
    public final Object _key;
    public final boolean _doAutoCommit;
    public DataCursor _cursor;
    public Object _curValue;
    private UpdateState(Object key, boolean doAutoCommit) {
      _key = key;
      _doAutoCommit = doAutoCommit;
     * Loads the current value from the given cursor, and maintains a
     * reference to the given cursor and the loaded value.
    public Object loadCurrentValue(DataCursor cursor)
      throws DatabaseException
      _cursor = cursor;
      _curValue = _cursor.getCurrentValue();
      return _curValue;
     * Replaces the current value in the current cursor with the given value.
     * @return the old value
    public Object replaceCurrentValue(Object newValue)
      throws DatabaseException
      Object oldValue = _curValue;
      _cursor.putCurrent(newValue);
      _curValue = newValue;
      return oldValue;
     * Closes the current curstor and clears the references to the cursor and
     * current value.
    public void clearCurrentValue(StoredConcurrentMap map) {
      try {
        map.closeCursor(_cursor);
      } finally {
        _cursor = null;
        _curValue = null;
}

Concurrent behavior of DB adapter on SOA 10g Cluster

Hi all,
We have currently setup SOA 10g(10.1.3.5.2) cluster.According to Oracle documentation other than File/FTP adapters all other adapters behave concurrently i.e; we can have these adapters in active-active topology in the cluster.
Now we have a built a sample ESB project with inbound DB adapter and two routing rules.One invoking a BPEL process and another creating a File.
We have the DB adapter in active-active mode.Now at runtime when we insert some record into a table polled by the above DB adapter, we find that duplicate BPEL instances are created and duplicate files get created(on both application hosts).
However if I change the active-active topology of the adapter into active-passive topology by inserting clusterGroupId property on endpoint of the adapter then only a single BPEL instance and single File is created.
Please let us know how we can achieve the above with active-active mode of the adapters.
Thnks & Rgds,
Mandrita

Hi Anuj,
Thanks for your response. However when we enabling distributed polling then we find that the behavior is not consistent.
I am explaining the inconsistency below-
When ESB_DT with service-weight=100 is up then ESB to BPEL invocation(SOAP) creates duplicate BPEL instances but when I shutdown that ESB_DT and the other ESB_DT with service-weight = 50 goes up then we find that duplicate BPEL instances are not getting created.
So is this a default behavior i.e; active-active topology behavior is not consistent?
Thnks & Rgds,
Mandrita

RMI behavior in concurrent connections

hello guys!
I would like to know if a rmi application open more then one port if necessary when it need to handle many concurrent connection. Cause i've seen in JVM logs it handle a lot of threads but i don't know if in every thread it's the same port or it's create a new one.
I mean there's a entry point port for example 1099 but at low level JVM opens any other port. Is that thuth or i am completely lost
thanks for any comments
endyamon

RMI accepts multiple concurrent connections and despatches them all in separate threads.
TCP/IP gives all accepted sockets the same port number as the listening socket.
So the answer is yes and yes.

Jump in Young GG (ParNew) times after CMS-concurrent-reset

In one of our automated test scenarios following a CMS-concurrent-reset, young GC times dramatically increased. For instance, prior to the CMS reset, average young GC times average 0.15 seconds; after the CMS reset, times would spike to as high as 40 seconds. With our high-load scenario this does not happen. The difference in data load between these two tests is approximately 360:1.
Usually when this occcurs, the young GC times would stay consistently high (between 30 and 40 seconds). However, in one of our most recent test runs, something else happened. Young GC times would spike and then over a period of time gradually decrease back down to tolerable levels (over a period of 3.5+ hours). The log snippet below illustrates this behavior.
The application itself is a custom server built on Java 1.5.0_06 using Java 1.5.0_06erdist1. The hardware is a Dell PowerEdge 6800 running Windows 2003 Server 64-bit w/SP1. The server has 32GB of RAM, no swap file, and 8 logical CPU's (4 hyperthreaded Xeon processors). The system caches large amounts of data in a variety of strong, soft, and weak reference maps is using SleepyCat Software's DBJE for data storage.
We're working on getting memory dumps, but right now, we're thinking it might have something to do with large arrays in the old generation either being reallocated, or references back to the young generation that could be causing this. There is a slight possibility that there is also a large object being allocated in the young generation, although this seems like it is less likely (the average data packet is less than 1K in this test scenario and most object allocations are usually less than 4K in size -- byte arrays usually).
We're also looking at possibly testing with the latest 1.6 beta to see if the problem goes away, or at the very least we can profile the app when it gets into trouble without having to turn off CMS.
Does anybody have any thoughts on what might be causing this, or has anyone else run into something similar before?
The JVM Args used are:
-server
-Xms28G
-Xmx28G
-enableassertions
-XX:-UsePerfData
-XX:+PrintVMOptions
-XX:-TraceClassUnloading
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-verbose:gc
-XX:MaxTenuringThreshold=0
-XX:SurvivorRatio=20000
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+ParallelRefProcEnabled
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:ParallelGCThreads=7
-XX:NewSize=128M
-XX:MaxNewSize=128M
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-XX:CMSIncrementalDutyCycleMin=0
-XX:CMSIncrementalDutyCycle=10
-XX:CMSMarkStackSize=8M
-XX:CMSMarkStackSizeMax=32M
-XX:+UseLargePages
-XX:+DisableExplicitGC
64255.634: [GC 64255.634: [ParNew: 127304K->0K(131008K), 0.2955450 secs] 14370952K->14273019K(28671936K) icms_dc=0 , 0.2957102 secs]
64270.829: [GC 64270.829: [ParNew: 130944K->0K(131008K), 0.2805740 secs] 14403963K->14286161K(28671936K) icms_dc=0 , 0.2807523 secs]
64287.158: [GC 64287.158: [ParNew: 129676K->0K(131008K), 0.2908535 secs] 14415837K->14289089K(28671936K) icms_dc=0 , 0.2911033 secs]
64297.966: [GC 64297.966: [ParNew: 130602K->0K(131008K), 0.2682085 secs] 14419692K->14311368K(28671936K) icms_dc=0 , 0.2683754 secs]
64308.812: [GC 64308.812: [ParNew: 126613K->0K(131008K), 0.2965320 secs] 14437982K->14336914K(28671936K) icms_dc=0 , 0.2967070 secs]
64319.249: [GC 64319.249: [ParNew: 128966K->0K(131008K), 0.2878087 secs] 14465880K->14364326K(28671936K) icms_dc=3 , 0.2879923 secs]
64329.585: [GC [1 CMS-initial-mark: 14364326K(28540928K)] 14428075K(28671936K), 0.0367576 secs]
64329.622: [CMS-concurrent-mark-start]
64340.074: [GC 64340.074: [ParNew: 130758K->0K(131008K), 0.2824739 secs] 14495085K->14372339K(28671936K) icms_dc=3 , 0.2826438 secs]
64341.411: [CMS-concurrent-mark: 0.873/11.789 secs]
64341.411: [CMS-concurrent-preclean-start]
64341.411: [CMS-concurrent-preclean: 0.000/0.000 secs]
64341.557: [CMS-concurrent-abortable-preclean-start]
64341.557: [CMS-concurrent-abortable-preclean: 0.000/0.000 secs]
64350.684: [GC 64350.684: [ParNew: 130944K->0K(131008K), 0.2899810 secs] 14503283K->14395507K(28671936K) icms_dc=3 , 0.2901651 secs]
64363.365: [GC 64363.365: [ParNew: 130944K->0K(131008K), 0.2975003 secs] 14526451K->14421343K(28671936K) icms_dc=3 , 0.2976791 secs]
64372.076: [GC[YG occupancy: 83987 K (131008 K)]64372.076: [Rescan (parallel) , 0.0674530 secs]64372.144: [weak refs processing, 0.0308673 secs]64372.175: [class unloading[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor27]
64372.182: [scrub symbol & string tables, 0.0083922 secs] [1 CMS-remark: 14421343K(28540928K)] 14505331K(28671936K), 0.1281897 secs]
64372.206: [CMS-concurrent-sweep-start]
64376.703: [GC 64376.703: [ParNew: 130944K->0K(131008K), 0.3150279 secs] 14552287K->14443248K(28671936K) icms_dc=3 , 0.3152040 secs]
64393.182: [GC 64393.183: [ParNew: 130944K->0K(131008K), 0.2967053 secs] 14570664K->14441684K(28671936K) icms_dc=3 , 0.2968985 secs]
64395.855: [CMS-concurrent-sweep: 2.118/23.650 secs]
64395.856: [CMS-concurrent-reset-start]
64396.202: [CMS-concurrent-reset: 0.346/0.346 secs]
64404.846: [GC 64404.846: [ParNew: 130944K->0K(131008K), 11.8319372 secs] 452302K->326245K(28671936K) icms_dc=0 , 11.8321090 secs]
64420.865: [GC 64420.865: [ParNew: 130944K->0K(131008K), 11.8750319 secs] 457189K->352203K(28671936K) icms_dc=0 , 11.8752811 secs]
64435.536: [GC 64435.536: [ParNew: 130944K->0K(131008K), 11.8229769 secs] 483147K->374039K(28671936K) icms_dc=0 , 11.8231579 secs]
64448.564: [GC 64448.564: [ParNew: 130944K->0K(131008K), 12.2692927 secs] 504983K->376605K(28671936K) icms_dc=0 , 12.2694811 secs]
64462.276: [GC 64462.276: [ParNew: 130944K->0K(131008K), 12.0860714 secs] 507549K->401835K(28671936K) icms_dc=0 , 12.0862452 secs]
64478.522: [GC 64478.522: [ParNew: 126250K->0K(131008K), 12.3507999 secs] 528085K->428168K(28671936K) icms_dc=0 , 12.3509812 secs]
64492.047: [GC 64492.047: [ParNew: 130944K->0K(131008K), 11.7977262 secs] 559112K->450172K(28671936K) icms_dc=0 , 11.7979055 secs]
64505.333: [GC 64505.333: [ParNew: 130944K->0K(131008K), 11.6679971 secs] 581116K->475511K(28671936K) icms_dc=0 , 11.6681951 secs]
64523.377: [GC 64523.377: [ParNew: 130944K->0K(131008K), 12.1859479 secs] 606455K->496955K(28671936K) icms_dc=0 , 12.1861274 secs]
64537.004: [GC 64537.004: [ParNew: 130944K->0K(131008K), 12.3909395 secs] 627899K->500863K(28671936K) icms_dc=0 , 12.3911184 secs]
64550.836: [GC 64550.836: [ParNew: 130944K->0K(131008K), 13.3435750 secs] 631807K->522967K(28671936K) icms_dc=0 , 13.3437711 secs]
64565.421: [GC 64565.421: [ParNew: 130943K->0K(131008K), 12.1759533 secs] 653910K->551883K(28671936K) icms_dc=0 , 12.1761337 secs]
64578.968: [GC 64578.968: [ParNew: 129670K->0K(131008K), 11.7518116 secs] 681553K->565967K(28671936K) icms_dc=0 , 11.7519997 secs]
64595.156: [GC 64595.156: [ParNew: 130944K->0K(131008K), 12.7430090 secs] 696911K->588549K(28671936K) icms_dc=0 , 12.7431996 secs]
64609.154: [GC 64609.155: [ParNew: 127642K->0K(131008K), 13.4122057 secs] 716191K->613789K(28671936K) icms_dc=0 , 13.4123919 secs]
64623.588: [GC 64623.588: [ParNew: 130934K->0K(131008K), 11.8692832 secs] 744723K->634958K(28671936K) icms_dc=0 , 11.8694631 secs]
64636.690: [GC 64636.690: [ParNew: 130944K->0K(131008K), 12.2170544 secs] 765902K->640533K(28671936K) icms_dc=0 , 12.2172308 secs]
64652.592: [GC 64652.592: [ParNew: 130153K->0K(131008K), 12.5039780 secs] 770687K->670050K(28671936K) icms_dc=0 , 12.5041652 secs]
64665.798: [GC 64665.798: [ParNew: 130944K->0K(131008K), 11.8129872 secs] 800994K->683828K(28671936K) icms_dc=0 , 11.8131695 secs]
64678.710: [GC 64678.710: [ParNew: 130944K->0K(131008K), 12.2518054 secs] 814772K->686723K(28671936K) icms_dc=0 , 12.2519837 secs]
64692.491: [GC 64692.491: [ParNew: 128795K->0K(131008K), 12.4420712 secs] 815519K->711677K(28671936K) icms_dc=0 , 12.4422521 secs]
64706.761: [GC 64706.761: [ParNew: 130944K->0K(131008K), 12.1215915 secs] 842621K->733167K(28671936K) icms_dc=0 , 12.1217708 secs]
64720.486: [GC 64720.486: [ParNew: 130944K->0K(131008K), 12.4783432 secs] 864111K->736715K(28671936K) icms_dc=0 , 12.4785325 secs]
64734.374: [GC 64734.374: [ParNew: 129901K->0K(131008K), 12.6808484 secs] 866617K->763351K(28671936K) icms_dc=0 , 12.6810264 secs]
64748.544: [GC 64748.544: [ParNew: 130944K->0K(131008K), 13.0768090 secs] 894295K->772967K(28671936K) icms_dc=0 , 13.0769936 secs]
64762.836: [GC 64762.836: [ParNew: 130944K->0K(131008K), 12.6763159 secs] 903911K->797964K(28671936K) icms_dc=0 , 12.6764964 secs]
64777.255: [GC 64777.255: [ParNew: 125172K->0K(131008K), 11.3742001 secs] 923137K->823513K(28671936K) icms_dc=0 , 11.3743819 secs]
64789.913: [GC 64789.913: [ParNew: 130944K->0K(131008K), 12.6647870 secs] 954457K->845201K(28671936K) icms_dc=0 , 12.6649700 secs]
64803.944: [GC 64803.944: [ParNew: 127557K->0K(131008K), 12.4356678 secs] 972758K->870316K(28671936K) icms_dc=0 , 12.4358488 secs]
64818.674: [GC 64818.674: [ParNew: 130944K->0K(131008K), 12.1313661 secs] 1001260K->895535K(28671936K) icms_dc=0 , 12.1315657 secs]
64834.764: [GC 64834.764: [ParNew: 129555K->0K(131008K), 11.9518352 secs] 1025090K->925104K(28671936K) icms_dc=0 , 11.9520134 secs]
64848.138: [GC 64848.138: [ParNew: 130944K->0K(131008K), 12.9124929 secs] 1056048K->939587K(28671936K) icms_dc=0 , 12.9127034 secs]
64862.318: [GC 64862.318: [ParNew: 123806K->0K(131008K), 13.0569914 secs] 1063394K->964362K(28671936K) icms_dc=0 , 13.0571688 secs]
64877.530: [GC 64877.530: [ParNew: 130944K->0K(131008K), 12.3056353 secs] 1095306K->986163K(28671936K) icms_dc=0 , 12.3058150 secs]
64891.725: [GC 64891.725: [ParNew: 130944K->0K(131008K), 13.0376824 secs] 1117107K->1007903K(28671936K) icms_dc=0 , 13.0378846 secs]
76591.355: [GC 76591.355: [ParNew: 130944K->0K(131008K), 0.2791594 secs] 15265232K->15138597K(28671936K) icms_dc=0 , 0.2793572 secs]
76600.766: [GC 76600.766: [ParNew: 130944K->0K(131008K), 0.2752963 secs] 15269541K->15160685K(28671936K) icms_dc=0 , 0.2754887 secs]
76611.557: [GC 76611.557: [ParNew: 130944K->0K(131008K), 0.2790154 secs] 15291629K->15165049K(28671936K) icms_dc=0 , 0.2792048 secs]
76622.303: [GC 76622.303: [ParNew: 130944K->0K(131008K), 0.2849006 secs] 15295993K->15187817K(28671936K) icms_dc=0 , 0.2850920 secs]
76632.887: [GC 76632.887: [ParNew: 130944K->0K(131008K), 0.2689896 secs] 15318761K->15213844K(28671936K) icms_dc=0 , 0.2693092 secs]
76643.956: [GC 76643.956: [ParNew: 130879K->0K(131008K), 0.2662928 secs] 15344723K->15236015K(28671936K) icms_dc=0 , 0.2664782 secs]
76656.379: [GC 76656.379: [ParNew: 130944K->0K(131008K), 0.2872218 secs] 15366959K->15242404K(28671936K) icms_dc=0 , 0.2874433 secs]
76664.841: [GC 76664.841: [ParNew: 130868K->0K(131008K), 0.2931068 secs] 15373273K->15269283K(28671936K) icms_dc=0 , 0.2932965 secs]
76677.732: [GC 76677.732: [ParNew: 130920K->0K(131008K), 0.2475306 secs] 15400203K->15276884K(28671936K) icms_dc=0 , 0.2477292 secs]
76697.644: [GC 76697.644: [ParNew: 130944K->0K(131008K), 0.2879494 secs] 15407828K->15280611K(28671936K) icms_dc=0 , 0.2881359 secs]
76707.426: [GC 76707.426: [ParNew: 130944K->0K(131008K), 0.2911420 secs] 15411555K->15285072K(28671936K) icms_dc=0 , 0.2913233 secs]
76717.857: [GC 76717.857: [ParNew: 130944K->0K(131008K), 0.2701989 secs] 15416016K->15309374K(28671936K) icms_dc=0 , 0.2703928 secs]
76728.560: [GC 76728.561: [ParNew: 130944K->0K(131008K), 0.2931724 secs] 15440318K->15333673K(28671936K) icms_dc=0 , 0.2933609 secs]
76739.261: [GC 76739.262: [ParNew: 126315K->0K(131008K), 0.2973160 secs] 15459989K->15363224K(28671936K) icms_dc=0 , 0.2974960 secs]
76749.705: [GC 76749.705: [ParNew: 127396K->0K(131008K), 0.2972422 secs] 15490620K->15382987K(28671936K) icms_dc=0 , 0.2975240 secs]
76767.794: [GC 76767.794: [ParNew: 130944K->0K(131008K), 0.2838999 secs] 15513931K->15391591K(28671936K) icms_dc=0 , 0.2840901 secs]
76773.076: [GC 76773.076: [ParNew: 130944K->0K(131008K), 0.2552678 secs] 15522535K->15393025K(28671936K) icms_dc=0 , 0.2554467 secs]
76790.058: [GC 76790.058: [ParNew: 130860K->0K(131008K), 0.2934145 secs] 15523885K->15394843K(28671936K) icms_dc=0 , 0.2936080 secs]
76802.396: [GC 76802.396: [ParNew: 130604K->0K(131008K), 0.2972303 secs] 15525447K->15397713K(28671936K) icms_dc=0 , 0.2974271 secs]
76813.202: [GC 76813.202: [ParNew: 130169K->0K(131008K), 0.2880799 secs] 15527883K->15422970K(28671936K) icms_dc=0 , 0.2882746 secs]
76823.896: [GC 76823.896: [ParNew: 129924K->0K(131008K), 0.2832927 secs] 15552894K->15452588K(28671936K) icms_dc=0 , 0.2834869 secs]
76834.357: [GC 76834.358: [ParNew: 130767K->0K(131008K), 0.2764792 secs] 15583355K->15474140K(28671936K) icms_dc=0 , 0.2766770 secs]
76855.497: [GC 76855.497: [ParNew: 130897K->0K(131008K), 0.2894657 secs] 15605037K->15488217K(28671936K) icms_dc=0 , 0.2896626 secs]
76866.253: [GC 76866.253: [ParNew: 130944K->0K(131008K), 0.2999675 secs] 15619161K->15490659K(28671936K) icms_dc=0 , 0.3001493 secs]
76879.530: [GC 76879.530: [ParNew: 130944K->0K(131008K), 0.2816982 secs] 15621603K->15493104K(28671936K) icms_dc=0 , 0.2818897 secs]
76888.031: [GC 76888.031: [ParNew: 130944K->0K(131008K), 0.2760192 secs] 15624048K->15498672K(28671936K) icms_dc=0 , 0.2762118 secs]
76898.232: [GC 76898.232: [ParNew: 125483K->0K(131008K), 0.3109439 secs] 15624155K->15528482K(28671936K) icms_dc=0 , 0.3111342 secs]
76914.416: [GC 76914.416: [ParNew: 130944K->0K(131008K), 0.3065572 secs] 15659426K->15542745K(28671936K) icms_dc=0 , 0.3067479 secs]
76924.748: [GC 76924.748: [ParNew: 130883K->0K(131008K), 0.2937243 secs] 15673628K->15544088K(28671936K) icms_dc=0 , 0.2938988 secs]
76942.226: [GC 76942.226: [ParNew: 130944K->0K(131008K), 0.2960886 secs] 15675032K->15547980K(28671936K) icms_dc=0 , 0.2962779 secs]
76951.345: [GC 76951.345: [ParNew: 130944K->0K(131008K), 0.3050291 secs] 15678924K->15573683K(28671936K) icms_dc=0 , 0.3052196 secs]
76961.936: [GC 76961.936: [ParNew: 130944K->0K(131008K), 0.2914707 secs] 15704627K->15595952K(28671936K) icms_dc=0 , 0.2916589 secs]
76972.575: [GC 76972.575: [ParNew: 129330K->0K(131008K), 0.2838618 secs] 15725283K->15621207K(28671936K) icms_dc=0 , 0.2840550 secs]
76986.283: [GC 76986.284: [ParNew: 130939K->0K(131008K), 0.2933898 secs] 15752146K->15643239K(28671936K) icms_dc=0 , 0.2935624 secs]
76997.181: [GC 76997.181: [ParNew: 130944K->0K(131008K), 0.3075952 secs] 15774183K->15645463K(28671936K) icms_dc=0 , 0.3077828 secs]
77007.913: [GC 77007.913: [ParNew: 130944K->0K(131008K), 0.2958084 secs] 15776407K->15647422K(28671936K) icms_dc=0 , 0.2960437 secs]
77018.011: [GC 77018.011: [ParNew: 130910K->0K(131008K), 0.2964236 secs] 15778333K->15649978K(28671936K) icms_dc=0 , 0.2966224 secs]
77034.694: [GC 77034.694: [ParNew: 130944K->0K(131008K), 0.3092856 secs] 15780922K->15652024K(28671936K) icms_dc=0 , 0.3094763 secs]
77047.053: [GC 77047.054: [ParNew: 130944K->0K(131008K), 0.3015745 secs] 15782968K->15657359K(28671936K) icms_dc=0 , 0.3017561 secs]
77057.249: [GC 77057.249: [ParNew: 130944K->0K(131008K), 0.3185589 secs] 15788303K->15680967K(28671936K) icms_dc=0 , 0.3188166 secs]
77070.581: [GC 77070.581: [ParNew: 130944K->0K(131008K), 0.3062147 secs] 15811911K->15706444K(28671936K) icms_dc=0 , 0.3064015 secs]
77078.801: [GC 77078.801: [ParNew: 123632K->0K(131008K), 0.3221894 secs] 15830077K->15732164K(28671936K) icms_dc=0 , 0.3223794 secs]
77092.282: [GC 77092.282: [ParNew: 130944K->0K(131008K), 0.3141997 secs] 15863108K->15754279K(28671936K) icms_dc=0 , 0.3143788 secs]
77104.965: [GC 77104.965: [ParNew: 130936K->0K(131008K), 0.2957323 secs] 15885215K->15756444K(28671936K) icms_dc=0 , 0.2959160 secs]
77120.762: [GC 77120.762: [ParNew: 130944K->0K(131008K), 0.2967338 secs] 15887388K->15759133K(28671936K) icms_dc=0 , 0.2969243 secs]
77125.566: [GC 77125.566: [ParNew: 130944K->0K(131008K), 0.3192459 secs] 15890077K->15761500K(28671936K) icms_dc=0 , 0.3194239 secs]
77134.280: [GC 77134.280: [ParNew: 130930K->0K(131008K), 0.3128382 secs] 15892430K->15763820K(28671936K) icms_dc=0 , 0.3130111 secs]
77148.565: [GC 77148.565: [ParNew: 130944K->0K(131008K), 0.3146629 secs] 15894764K->15766067K(28671936K) icms_dc=0 , 0.3148481 secs]
77166.762: [GC 77166.762: [ParNew: 130944K->0K(131008K), 0.2902859 secs] 15897011K->15769686K(28671936K) icms_dc=0 , 0.2904642 secs]
77173.957: [GC 77173.957: [ParNew: 130944K->0K(131008K), 0.3132502 secs] 15900630K->15794955K(28671936K) icms_dc=0 , 0.3134416 secs]
77184.689: [GC 77184.689: [ParNew: 130944K->0K(131008K), 0.3122028 secs] 15925899K->15817089K(28671936K) icms_dc=0 , 0.3123857 secs]
77195.961: [GC 77195.961: [ParNew: 130944K->0K(131008K), 0.3101975 secs] 15948033K->15823153K(28671936K) icms_dc=0 , 0.3103801 secs]
77212.697: [GC 77212.697: [ParNew: 130944K->0K(131008K), 0.3109774 secs] 15954097K->15845044K(28671936K) icms_dc=0 , 0.3111528 secs]
77217.947: [GC 77217.947: [ParNew: 130933K->0K(131008K), 0.2913624 secs] 15975978K->15846428K(28671936K) icms_dc=0 , 0.2915358 secs]
77237.788: [GC 77237.788: [ParNew: 129457K->0K(131008K), 0.2967028 secs] 15975885K->15849363K(28671936K) icms_dc=0 , 0.2968859 secs]
77248.232: [GC 77248.232: [ParNew: 130441K->0K(131008K), 0.3249377 secs] 15979804K->15872164K(28671936K) icms_dc=0 , 0.3251147 secs]
77259.231: [GC 77259.231: [ParNew: 130939K->0K(131008K), 0.3262398 secs] 16003104K->15893957K(28671936K) icms_dc=0 , 0.3264322 secs]
77269.578: [GC 77269.578: [ParNew: 130944K->0K(131008K), 0.3244924 secs] 16024901K->15897801K(28671936K) icms_dc=0 , 0.3246682 secs]
77280.109: [GC 77280.109: [ParNew: 129785K->0K(131008K), 0.3440615 secs] 16027587K->15923895K(28671936K) icms_dc=0 , 0.3442430 secs]
77290.806: [GC 77290.806: [ParNew: 125725K->0K(131008K), 0.3185027 secs] 16049620K->15950674K(28671936K) icms_dc=0 , 0.3186805 secs]
77302.797: [GC 77302.797: [ParNew: 130859K->0K(131008K), 0.3043288 secs] 16081533K->15958590K(28671936K) icms_dc=0 , 0.3045180 secs]
77312.365: [GC 77312.365: [ParNew: 130944K->0K(131008K), 0.2918505 secs] 16089534K->15960772K(28671936K) icms_dc=0 , 0.2920314 secs]
77322.862: [GC 77322.863: [ParNew: 130944K->0K(131008K), 0.3015737 secs] 16091716K->15963449K(28671936K) icms_dc=0 , 0.3017476 secs]
77343.729: [GC 77343.729: [ParNew: 130944K->0K(131008K), 0.3236395 secs] 16094393K->15967208K(28671936K) icms_dc=0 , 0.3238134 secs]
77354.586: [GC 77354.586: [ParNew: 130944K->0K(131008K), 0.3131893 secs] 16098152K->15970188K(28671936K) icms_dc=0 , 0.3133721 secs]
77364.952: [GC 77364.952: [ParNew: 130944K->0K(131008K), 0.3102413 secs] 16101132K->15992949K(28671936K) icms_dc=0 , 0.3104283 secs]
77377.458: [GC 77377.458: [ParNew: 130935K->0K(131008K), 0.3312504 secs] 16123885K->16015429K(28671936K) icms_dc=0 , 0.3314204 secs]
77386.642: [GC 77386.642: [ParNew: 130944K->0K(131008K), 0.3294257 secs] 16146373K->16018109K(28671936K) icms_dc=0 , 0.3296290 secs]
77397.408: [GC 77397.408: [ParNew: 130944K->0K(131008K), 0.3466004 secs] 16149053K->16041639K(28671936K) icms_dc=0 , 0.3467640 secs]
77407.720: [GC 77407.720: [ParNew: 127181K->0K(131008K), 0.3291395 secs] 16168820K->16067781K(28671936K) icms_dc=0 , 0.3293197 secs]
77419.256: [GC 77419.257: [ParNew: 127292K->0K(131008K), 0.3417004 secs] 16195074K->16101594K(28671936K) icms_dc=3 , 0.3418733 secs]
77426.886: [GC [1 CMS-initial-mark: 16101594K(28540928K)] 16165188K(28671936K), 0.0349381 secs]
77426.921: [CMS-concurrent-mark-start]
77428.941: [GC 77428.941: [ParNew: 130944K->0K(131008K), 0.2950079 secs] 16232538K->16108380K(28671936K) icms_dc=3 , 0.2951910 secs]
77438.826: [CMS-concurrent-mark: 0.913/11.904 secs]
77438.826: [CMS-concurrent-preclean-start]
77438.826: [CMS-concurrent-preclean: 0.000/0.000 secs]
77439.028: [CMS-concurrent-abortable-preclean-start]
77439.028: [CMS-concurrent-abortable-preclean: 0.000/0.000 secs]
77439.480: [GC 77439.480: [ParNew: 126872K->0K(131008K), 0.3251631 secs] 16235253K->16139128K(28671936K) icms_dc=3 , 0.3253437 secs]
77447.411: [GC[YG occupancy: 66352 K (131008 K)]77447.411: [Rescan (parallel) , 0.0551127 secs]77447.466: [weak refs processing, 0.0308647 secs]77447.497: [class unloading[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor28]
77447.504: [scrub symbol & string tables, 0.0084419 secs] [1 CMS-remark: 16139128K(28540928K)] 16205480K(28671936K), 0.1156339 secs]
77447.528: [CMS-concurrent-sweep-start]
77450.331: [GC 77450.331: [ParNew: 127555K->0K(131008K), 0.3276881 secs] 16257886K->16148782K(28671936K) icms_dc=3 , 0.3278723 secs]
77471.167: [GC 77471.168: [ParNew: 130944K->0K(131008K), 0.3443864 secs] 16264980K->16156348K(28671936K) icms_dc=3 , 0.3445624 secs]
77484.330: [GC 77484.331: [ParNew: 130944K->0K(131008K), 0.3138211 secs] 16282337K->16155285K(28671936K) icms_dc=3 , 0.3139971 secs]
77490.323: [GC 77490.323: [ParNew: 130887K->0K(131008K), 0.3463333 secs] 16266084K->16158092K(28671936K) icms_dc=3 , 0.3465076 secs]
77503.075: [GC 77503.075: [ParNew: 130944K->0K(131008K), 0.3230820 secs] 16246239K->16117912K(28671936K) icms_dc=3 , 0.3232641 secs]
77513.508: [GC 77513.508: [ParNew: 130944K->0K(131008K), 0.3446744 secs] 16232772K->16104890K(28671936K) icms_dc=3 , 0.3449231 secs]
77526.076: [GC 77526.076: [ParNew: 130173K->0K(131008K), 0.3488064 secs] 16219569K->16093708K(28671936K) icms_dc=3 , 0.3490094 secs]
77535.048: [GC 77535.048: [ParNew: 130944K->0K(131008K), 0.3444742 secs] 16091984K->15984538K(28671936K) icms_dc=3 , 0.3447258 secs]
77540.284: [CMS-concurrent-sweep: 1.808/92.757 secs]
77540.285: [CMS-concurrent-reset-start]
77540.637: [CMS-concurrent-reset: 0.352/0.352 secs]
77547.483: [GC 77547.483: [ParNew: 130944K->0K(131008K), 21.2268491 secs] 569606K->465738K(28671936K) icms_dc=0 , 21.2270424 secs]
77570.056: [GC 77570.056: [ParNew: 129623K->0K(131008K), 21.8197998 secs] 595362K->492094K(28671936K) icms_dc=0 , 21.8200025 secs]
77592.450: [GC 77592.450: [ParNew: 130901K->0K(131008K), 22.4998156 secs] 622995K->513309K(28671936K) icms_dc=0 , 22.5000306 secs]
77615.471: [GC 77615.471: [ParNew: 130865K->0K(131008K), 24.1625520 secs] 644174K->515142K(28671936K) icms_dc=0 , 24.1627472 secs]

Might it be possible for you to check if the same behaviour reproduces
with the latest (b76?) Mustang JVM?
If so, let us know and we'll look into this more closely.
PS: Could you also pstack the process once it gets into
one of these long scavenges, and see if you find a lot
of "block_start" calls at the top of the stack (during card
scanning). It's almost certainly some performace pathology
related to block offset table accesses during card scanning
in the presence of large contiguous blocks would be my
guess.

COncurrent process fails with warning for OPP

Concurrent process generates xml output (version 5.6.2) .
When it tries to publish it , the log suggests checking out the OPP log.
The OPP log has a series of java entries for the request, including one of the type
Caused by: oracle.xdo.parser.v2.XPathException: Expected 'QNAME' instead of ''.
header of the OPP log says
Resolution History
18-OCT-06 20:36:05 GMT
Can you easily recover from, bypass or work around the problem? = NO
Does your system or application continue normally after the problem occurs? =
YES
Are the standard features of the system or application still available; is the
loss of service minor? = YES
### Informational Only:Warning Presented to Customer ###
You chose 'Other technical issues with this product' from the Type of Problem
list. This is a generic Service Request form which will require additional time
to be routed appropriately. You may be able to expedite the resolution of your
Service Request by doing the following: 1. Use your browser’s back button to
return to the Create a SR – Brief Description page. 2. Select an option from
the Type of Problem list that more closely describes the problem.
### Requested files:ACT(Note 183274.1),RDA (Note 175853.1). Files to be loaded.
None
### Detailed Problem Statement ###
Concurrent process for XML Publisher fails with warning. Cannot see Diagnostics
--> XML output completely. Only first page visible. Buttons and Menu items
disabled not allowing to view the whole XML file to troubleshoot for
correct/incorrect tags.
Attached are OPP Manager log file, Screen shot of 'Preview' output jjst before
submitting request. Also log file of failed concurrent request which contains
standard error " See OPP Service log file for more".
### Steps to Reproduce Problem ###
Registered a concurrent process with XML template , and running the process
from Receivables Manager responsibility.
Ran concurrent process for 1) Standard RAXINV report , with output method as
'XML'. 2) Customised RAXINV report, with output method as 'XML'
### Instance Name(s) and Type of System(s) Where Error Occurs ###
Lunix, 11.5.10 on 10g
### Recent Changes to this Environment ###
None
### Workarounds Used ###
None
### How is this Issue Impacting Your Business ###
Business is readying for CRP3, so would like to have reports ready by then.
Contact me via : MetaLink
18-OCT-06 20:48:07 GMT
The customer : [email protected] : has uploaded the following file via MetaLink:
C:\Documents_and_Settings\broy\BareEscentuals\Reports\Errors\XML_Pub1.bmp
18-OCT-06 20:49:14 GMT
The customer : [email protected] : has uploaded the following file via MetaLink:
C:\Documents_and_Settings\broy\BareEscentuals\Reports\Errors\XMLPublisher_java.t
xt
18-OCT-06 21:17:26 GMT
Hi Bashobi,
Thank you for using MetaLink. We are currently reviewing/researching the situation and will update the SR as soon as we have relevant information
Best Regards,
Bill
Oracle Support Services
STATUS
=======
@WIP -- Work In Progress
18-OCT-06 21:18:04 GMT
Email Update button has been pressed: Sending email to [email protected].
18-OCT-06 21:21:45 GMT
ISSUE CLARIFICATION
====================
On 11.5.10.2 in Production:
Find concurrent process for XML Publisher fails with warning. Cannot see Diagnostics
--> XML output completely. Only first page visible. Buttons and Menu items
disabled not allowing to view the whole XML file to troubleshoot for
correct/incorrect tags.
EXPECTED BEHAVIOR
Expect the processes run successfully
STEPS
The issue can be reproduced at will with the following steps:
1. Registered a concurrent process with XML template .
2. Run the process from Receivables Manager responsibility.
3. Ran concurrent process for
1) Standard RAXINV report , with output method as 'XML'
2) Customised RAXINV report, with output method as 'XML'
BUSINESS IMPACT
The issue has the following business impact:
Business is readying for CRP3, so would like to have reports ready by then.
ACTION PLAN
============
Hi Bashobi,
1. Can you reproduce the issue from sysadmin responsibility with Active users report? if yes
please upload OPP log file after reproduce it and upload the request log file.
Thanks.
18-OCT-06 23:09:02 GMT
New info : [email protected] : Did the same as suggested, Request
completes successfully.
But what is the relation between Active Users report and a report sent via XML
Publisher?
19-OCT-06 15:54:26 GMT
ACTION PLAN
============
Hi Bashobi,
1. When you reproduce the issue from sysadmin responsibility with Active users report change the format out put to XML,
Save your change:
2. Upload OPP manager log file and upload the request log file.
Thanks,
Bill.
19-OCT-06 15:54:33 GMT
Email Update button has been pressed: Sending email to [email protected].
19-OCT-06 16:42:23 GMT
New info : [email protected] : Bill,
No, I could not reproduce the problem with Active Users program.
Attaching OPP manager log in the next update. Bashobi
19-OCT-06 17:05:07 GMT
New info : [email protected] : Bill, Attaching internal log and manager
log
Bashobi
19-OCT-06 17:06:08 GMT
The customer : [email protected] : has uploaded the following file via MetaLink:
C:\Documents_and_Settings\broy\BareEscentuals\Reports\Errors\OPP_internal_log.tx
t
19-OCT-06 17:07:10 GMT
The customer : [email protected] : has uploaded the following file via MetaLink:
C:\Documents_and_Settings\broy\BareEscentuals\Reports\Errors\OPP_manager_log.txt
19-OCT-06 18:14:32 GMT
UPDATE
=======
Hi Bashobi,
Thank you for providing the requested information.
Best Regards,
Bill
STATUS
=======
@WIP -- Work In Progress
19-OCT-06 18:14:36 GMT
Email Update button has been pressed: Sending email to [email protected].
19-OCT-06 18:59:25 GMT
DATA COLLECTED
===============
SCREEN SHOTS
XML_Pub1.bmp:
Error:
Jave.sql SQL Exception No corresponding LOB data found: select File_data_dbms_lob...........
LOG FILE
1. XMLPublisher_java.txt:
[10/18/06 11:16:57 AM] [5670:RT277479] Completed post-processing actions for request 277479.
[10/18/06 11:29:06 AM] [OPPServiceThread1] Post-processing request 277488.
[10/18/06 11:29:06 AM] [5670:RT277488] Executing post-processing actions for request 2
77488.
[10/18/06 11:29:06 AM] [5670:RT277488] Starting XML Publisher post-processing action.
[10/18/06 11:29:06 AM] [5670:RT277488]
Template code: XXBE_TEST_INV
Template app: AR
Language: en
Territory: US
Output type: null
[10/18/06 11:29:07 AM] [UNEXPECTED] [5670:RT277488] java.lang.reflect.InvocationTarg
etException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10/18/06 11:29:07 AM] [5670:RT277488] Completed post-processing actions for reque
st 277488.
2. OPP_manager_log.txt:
[10/19/06 5:22:36 AM] [main] Starting GSF service with concurrent process id = 5688.
[10/19/06 5:22:36 AM] [main] Initialization Parameters: oracle.apps.fnd.cp.opp.OPPServiceThread:2:0:max_threads=5
[10/19/06 5:22:37 AM] [Thread-12] Service thread starting up.
[10/19/06 5:22:37 AM] [Thread-13] Service thread starting up.
ISSUE VERIFICATION
=================
Issue veryfied by the screen shots: XML_Pub1.bmp which shows:
Jave.sql SQL Exception No corresponding LOB data found: select File_data_dbms_lob...........
ACTION PLAN
============
Hi Bashobi,
1. Since you can not reproduce the issue from sysadmin responsibility can we say the issue specific to Receivables Manager
responsibility<INV xml report>?
2. You said before: "Concurrent process for XML Publisher fails with warning. Cannot see Diagnostics
--> XML output completely. Only first page visible. Buttons and Menu items
disabled not allowing to view the whole XML file to troubleshoot for
correct/incorrect tags.":
Is the above mean :
-The xml publisher report completed but you can not view the whole XML file
-Or the xml publisher report error out with "Jave.sql SQL Exception No corresponding LOB data found: select File_data_dbms_lob.."
Thanks.
19-OCT-06 18:59:32 GMT
Email Update button has been pressed: Sending email to [email protected].
20-OCT-06 21:36:13 GMT
Email Update button has been pressed: Sending email to [email protected].
24-OCT-06 21:50:06 GMT
New info : [email protected] : Hi,
We are in the process of upgrading XML Publisher at the moment. I would like to
wait a day or two to test the report with the upgrade.
Thanks,Bashobi
26-OCT-06 20:15:07 GMT
New info : [email protected] : Hi,
Our DBA has applied the 5.6.2 patch on our dev instance. My concurrent process
runs to a warning.
The warnings in the OPP manager log file say
Template code: BE_RAXINV
Template app: XXBE
Language: en
Territory: US
Output type: PDF
[10/26/06 12:50:13 PM] [UNEXPECTED] [5849:RT281617]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Any idea?

Hi All,
I have ran into the same issue.
"The Output Post-processor is running but has not picked up this request.
Any ideas.
Thanks
Ravi

Effect of Multiversion Concurrency Control on Isolation

Suppose I have a table defined as follows:
create table duty
(person char(30),
status char(3)
And it has the following contents:
select * from duty;
PERSON STATUS
Greg on
Heping on
If I do the following in two sessions as outlined:
*** Session 1 ***
set transaction isolation level serializable;
*** Session 2 ***
set transaction isolation level serializable;
*** Session 1 ***
select * from duty where person = 'Greg';
PERSON STATUS
Greg on
-- Since Greg is 'on' we'll set Heping 'off'.
*** Session 2 ***
select * from duty where person = 'Heping';
PERSON STATUS
Heping on
-- Since Heping is 'on' we'll set Greg 'off'.
*** Session 1 ***
update duty set status = 'off' where person = 'Heping';
*** Session 2 ***
update duty set status = 'off' where person = 'Greg';
*** Session 1 ***
commit;
*** Session 2 ***
commit;
Then, my table contains
select * from duty;
PERSON STATUS
Greg off
Heping off
If these two transactions had been executed according to the SQL92 standard for transaction isolation level serializable, that is in one order or the other, then the status of these two rows would not both be 'off' (because I would not have executed the update if I saw the status off).
I note that Sybase seems to correctly handle these transactions in serializable mode if I execute them just as show above in that it identifies a deadlock between the two and forces one to rollback.
Does Oracle not implement the SQL92 Standard with respect to transaction isolation levels? Is this behavior due to Multi-Version Concurrency Control?
Thanks,
G.Carter

The couple of responses are very much appreciated. I especially found the link to Tom Kyte's article, "On Transaction Isolation Levels" (http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html) enlightening.
My conclusion is that different SQL database vendors may claim compliance with the SQL-92 standard despite the fact that their databases exhibit different behaviors and yield different answers under like circumstances because the SQL-92 standard is self inconsistent. In particular, on the one hand, the standard states that:
[1]A serializable execution is defined to be an execution of the operations of
concurrently executing SQL-transactions that produces the same effect as
some serial execution of those same SQL-transactions.
And on the other hand (in fact, in the very next paragraph), the standard states that:
[2]The isolation level specifies the kind of phenomena ["Dirty read", "Non-repeatable read", "Phantom"]
that can occur during the execution of concurrent SQL-transactions.
Whereas Sybase can emphasize [1] as a justification for its behavior, Oracle can emphasize [2] to justify its behavior, and under like circumstances, those behaviors yield different results.
Unfortunately, I (and I've got to believe that many others as well) do not have the luxury of building an application that will work with only one vendor's database.
Thanks,
G.Carter

XML Publisher generates PDF but concurrent program still completes in error

Hello,
I have a concurent program that is used everyday. It generates PDF output with an average of 500 pages. It completes normal majority of the times, but completes in error sporadicallly. Interestingly, when it completes in error, it still generates the PDF output successfully.
Question is why does it complete in error when all is good?
Please note that we just went live on R12 from 11i beginning of this year. This issue never occurred in 11i. Please advise what can be done to fix this issue.
Below is a log from one such submission. The log was rather long, so I'm only posting chunks from the beginning and end of the log, stripping the middle portion:
Receivables: Version : 12.0.0
Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved.
XXBREG_RAXINV_NEW_XMLP module: Breg Invoice Print New Invoices - XMLP
Current system time is 22-JAN-2013 06:46:58
+-----------------------------
| Starting concurrent program execution...
+-----------------------------
Arguments
p_order_by='TRX_NUMBER'
p_cust_trx_class='INV'
p_cust_trx_type_id='1'
p_open_invoice='Y'
p_check_for_taxyn='N'
p_choice='NEW'
p_header_pages='1'
p_debug_flag='N'
p_message_level='10'
Forcing NLS_NUMERIC_CHARACTERS to: '.,' for XDO processing
APPLLCSP Environment Variable set to :
Current NLS_LANG and NLS_NUMERIC_CHARACTERS Environment Variables are :
American_America.AL32UTF8
Enter Password:
MSG-00100: DEBUG: AfterPForm_Trigger +
MSG-00100: DEBUG: Multi Org established.
MSG-00100: DEBUG: AfterParam_Procs.Get_Country_Details
MSG-00100: DEBUG: AfterParam_Procs.Switch_On_Debug
MSG-00100: DEBUG: AfterParam_Procs.Get_Trx_Number_Low
MSG-00100: DEBUG: AfterParam_Procs.Get_Trx_Number_High
MSG-00100: DEBUG: AfterParam_Procs.Get_Tax_Option
MSG-00100: DEBUG: AfterPForm_Trigger -
MSG-00100: DEBUG: BeforeReport_Trigger +
MSG-00100: DEBUG: BeforeReport_Procs.Populate_Printing_Option
MSG-00100: DEBUG: BeforeReport_Procs.Populate_Tax_Printing_Option
MSG-00100: DEBUG: BeforeReport_Trigger.Get_Message_Details
MSG-00100: DEBUG: BeforeReport_Trigger.Get_Org_Profile.
MSG-00100: DEBUG: Organization Id: 106
MSG-00100: DEBUG: BeforeReport_Trigger.Build_Where_Clause
MSG-00100: DEBUG: P_Choice: NEW
MSG-00500: DEBUG: About to build WHERE clause.
MSG-00500: DEBUG: WHERE clause built.
MSG-00555: :p_choice:NEW
MSG-00100: DEBUG: Choice is other than ADJ, setting ORDER BY.
MSG-00555: :p_sel_trx_number:a.trx_number
MSG-00555: :p_sel_trx_date:a.trx_date
MSG-00555: :p_sel_trx_id:a.customer_trx_id
MSG-00555: :p_sel_trx_type:types.type
MSG-00555: :p_br_where_clause:
MSG-00500: DEBUG: Table 1: AR_ADJUSTMENTS COM_ADJ,
AR_PAYMENT_SCHEDULES P,
RA_CUST_TRX_LINE_GL_DIST REC,
RA_CUSTOMER_TRX A,
HZ_CUST_ACCOUNTS B,
RA_TERMS T,
RA_TERMS_LINES TL,
RA_CUST_TRX_TYPES TYPES,
AR_LOOKUPS L_TYPES,
HZ_PARTIES      PARTY,
HZ_CUST_ACCT_SITES A_BILL,
HZ_PARTY_SITES PARTY_SITE,
HZ_LOCATIONS LOC,
HZ_CUST_SITE_USES U_BILL
MSG-00500: DEBUG: Table 2: RA_TERMS_LINES TL,
RA_CUST_TRX_TYPES TYPES,
AR_LOOKUPS L_TYPES,
     HZ_CUST_ACCOUNTS B,
HZ_PARTIES      PARTY,
HZ_CUST_SITE_USES U_BILL,
HZ_CUST_ACCT_SITES A_BILL,
HZ_PARTY_SITES PARTY_SITE,
HZ_LOCATIONS LOC,
AR_ADJUSTMENTS COM_ADJ,
RA_CUSTOMER_TRX A,
AR_PAYMENT_SCHEDULES P,
RA_TERMS T
MSG-00500: DEBUG: Where 1: A.BILL_TO_CUSTOMER_ID = B.CUST_ACCOUNT_ID
AND REC.CUSTOMER_TRX_ID = A.CUSTOMER_TRX_ID
AND REC.LATEST_REC_FLAG = 'Y'
AND REC.ACCOUNT_CLASS = 'REC'
AND P.PAYMENT_SCHEDULE_ID + DECODE(P.CLASS,
'INV', 0,
= COM_ADJ.PAYMENT_SCHEDULE_ID(+)
AND COM_ADJ.SUBSEQUENT_TRX_ID IS NULL
AND 'C' = COM_ADJ.ADJUSTMENT_TYPE(+)
AND A.COMPLETE_FLAG = 'Y'
AND A.CUST_TRX_TYPE_ID = TYPES.CUST_TRX_TYPE_ID
AND L_TYPES.LOOKUP_TYPE = 'INV/CM/ADJ'
AND A.PRINTING_OPTION IN ('PRI', 'REP')
AND L_TYPES.LOOKUP_CODE =
DECODE( TYPES.TYPE,'DEP','INV', TYPES.TYPE)
AND NVL(P.TERMS_SEQUENCE_NUMBER,nvl(TL.SEQUENCE_NUM,0))=nvl(TL.SEQUENCE_NUM,nvl(p.terms_sequence_number,0))
AND DECODE(P.PAYMENT_SCHEDULE_ID,'',0, NVL(T.PRINTING_LEAD_DAYS,0))=0
AND A.BILL_TO_SITE_USE_ID = U_BILL.SITE_USE_ID
AND U_BILL.CUST_ACCT_SITE_ID = A_BILL.CUST_ACCT_SITE_ID
AND A_BILL.party_site_id = party_site.party_site_id
AND B.PARTY_ID = PARTY.PARTY_ID
AND loc.location_id = party_site.location_id
AND NVL(LOC.LANGUAGE,'US') = 'US'
AND NVL(P.AMOUNT_DUE_REMAINING,0) <> 0
AND A.CUST_TRX_TYPE_ID = 1
AND TYPES.TYPE = 'INV'
AND A.TERM_ID = TL.TERM_ID(+)
AND A.TERM_ID = T.TERM_ID(+)
AND A.CUSTOMER_TRX_ID = P.CUSTOMER_TRX_ID(+)
AND A.PRINTING_PENDING = 'Y'
AND NVL(TL.SEQUENCE_NUM, 1) > NVL(A.LAST_PRINTED_SEQUENCE_NUM,0)
MSG-00500: DEBUG: Where 2: A.BILL_TO_CUSTOMER_ID = B.CUST_ACCOUNT_ID
AND P.PAYMENT_SCHEDULE_ID + DECODE(P.CLASS,
'INV', 0,
= COM_ADJ.PAYMENT_SCHEDULE_ID(+)
AND COM_ADJ.SUBSEQUENT_TRX_ID IS NULL
AND 'C' = COM_ADJ.ADJUSTMENT_TYPE(+)
AND A.COMPLETE_FLAG = 'Y'
AND A.CUSTOMER_TRX_ID = P.CUSTOMER_TRX_ID
AND A.CUST_TRX_TYPE_ID = TYPES.CUST_TRX_TYPE_ID
AND L_TYPES.LOOKUP_TYPE = 'INV/CM/ADJ'
AND A.PRINTING_OPTION IN ('PRI', 'REP')
AND L_TYPES.LOOKUP_CODE =
DECODE( TYPES.TYPE,'DEP','INV', TYPES.TYPE)
AND NVL(T.PRINTING_LEAD_DAYS,0) > 0
AND A.BILL_TO_SITE_USE_ID = U_BILL.SITE_USE_ID
AND U_BILL.CUST_ACCT_SITE_ID = A_BILL.CUST_ACCT_SITE_ID
AND A_BILL.PARTY_SITE_ID = PARTY_SITE.PARTY_SITE_ID
AND B.PARTY_ID = PARTY.PARTY_ID
AND LOC.LOCATION_ID = PARTY_SITE.LOCATION_ID
AND NVL(LOC.LANGUAGE,'US') = 'US'
AND NVL(P.TERMS_SEQUENCE_NUMBER,TL.SEQUENCE_NUM)=TL.SEQUENCE_NUM
AND NVL(P.AMOUNT_DUE_REMAINING,0) <> 0
AND A.CUST_TRX_TYPE_ID = 1
AND TYPES.TYPE = 'INV'
AND T.TERM_ID = P.TERM_ID
AND TL.TERM_ID(+) = T.TERM_ID
AND A.PRINTING_PENDING = 'Y'
AND P.TERMS_SEQUENCE_NUMBER > NVL(A.LAST_PRINTED_SEQUENCE_NUM,0)
MSG-00100: DEBUG: BeforeReport_Trigger -
MSG-05000: DEBUG: Trx No... 1010441
MSG-00100: DEBUG: Get_Country_Description.
MSG-00010: 06:47 1 Transaction: 1010441
MSG-00001: Line type : Line
MSG-00100: DEBUG: Get_Country_Description.
MSG-00100: DEBUG: Get_Country_Description.
MSG-05000: DEBUG: Remit To Address....
MSG-05000: DEBUG: Address Style:
MSG-05000: DEBUG: Address 1: PO Box 849991
MSG-05000: DEBUG: Address 2:
MSG-05000: DEBUG: Address 3:
MSG-05000: DEBUG: Address 4:
MSG-05000: DEBUG: City: Dallas
MSG-05000: DEBUG: County:
MSG-05000: DEBUG: State: TX
MSG-05000: DEBUG: Province:
MSG-05000: DEBUG: Postal Code: 75284
MSG-05000: DEBUG: Territory:
MSG-05000: DEBUG: Country_Code: US
MSG-05000: DEBUG: Customer Name:
MSG-05000: DEBUG: Bill To:
MSG-05000: DEBUG: First Name:
MSG-05000: DEBUG: Last Name:
MSG-05000: DEBUG: Mail Stop:
MSG-05000: DEBUG: Country Code: US
MSG-05000: DEBUG: Country Desc:
MSG-05000: DEBUG: Print Home Flag: N
MSG-05000: DEBUG: Width: 40
MSG-05000: DEBUG: Height Min: 6
MSG-05000: DEBUG: Height Max: 6
MSG-05000: DEBUG: Remit To Formatted... PO Box 849991
Dallas TX 75284
MSG-05000: DEBUG: Trx No... 1010442
MSG-00100: DEBUG: Get_Country_Description.
MSG-00010: 06:47 2 Transaction: 1010442
MSG-05000: DEBUG: Bill To Address....
MSG-05000: DEBUG: Address Style:
MSG-05000: DEBUG: Address 1: 6560 W ROGERS CIR
MSG-05000: DEBUG: Address 2: STE 19
MSG-05000: DEBUG: Address 3:
MSG-05000: DEBUG: Address 4:
MSG-05000: DEBUG: City: BOCA RATON
MSG-05000: DEBUG: County:
MSG-05000: DEBUG: State: FL
MSG-05000: DEBUG: Province:
MSG-05000: DEBUG: Postal Code: 33487-2746
MSG-05000: DEBUG: Territory:
MSG-05000: DEBUG: Country_Code: US
MSG-05000: DEBUG: Customer Name: THE BRACE SHOP
MSG-05000: DEBUG: Bill To:
MSG-05000: DEBUG: First Name: LORI
MSG-05000: DEBUG: Last Name: ESCALANTE
MSG-05000: DEBUG: Mail Stop:
MSG-05000: DEBUG: Country Code: US
MSG-05000: DEBUG: Country Desc:
MSG-05000: DEBUG: Print Home Flag: N
MSG-05000: DEBUG: Width: 40
MSG-05000: DEBUG: Height Min: 8
MSG-05000: DEBUG: Height Max: 8
MSG-05000: DEBUG: Bill To Formatted... LORI ESCALANTE
THE BRACE SHOP
6560 W ROGERS CIR
STE 19
BOCA RATON FL 33487-2746
MSG-05000: DEBUG: Ship To Address....
MSG-05000: DEBUG: Address Style:
MSG-05000: DEBUG: Address 1: 7014 E Appleton Circle
MSG-05000: DEBUG: Address 2:
MSG-05000: DEBUG: Address 3:
MSG-05000: DEBUG: Address 4:
MSG-05000: DEBUG: City: CENTENNIAL
MSG-05000: DEBUG: County:
MSG-05000: DEBUG: State: CO
MSG-05000: DEBUG: Province:
MSG-05000: DEBUG: Postal Code: 80112-1155
MSG-05000: DEBUG: Territory:
MSG-05000: DEBUG: Country_Code: US
MSG-05000: DEBUG: Customer Name: Kenneth Grimm
MSG-05000: DEBUG: Bill To:
MSG-05000: DEBUG: First Name:
MSG-05000: DEBUG: Last Name:
MSG-05000: DEBUG: Mail Stop:
MSG-05000: DEBUG: Country Code: US
MSG-05000: DEBUG: Country Desc:
MSG-05000: DEBUG: Print Home Flag: N
MSG-05000: DEBUG: Width: 40
MSG-05000: DEBUG: Height Min: 8
MSG-05000: DEBUG: Height Max: 8
MSG-05000: DEBUG: Ship To Formatted... Kenneth Grimm
7014 E Appleton Circle
CENTENNIAL CO 80112-1155
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00100: DEBUG: Get_Country_Description.
MSG-00100: Oracle Error in call to arp_adds.location_description -6503
MSG-05000: DEBUG: Remit To Address....
MSG-05000: DEBUG: Address Style:
MSG-05000: DEBUG: Address 1: PO Box 849991
MSG-05000: DEBUG: Address 2:
MSG-05000: DEBUG: Address 3:
MSG-05000: DEBUG: Address 4:
MSG-05000: DEBUG: City: Dallas
MSG-05000: DEBUG: County:
MSG-05000: DEBUG: State: TX
MSG-05000: DEBUG: Province:
MSG-05000: DEBUG: Postal Code: 75284
MSG-05000: DEBUG: Territory:
MSG-05000: DEBUG: Country_Code: US
MSG-05000: DEBUG: Customer Name:
MSG-05000: DEBUG: Bill To:
MSG-05000: DEBUG: First Name:
MSG-05000: DEBUG: Last Name:
MSG-05000: DEBUG: Mail Stop:
MSG-05000: DEBUG: Country Code: US
MSG-05000: DEBUG: Country Desc:
MSG-05000: DEBUG: Print Home Flag: N
MSG-05000: DEBUG: Width: 40
MSG-05000: DEBUG: Height Min: 6
MSG-05000: DEBUG: Height Max: 6
MSG-05000: DEBUG: Remit To Formatted... PO Box 849991
Dallas TX 75284
MSG-05000: DEBUG: Trx No... 1010930
MSG-00100: DEBUG: Get_Country_Description.
MSG-00010: 06:47 506 Transaction: 1010930
MSG-05000: DEBUG: Bill To Address....
MSG-05000: DEBUG: Address Style:
MSG-05000: DEBUG: Address 1: 4412 MANILLA ROAD SE
MSG-05000: DEBUG: Address 2: UNIT 7
MSG-05000: DEBUG: Address 3:
MSG-05000: DEBUG: Address 4:
MSG-05000: DEBUG: City: CALGARY
MSG-05000: DEBUG: County:
MSG-05000: DEBUG: State:
MSG-05000: DEBUG: Province: ALBERTA
MSG-05000: DEBUG: Postal Code: T2G 4B7
MSG-05000: DEBUG: Territory:
MSG-05000: DEBUG: Country_Code: CA
MSG-05000: DEBUG: Customer Name: MEDLINES INC DBA PRO CARE MEDICAL LTD
MSG-05000: DEBUG: Bill To:
MSG-05000: DEBUG: First Name:
MSG-05000: DEBUG: Last Name:
MSG-05000: DEBUG: Mail Stop:
MSG-05000: DEBUG: Country Code: US
MSG-05000: DEBUG: Country Desc:
MSG-05000: DEBUG: Print Home Flag: N
MSG-05000: DEBUG: Width: 40
MSG-05000: DEBUG: Height Min: 8
MSG-05000: DEBUG: Height Max: 8
MSG-05000: DEBUG: Bill To Formatted... Attn: Accounts Payable
MEDLINES INC DBA PRO CARE MEDICAL LTD
4412 MANILLA ROAD SE
UNIT 7
CALGARY ALBERTA T2G 4B7
Canada
MSG-05000: DEBUG: Ship To Address....
MSG-05000: DEBUG: Address Style:
MSG-05000: DEBUG: Address 1: 4412 MANILLA ROAD SE Unit 7
MSG-05000: DEBUG: Address 2: PH:403 287 0993
MSG-05000: DEBUG: Address 3:
MSG-05000: DEBUG: Address 4:
MSG-05000: DEBUG: City: CALGARY
MSG-05000: DEBUG: County:
MSG-05000: DEBUG: State: ALBERTA
MSG-05000: DEBUG: Province: ALBERTA
MSG-05000: DEBUG: Postal Code: T2G 4B7
MSG-05000: DEBUG: Territory:
MSG-05000: DEBUG: Country_Code: CA
MSG-05000: DEBUG: Customer Name: MEDLINES INC DBA PRO CARE MEDICAL LTD
MSG-05000: DEBUG: Bill To:
MSG-05000: DEBUG: First Name:
MSG-05000: DEBUG: Last Name:
MSG-05000: DEBUG: Mail Stop:
MSG-05000: DEBUG: Country Code: US
MSG-05000: DEBUG: Country Desc:
MSG-05000: DEBUG: Print Home Flag: N
MSG-05000: DEBUG: Width: 40
MSG-05000: DEBUG: Height Min: 8
MSG-05000: DEBUG: Height Max: 8
MSG-05000: DEBUG: Ship To Formatted... MEDLINES INC DBA PRO CARE MEDICAL LTD
4412 MANILLA ROAD SE Unit 7
PH:403 287 0993
CALGARY ALBERTA ALBERTA T2G 4B7
Canada
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00001: Line type : Line
MSG-00100: DEBUG: Get_Country_Description.
MSG-05000: DEBUG: Remit To Address....
MSG-05000: DEBUG: Address Style:
MSG-05000: DEBUG: Address 1: PO Box 849991
MSG-05000: DEBUG: Address 2:
MSG-05000: DEBUG: Address 3:
MSG-05000: DEBUG: Address 4:
MSG-05000: DEBUG: City: Dallas
MSG-05000: DEBUG: County:
MSG-05000: DEBUG: State: TX
MSG-05000: DEBUG: Province:
MSG-05000: DEBUG: Postal Code: 75284
MSG-05000: DEBUG: Territory:
MSG-05000: DEBUG: Country_Code: US
MSG-05000: DEBUG: Customer Name:
MSG-05000: DEBUG: Bill To:
MSG-05000: DEBUG: First Name:
MSG-05000: DEBUG: Last Name:
MSG-05000: DEBUG: Mail Stop:
MSG-05000: DEBUG: Country Code: US
MSG-05000: DEBUG: Country Desc:
MSG-05000: DEBUG: Print Home Flag: N
MSG-05000: DEBUG: Width: 40
MSG-05000: DEBUG: Height Min: 6
MSG-05000: DEBUG: Height Max: 6
MSG-05000: DEBUG: Remit To Formatted... PO Box 849991
Dallas TX 75284
MSG-05000: DEBUG: Bill To Address....
MSG-05000: DEBUG: Address Style:
MSG-05000: DEBUG: Address 1: 8206 LEESBURG PIKE
MSG-05000: DEBUG: Address 2: STE 409
MSG-05000: DEBUG: Address 3:
MSG-05000: DEBUG: Address 4:
MSG-05000: DEBUG: City: VIENNA
MSG-05000: DEBUG: County:
MSG-05000: DEBUG: State: VA
MSG-05000: DEBUG: Province:
MSG-05000: DEBUG: Postal Code: 22182
MSG-05000: DEBUG: Territory:
MSG-05000: DEBUG: Country_Code: US
MSG-05000: DEBUG: Customer Name: NOVA ORTHOPAEDIC AND SPORTS MEDICINE
MSG-05000: DEBUG: Bill To:
MSG-05000: DEBUG: First Name: TAYLOR
MSG-05000: DEBUG: Last Name: CRIGLER
MSG-05000: DEBUG: Mail Stop:
MSG-05000: DEBUG: Country Code: US
MSG-05000: DEBUG: Country Desc:
MSG-05000: DEBUG: Print Home Flag: N
MSG-05000: DEBUG: Width: 40
MSG-05000: DEBUG: Height Min: 8
MSG-05000: DEBUG: Height Max: 8
MSG-05000: DEBUG: Bill To Formatted... TAYLOR CRIGLER
NOVA ORTHOPAEDIC AND SPORTS MEDICINE
8206 LEESBURG PIKE
STE 409
VIENNA VA 22182
MSG-05000: DEBUG: Ship To Address....
MSG-05000: DEBUG: Address Style:
MSG-05000: DEBUG: Address 1: 8206 LEESBURG PIKE
MSG-05000: DEBUG: Address 2: STE 409
MSG-05000: DEBUG: Address 3:
MSG-05000: DEBUG: Address 4:
MSG-05000: DEBUG: City: VIENNA
MSG-05000: DEBUG: County:
MSG-05000: DEBUG: State: VA
MSG-05000: DEBUG: Province:
MSG-05000: DEBUG: Postal Code: 22182
MSG-05000: DEBUG: Territory:
MSG-05000: DEBUG: Country_Code: US
MSG-05000: DEBUG: Customer Name: NOVA ORTHOPAEDIC AND SPORTS MEDICINE
MSG-05000: DEBUG: Bill To:
MSG-05000: DEBUG: First Name: TAYLOR
MSG-05000: DEBUG: Last Name: CRIGLER
MSG-05000: DEBUG: Mail Stop:
MSG-05000: DEBUG: Country Code: US
MSG-05000: DEBUG: Country Desc:
MSG-05000: DEBUG: Print Home Flag: N
MSG-05000: DEBUG: Width: 40
MSG-05000: DEBUG: Height Min: 8
MSG-05000: DEBUG: Height Max: 8
MSG-05000: DEBUG: Ship To Formatted... TAYLOR CRIGLER
NOVA ORTHOPAEDIC AND SPORTS MEDICINE
8206 LEESBURG PIKE
STE 409
VIENNA VA 22182
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
MSG-00001: In Line frame trigger
MSG-00001: Line Type: INV Source:OM Invoices
REP-0069: Internal error
REP-57054: In-process job terminated:Finished successfully
MSG-00100: DEBUG: BeforeReport_Trigger +
MSG-00100: DEBUG: BeforeReport_Procs.Populate_Printing_Option
MSG-00100: DEBUG: BeforeReport_Procs.Populate_Tax_Printing_Option
MSG-00100: DEBUG: BeforeReport_Trigger.Get_Message_Details
MSG-00100: DEBUG: BeforeReport_Trigger.Get_Org_Profile.
MSG-00100: DEBUG: Organization Id: 106
MSG-00100: DEBUG: BeforeReport_Trigger.Build_Where_Clause
MSG-00100: DEBUG: P_Choice: NEW
MSG
Report Builder: Release 10.1.2.3.0 - Production on Tue Jan 22 06:47:00 2013
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Start of log messages from FND_FILE
End of log messages from FND_FILE
Program exited with status 1
Concurrent Manager encountered an error while running Oracle*Report for your concurrent request 945196.
Review your concurrent request log and/or report output file for more detailed information.
Successfully resubmitted concurrent program XXBREG_RAXINV_NEW_XMLP with request ID 953242 to start at 23-JAN-2013 05:15:00 (ROUTINE=AFPSRS)
Executing request completion options...
Output file size:
13010844
------------- 1) PUBLISH -------------
Beginning post-processing of request 945196 on node EBSAPPPROD at 22-JAN-2013 06:49:36.
Post-processing of request 945196 completed at 22-JAN-2013 06:49:59.
Finished executing request completion options.
Concurrent request completed
Current system time is 22-JAN-2013 06:49:59
Regards,
Smita

Hi,
Since you said the behavior is sporadic and also the program was running good in 11i instance, I think its a problem with the data [or select query in the concurrent program] .
Ideal scenario:
1. Upon the concurrent program completing in error the pdf should not be generated in first place, since it misguides the obtained report. [Concurrent Program should be modified accordingly, before calling the pdf generation logic you need to check the status of the concurrent program].
2. It is not likely that the pdf generation should error out upon concurrent program's error, since the concurrent program could have a soft closure of its schema definition [inspite of an uncaught/unhandled exception]
eg:
<schema def>
<Xml element 1> </Xml element 1>
<Xml element 2> </Xml element 2>
<Xml element 3> </Xml element 3>
*_ <while generating elements 4, 5 and so on concurrent program could have errored out, but still the schema definition is valid so the pdf is generated>_*
</schema def>
Solution:
Next time when you get the same behaviour, try running the concurrent program and handle the exception for that scenario, this should resolve your issue.
Regards,
Yuvaraj

MDB behavior with Foreign JMS Provider

          I am experiencing some MDB behavior which I do not quite understand. I would appreciate
          if someone could tell me what might be happening.
          An application on WebLogic 8.1 SP1 (also tried it with SP2) has MDB's which listen
          on a MQ Queue. If I put a large XML message on the MQ Queue (say around 600 KB),
          the onMessage execution is very random, For the large messages only 1 MDB gets
          invoked and the other messages just sit on the MQ Queue. Even though I have defined
          an weblogic execute queue for the MDB's and they have 15 threads allocated.
          The other messages get picked up after the first one gets completed. The problem
          is the whole transaction (which is XA) can take a while (upto 10 minutes). This
          is not intended, but for some reason it takes that long.
          Also, while monitoring the MDB execute queues, I noticed that none of the threads
          from that queue are performing the work and a thread dump shows that the weblogic.ejb20.internal.JMSPoller
          thread has invoked the MDB and is currently waiting for the database to finish
          some processing.
          When the message size is smaller, the MDB's fire concurrently and are executed
          on the MDB execute queue.
          Thanks,
          Ketan.


When we're using MDBs against a foreign JMS provider with XA, the EJB
          container tries to reduce the number of threads that are blocked waiting for
          a message. You should see lots of threads working when there are lots of
          messages on the queue, a few threads (or only one) working when the queue is
          empty or nearly so, and there should be some ramp-up and ramp-down time in
          between. It sounds like the ramp-up takes longer in your case because
          receiving the very first message takes a long time.
          If this behavior is causing big problems for you, you might want to contact
          product support and file an enhancement request.
          greg
          "Ketan" <[email protected]> wrote in message
          news:[email protected]...
          >
          > Here is some more information regarding this issue.
          >
          > When I place sufficiently large messages (such that the parsing and
          processing
          > of these messages takes longer than it does for normal size messages), I
          notice
          > the following behavior.
          >
          > Lets say I put 6 large messages on the MQ Queue. The server immediately
          picks
          > up 1 message and starts processing it. The other 5 messages are sitting on
          the
          > MQ Queue, while the MDB execute queue has all 15 idle threads.
          >
          > After the processing of the message is done, 2 messages get picked up.
          This time,
          > 1 thread in the MDB execute queue gets the message and the other is
          processed
          > by the JMSPoller thread. After these 2 messages are processed, 3 Messages
          get
          > picked up and this time 2 messages are on the MDB execute queue and 1 is
          processed
          > by the JMSPoller.
          >
          > So based on this the question is ..Is this the expected behavior? I was
          under
          > the impression that the poller would simply dispatch messages to the
          execute queue,
          > and as a result, I was expecting all the messages would get picked up from
          the
          > MQ queue pretty fast and would not have to wait for 1 or more MDB's to
          finish
          > processing.
          >
          > I would really appreciate any suggestions anyone may have for me.
          >
          > Again the environment is WLS 8.1 SP2, MQ 5.3
          >
          > thanks,
          > Ketan

Using threads in a process of two or more tasks concurrently?

Dear,
I need to develop through a Java application in a process that allows the same process using Threads on two or more tasks can be executed concurrently. The goal is to optimize the runtime of a program.
Then, through a program, display the behavior of a producer and two consumers at runtime!
Below is the code and problem description.
Could anyone help me on this issue?
Sincerely,
Sérgio Pitta
The producer-consumer problem
Known as the problem of limited buffer. The two processes share a common buffer of fixed size. One, the producer puts information into the buffer and the other the consumer to pull off.
The problem arises when the producer wants to put a new item in the buffer, but it is already full. The solution is to put the producer to sleep and wake it up only when the consumer to remove one or more items. Likewise, if the consumer wants to remove an item from the buffer and realize that it is empty, he will sleep until the producer put something in the buffer and awake.
To keep track of the number of items in the buffer, we need a variable, "count". If the maximum number of items that may contain the buffer is N, the producer code first checks whether the value of the variable "count" is N. If the producer sleep, otherwise, the producer adds an item and increment the variable "count".
The consumer code is similar: first checks if the value of the variable "count" is 0. If so, go to sleep if not zero, removes an item and decreases the counter by one. Each case also tests whether the other should be agreed and, if so, awakens. The code for both producer and consumer, is shown in the code below:
#define N 100                     / * number of posts in the buffer * /
int count = 0,                     / * number of items in buffer * /
void producer(void)
int item;
while (TRUE) {                    / * number of items in buffer * /
produce_item item = ()           / * generates the next item * /
if (count == N) sleep ()           / * if the buffer is full, go to sleep * /
insert_item (item)                / * put an item in the buffer * /
count = count + 1                / * increment the count of items in buffer * /
if (count == 1) wakeup (consumer);      / * buffer empty? * /
void consumer(void)
int item;
while (TRUE) {                    / * repeat forever * /
if (count == 0) sleep ()           / * if the buffer is full, go to sleep * /
remove_item item = ()           / * generates the next item * /
count = count - 1                / * decrement a counter of items in buffer * /
if (count == N - 1) wakeup (producer)      / * buffer empty? * /
consume_item (item)      / * print the item * /
To express system calls such as sleep and wakeup in C, they are shown how to call library routines. They are not part of standard C library, but presumably would be available on any system that actually have those system calls. Procedures "insert_item and remove_item" which are not shown, they register themselves on the insertion and removal of the item buffer.
Now back to the race condition. It can occur because the variable "count" unfettered access. Could the following scenario occurs: the buffer is empty and the consumer just read the variable "count" to check if its value is 0. In that instant, the scheduler decides to stop running temporarily and the consumer starting to run the producer. The producer inserts an item in the buffer, increment the variable "count" and realizes that its value is now 1. Inferring the value of "count" was 0 and that the consumer should go to bed, the producer calls "wakeup" to wake up the consumer.
Unfortunately, the consumer is not logically asleep, so the signal is lost to agree. The next time the consumer to run, test the value of "count" previously read by him, shall verify that the value is 0, and sleep. Sooner or later the producer fills the whole buffer and also sleep. Both sleep forever.
The essence of the problem is that you lose sending a signal to wake up a process that (still) not sleeping. If he were not lost, everything would work. A quick solution is to modify the rules, adding context to a "bit of waiting for the signal to wake up (wakeup waiting bit)." When a signal is sent to wake up a process that is still awake, this bit is turned on. Then, when the process trying to sleep, if the bit waiting for the signal to wake up is on, it will shut down, but the process will remain awake. The bit waiting for the signal to wake up is actually a piggy bank that holds signs of waking.
Even the bit waiting for the signal to wake the nation have saved in this simple example, it is easy to think of cases with three or more cases in which a bit of waiting for the signal to wake up is insufficient. We could do another improvisation and add a second bit of waiting for the signal to wake up or maybe eight or 32 of them, but in principle, the problem still exists.

user12284350 wrote:
Hi!
Thanks for the feedback!
I need a program to provide through an interface with the user behavior of a producer and two consumers at runtime, using Threads!So hire somebody to write one.
Or, if what you really mean is that you need to write such a program, as part of your course work, then write one.
You can't just dump your requirements here and expect someone to do your work for you though. If this is your assignment, then you need to do it. If you get stuck, ask a specific question about the part that's giving you trouble. "How do I write a producer/consumer program?" is not a valid question.

How we can limit the number of concurrent calls to a WCF service without use the Singleton pattern or without do the change in BizTalk Configuration file?

How can we send only one message to a WCF service at a time? How we can limit the number of concurrent calls to a WCF service without use the Singleton pattern or without do the change in BizTalk Configuration file? Can we do it by Host throttling?

Hi Pawan,
You need to use WCF-Custom adapter and add the ServiceThrottlingBehavior service behavior to a WCF-Custom Locations.
ServiceThrottlingBehavior.MaxConcurrentCalls - Gets or sets a value that specifies the maximum number of messages actively processing across a ServiceHost. The MaxConcurrentCalls property specifies the maximum number of messages actively
processing across a ServiceHost object. Each channel can have one pending message that does not count against the value of MaxConcurrentCalls until WCF begins to process it.
Follow MSDN-
http://msdn.microsoft.com/en-us/library/ee377035%28BTS.10%29.aspx
http://msdn.microsoft.com/en-us/library/system.servicemodel.description.servicethrottlingbehavior.maxconcurrentcalls.aspx
I hope this helps.
Rachit
If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

MDB cannot loads enitities if more than 10 concurrent messages are sent tog

Hello,
I have seen a weird behavior of the MDB in Jboss or perhaps in transaction management.
Here is a my scenario
I have a session bean sb, an entity bean e and a message driven bean mb
When a request comes to sb , it persists a new entity e and send a message (primary key) to mb
mb then loads e from the database using one of the findByXX method and does something else.
If 10 concurrent request comes to sb, 10 different entities are persisted and 10 different messages are sent to mb
mb are able to load 10 different e from the database
Everything works fine as long as there are 10 concurrent request. If there are 13 concurrent request, then one or two mb
cannot load e from the database. It seems that the session bean has persisted the entities but some of them are still unload able from mb. They have been persisted , (I saw in the logs), but mb cannot load them.
Initially I thought that a transaction mishap might be happening, so instead of persisting the entity and sending the message in one method in sb , I separated these two tasks in two methods a and b, in which both a and b uses RequiresNew transaction attribute. But the problem still remains. Please note if the number of parallel request are less than 10 then everything works fine. Is there something I am missing or is Jboss doing something buggy?
The above situation is reproducible .
Here is some more information about the problem along with some code snapshots. Note that the code is trimmed for clarity purposes.
Request is a simple entity (e as mentioned in the problem before) that is persisted in session bean . Here is a trimmed snapshot
Request.java
package gov.fnal.ms.dm.entity;
import java.io.Serializable;
import javax.persistence.Column;
import javax.persistence.Entity;
@Entity
@NamedQueries({@NamedQuery(name = "Request.findById", query = "SELECT r FROM Request r WHERE r.id = :id"),
@NamedQuery(name = "Request.findAll", query = "SELECT r FROM Request r"),
@Table(name = "cms_dbs_migration.Request")
@SequenceGenerator(name="seq", sequenceName="cms_dbs_migration.SEQ_REQUEST")
public class Request implements Serializable {
private String detail;
@Id
@GeneratedValue(strategy = GenerationType.AUTO, generator="seq")
@Column(nullable = false)
private Long id;
private String notify;
.....The session bean is MSSessionEJBBean.
MSSessionEJBBean.java
@Stateless(name="MSSessionEJB")
@WebService(endpointInterface = "gov.fnal.ms.dm.session.MSSessionEJBWS")
public class MSSessionEJBBean implements MSSessionEJB, MSSessionEJBLocal, MSSessionEJBWS {
@PersistenceContext(unitName="dm")
private EntityManager em;
.......    The methods that is called concurrently in this bean is
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public Request addRequest(String srcUrl, String dstUrl, String path,
String dn, String withParents, String withForce, String notify) throws
Exception {
Request r = addRequestUnit(srcUrl, dstUrl, path, dn, withParents, withForce, notify);
if (r != null) sendToQueue(r.getId());
return r;
}    It first adds the request entity and then sends a message to the queue in separate methods each using TransactionAttributeType.REQUIRES_NEW (I don't think this TransactionAttributeType is needed . I was just playing to see if this resolves the problem)
Here is the method that actually persist the entity
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public Request addRequestUnit(String srcUrl, String dstUrl, String path,
String dn, String withParents, String withForce, String notify) throws
Exception {
....// Does something before persisting
Request r = new Request();
r.setNotify(notify);
r.setPath(path);
r.setPerson(p);
r.setWithForce(withForce);
r.setWithParents(withParents);
r.setProgress(new Integer(0));
r.setStatus("Queued");
r.setDetail("Waiting to be Picked up");
em.persist(r);
System.out.println("Request Entity persisted");
System.out.println("ID is " + r.getId());
return r;
}I can see that the log files has messages
*{color:#800000}"Request Entity persisted" "ID is " 12 (or some other number){color}*
. So it is safe to assume that the request entity is persisted properly before the message is sent to the queue. Here is how the message is sent to the queue
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
private void sendToQueue(long rId) throws Exception {
QueueSession session = null;
QueueConnection conn = null;
try {
conn = factory.createQueueConnection();
session = conn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
MapMessage mapMsg = session.createMapMessage();
mapMsg.setLong("request", rId);
session.createSender(queueRequest).send(mapMsg);
} finally {
if (session != null) session.close();
if(conn != null) try {
conn.close();
}catch(Exception e) {e.printStackTrace();}
System.out.println("Message sent to queue");
}I can see the message
{color:#800000}*"Message sent to queue"*{color}
in the log file right after I see the
*{color:#800000}
"Request Entity persisted"{color}*
message. So it correct to assume that the message is infact sent to the queue.
Here is the md bean that gets the message from the queue and process it
@MessageDriven(activationConfig =
@ActivationConfigProperty(propertyName="destinationType",
propertyValue="javax.jms.Queue"),
@ActivationConfigProperty(propertyName="destination",
propertyValue="queue/requestmdb")
public class RequestMessageDrivenBean implements MessageListener {
@EJB
private MSSessionEJBLocal ejbObj;
public void onMessage(Message message) {
try{
System.out.println("Message recived ");
if(message instanceof MapMessage) {
System.out.println("This is a instance of MapMessage");
MapMessage mMsg = (MapMessage) message;
long rId = mMsg.getLong("request");
List<Request> rList = ejbObj.getRequestById(new Long(rId));
System.out.println("rList size is " + rList.size());
for(Request r: rList) {
//Does something and print something in logs
System.out.println("Finsihed onMessage");
}catch(Exception e) {
System.out.println(e.getMessage());
}    One thing to note here is that getRequestById is another method in the same session bean MSSessionEJB. Can that be the reason for not loading the request from the database when many concurrent request are present? Here is what it does
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public List<Request> getRequestById(Long id) throws Exception {
System.out.println("Inside getRequestById id is " + id);
return em.createNamedQuery("Request.findById")
.setParameter("id", id)
.getResultList();
}    In the logs I do see
{color:#800000}*"This is a instance of MapMessage"*{color}
and I do see the correct Rid that was persisted before in the log
*{color:#800000}
"inside getRequestById id is 12"{color}*
. Finally I do see
*{color:#800000}
"Finsihed onMessage"{color}*
for all the request no matter how many are sent concurrently.
*{color:#ff0000}Here is where the problem is . rList size is 1 for most of the cases but it returns 0 when the number of concurrent message exceeds 10.*
*{color}*
So you see there is no exception per se, just that entity does not get loaded from the database. I would like to mention this again, it does work properly when the number of concurrent request are less than 10. All the invocation of onMessage in MB are able to load the entity properly in that case. Its only when the number of concurrent request increases more than 10, the onMessage is unable to load the entity and the rList is 0.
FYI I am using jboss-4.2.2.GA on RedHat enterprise linux 4 with jdk1.6.0_04
Please let me know if there is more information required on this.
Thank you

Hello,
I have seen a weird behavior of the MDB in Jboss or perhaps in transaction management.
Here is a my scenario
I have a session bean sb, an entity bean e and a message driven bean mb
When a request comes to sb , it persists a new entity e and send a message (primary key) to mb
mb then loads e from the database using one of the findByXX method and does something else.
If 10 concurrent request comes to sb, 10 different entities are persisted and 10 different messages are sent to mb
mb are able to load 10 different e from the database
Everything works fine as long as there are 10 concurrent request. If there are 13 concurrent request, then one or two mb
cannot load e from the database. It seems that the session bean has persisted the entities but some of them are still unload able from mb. They have been persisted , (I saw in the logs), but mb cannot load them.
Initially I thought that a transaction mishap might be happening, so instead of persisting the entity and sending the message in one method in sb , I separated these two tasks in two methods a and b, in which both a and b uses RequiresNew transaction attribute. But the problem still remains. Please note if the number of parallel request are less than 10 then everything works fine. Is there something I am missing or is Jboss doing something buggy?
The above situation is reproducible .
Here is some more information about the problem along with some code snapshots. Note that the code is trimmed for clarity purposes.
Request is a simple entity (e as mentioned in the problem before) that is persisted in session bean . Here is a trimmed snapshot
Request.java
package gov.fnal.ms.dm.entity;
import java.io.Serializable;
import javax.persistence.Column;
import javax.persistence.Entity;
@Entity
@NamedQueries({@NamedQuery(name = "Request.findById", query = "SELECT r FROM Request r WHERE r.id = :id"),
@NamedQuery(name = "Request.findAll", query = "SELECT r FROM Request r"),
@Table(name = "cms_dbs_migration.Request")
@SequenceGenerator(name="seq", sequenceName="cms_dbs_migration.SEQ_REQUEST")
public class Request implements Serializable {
private String detail;
@Id
@GeneratedValue(strategy = GenerationType.AUTO, generator="seq")
@Column(nullable = false)
private Long id;
private String notify;
.....The session bean is MSSessionEJBBean.
MSSessionEJBBean.java
@Stateless(name="MSSessionEJB")
@WebService(endpointInterface = "gov.fnal.ms.dm.session.MSSessionEJBWS")
public class MSSessionEJBBean implements MSSessionEJB, MSSessionEJBLocal, MSSessionEJBWS {
@PersistenceContext(unitName="dm")
private EntityManager em;
.......    The methods that is called concurrently in this bean is
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public Request addRequest(String srcUrl, String dstUrl, String path,
String dn, String withParents, String withForce, String notify) throws
Exception {
Request r = addRequestUnit(srcUrl, dstUrl, path, dn, withParents, withForce, notify);
if (r != null) sendToQueue(r.getId());
return r;
}    It first adds the request entity and then sends a message to the queue in separate methods each using TransactionAttributeType.REQUIRES_NEW (I don't think this TransactionAttributeType is needed . I was just playing to see if this resolves the problem)
Here is the method that actually persist the entity
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public Request addRequestUnit(String srcUrl, String dstUrl, String path,
String dn, String withParents, String withForce, String notify) throws
Exception {
....// Does something before persisting
Request r = new Request();
r.setNotify(notify);
r.setPath(path);
r.setPerson(p);
r.setWithForce(withForce);
r.setWithParents(withParents);
r.setProgress(new Integer(0));
r.setStatus("Queued");
r.setDetail("Waiting to be Picked up");
em.persist(r);
System.out.println("Request Entity persisted");
System.out.println("ID is " + r.getId());
return r;
}I can see that the log files has messages
*{color:#800000}"Request Entity persisted" "ID is " 12 (or some other number){color}*
. So it is safe to assume that the request entity is persisted properly before the message is sent to the queue. Here is how the message is sent to the queue
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
private void sendToQueue(long rId) throws Exception {
QueueSession session = null;
QueueConnection conn = null;
try {
conn = factory.createQueueConnection();
session = conn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
MapMessage mapMsg = session.createMapMessage();
mapMsg.setLong("request", rId);
session.createSender(queueRequest).send(mapMsg);
} finally {
if (session != null) session.close();
if(conn != null) try {
conn.close();
}catch(Exception e) {e.printStackTrace();}
System.out.println("Message sent to queue");
}I can see the message
{color:#800000}*"Message sent to queue"*{color}
in the log file right after I see the
*{color:#800000}
"Request Entity persisted"{color}*
message. So it correct to assume that the message is infact sent to the queue.
Here is the md bean that gets the message from the queue and process it
@MessageDriven(activationConfig =
@ActivationConfigProperty(propertyName="destinationType",
propertyValue="javax.jms.Queue"),
@ActivationConfigProperty(propertyName="destination",
propertyValue="queue/requestmdb")
public class RequestMessageDrivenBean implements MessageListener {
@EJB
private MSSessionEJBLocal ejbObj;
public void onMessage(Message message) {
try{
System.out.println("Message recived ");
if(message instanceof MapMessage) {
System.out.println("This is a instance of MapMessage");
MapMessage mMsg = (MapMessage) message;
long rId = mMsg.getLong("request");
List<Request> rList = ejbObj.getRequestById(new Long(rId));
System.out.println("rList size is " + rList.size());
for(Request r: rList) {
//Does something and print something in logs
System.out.println("Finsihed onMessage");
}catch(Exception e) {
System.out.println(e.getMessage());
}    One thing to note here is that getRequestById is another method in the same session bean MSSessionEJB. Can that be the reason for not loading the request from the database when many concurrent request are present? Here is what it does
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public List<Request> getRequestById(Long id) throws Exception {
System.out.println("Inside getRequestById id is " + id);
return em.createNamedQuery("Request.findById")
.setParameter("id", id)
.getResultList();
}    In the logs I do see
{color:#800000}*"This is a instance of MapMessage"*{color}
and I do see the correct Rid that was persisted before in the log
*{color:#800000}
"inside getRequestById id is 12"{color}*
. Finally I do see
*{color:#800000}
"Finsihed onMessage"{color}*
for all the request no matter how many are sent concurrently.
*{color:#ff0000}Here is where the problem is . rList size is 1 for most of the cases but it returns 0 when the number of concurrent message exceeds 10.*
*{color}*
So you see there is no exception per se, just that entity does not get loaded from the database. I would like to mention this again, it does work properly when the number of concurrent request are less than 10. All the invocation of onMessage in MB are able to load the entity properly in that case. Its only when the number of concurrent request increases more than 10, the onMessage is unable to load the entity and the rList is 0.
FYI I am using jboss-4.2.2.GA on RedHat enterprise linux 4 with jdk1.6.0_04
Please let me know if there is more information required on this.
Thank you

Invoke Java Concurrent program from PL/ SQL

Hi Experts,
I 've a requirement to invoke a Java Concurrent program form PL/ SQL. I 've defined default values for some of the parameters in the Java Concurrent program definition and some parameters do not have a default value. I would like to provide only the mandatory attributes that do not have a default value set from my PL/ SQL code. Can you please suggest how this can be achieved?
I tried giving null for those attributes. But, the java program takes a "" value instead of the default values. Any inputs here will be immensely helpful.
Thanks,
Ganapathi

Updating the correct format to be used for reference:
The correct format is:
fnd_request.submit_request(
application => 'PDT_CODE',
program => 'PGM_NAME', --program IN varchar2 default NULL,
start_time=> SYSDATE, --start_time IN varchar2 default NULL,
sub_request => FALSE, --sub_request IN boolean default FALSE
argument1 => rowdata,
argument2 => xxx
Note: the parameter name should be "argument1...n" (and not the actual argument name).
But I noticed that for parameters that are missed out, the default values still do not take effect. Can anyone please confirm this behavior?
Thanks,
Ganapathi

Concurrent Editing Excel Workbook Sharepoint Online

I am having an issue that hopefully someone out there has some experience with.
We have a deployment of Sharepoint online working right now and we are running into an issue where Excel documents can only be edited by 1 person at a time. I need for those workbooks be be able to allow multiple people to get in to edit concurrently.
I have went through the options to share workbook but that doesn't seem to work.
What am I missing? It seems like Sharepoint should allow for this type of behavior.
Sean
This topic first appeared in the Spiceworks Community

Hi,
For your issue, there are some things you can try:
If you have Excel installed on your device, you can download the workbook and then open it in Excel.
If you have edit permissions to the workbook, you can try to
reduce the workbook's file size.
If you do have Power BI for Office 365 and the workbook contains a Data Model, you can check to see if the workbook is visible in
Power BI sites on Power BI for Office 365 and
enabled for web viewing.
If you don’t already have
Power BI for Office 365, you can sign up for it. Ask your administrator for help with this.
For more information, refer to the following article:
https://support.office.com/en-us/article/File-size-limits-for-workbooks-in-SharePoint-Online-9e5bc6f8-018f-415a-b890-5452687b325e?ui=en-US&rs=en-US&ad=US
Best Regards,
Lisa Chen
Lisa Chen
TechNet Community Support

ConcurrentModificationException - concurrent requests while lazy loading a relationship without server warmup

Hello,
We are running into a ConcurrentModificationException when we are firing 100 concurrent requests without warming up the server.
Looks like the error is coming up when a a relationship is being lazy loaded.
We are seeing this behavior consistently. Once the server is warmed up, we are not seeing any issues under concurrency.
I am attaching the two DAOs that are related to the issue.
ExtensionPointRulesetDAO has a M:1 relationship with RuleSetEntityDAO and we are getting the error when ExtensionPointRuleSetDAO._persistence_get_ruleSetEntity() is called.
2015-02-13 12:14:24,021 ERROR [uimadmin] [[ACTIVE] ExecuteThread: '11' for queue: 'weblogic.kernel.Default (self-tuning)'] [ExtensionRuleMediator] [INV-180012] Failed to retrieve the extension point ruleset: null.
java.util.ConcurrentModificationException
    at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
    at java.util.ArrayList$Itr.next(ArrayList.java:831)
    at org.eclipse.persistence.internal.databaseaccess.ParameterizedSQLBatchWritingMechanism.executeBatchedStatements(ParameterizedSQLBatchWritingMechanism.java:134)
    at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:574)
    at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:535)
    at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1717)
    at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:253)
    at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:207)
    at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:193)
    at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectOneRow(DatasourceCallQueryMechanism.java:666)
    at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectOneRowFromTable(ExpressionQueryMechanism.java:2656)
    at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectOneRow(ExpressionQueryMechanism.java:2627)
    at org.eclipse.persistence.queries.ReadObjectQuery.executeObjectLevelReadQuery(ReadObjectQuery.java:450)
    at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:1081)
    at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:844)
    at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1040)
    at org.eclipse.persistence.queries.ReadObjectQuery.execute(ReadObjectQuery.java:418)
    at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1128)
    at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2871)
    at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1516)
    at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1498)
    at org.eclipse.persistence.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:98)
    at org.eclipse.persistence.internal.indirection.QueryBasedValueHolder.instantiateForUnitOfWorkValueHolder(QueryBasedValueHolder.java:113)
    at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiateImpl(UnitOfWorkValueHolder.java:156)
    at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:222)
    at org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:88)
    at oracle.communications.platform.entity.impl.ExtensionPointRuleSetDAO._persistence_get_ruleSetEntity(ExtensionPointRuleSetDAO.java)
    at oracle.communications.platform.entity.impl.ExtensionPointRuleSetDAO.getRuleSetEntity(ExtensionPointRuleSetDAO.java:272)
    at oracle.communications.inventory.extensibility.extension.util.ExtensionRuleMediator.findExtensionPointRule(ExtensionRuleMediator.java:267)
    at oracle.communications.inventory.extensibility.extension.util.ExtensionRuleMediator.initialize(ExtensionRuleMediator.java:134)
    at oracle.communications.inventory.extensibility.extension.SpecBasedArgumentExtension.configureMediator(SpecBasedArgumentExtension.aj:134)
Thanks,
Ravindra

Hi,
Found a note explaining the significance of these errors.
It says:
"NZE-28862: SSL connection failed
Cause: This error occurred because the peer closed the connection.
Action: Enable Oracle Net tracing on both sides and examine the trace output. Contact Oracle Customer support with the trace output."
For further details you may refer the Note: 244527.1 - Explanation of "SSL call to NZ function nzos_Handshake failed" error codes
Thanks & Regards,
Sindhiya V.

Concurrent GC Behavior?

Similar Messages

Maybe you are looking for