MDB / threads allocation : doubt

          Hello Tom,
          you wrote that :
          "Remember that an MDB will use up to half+1 of the thread pool."
          Sorry, but I've not understood.
          Do you mean that, if I have one MDB, 12 available threads (considering 3 threads
          for container's activities), I can have a max concurrency of 6+1 MDB executing
          I've implemented a simple MDB with a sleep inside.
          I've sent 12 messages to the destination (queue).
          All 12 threads have been "occupied" by the MDBs (and the 13th message is not processed,
          until one of the 12 MDBs wakes up), and I've not seen this limit (half+1).
          Please can you explain ?
          Thanks in advance
          Sergi

          Thanks Tom !
          Sergi
          Tom Barnes <[email protected]> wrote:
          >
          >Sergi Vaz wrote:
          >> Hello Tom,
          >> thanks for the reply.
          >>
          >> I've done my test with 6.1sp4, and I did not see this limit (I've occupied
          >all
          >> threads with MDBs waiting in the default queue).
          >>
          >> I've verified it with a thread dump.
          >>
          >> What have I done wrong ?
          >
          >Nothing. The internal tracking system I consulted
          >stated that the limit was added in SP4, but
          >it didn't make it in until SP5. This time
          >I checked the actual source code. Sorry about
          >the confusion. For now, just set
          >"max-beans-in-free-pool" to limit the concurrency.
          >
          >Tom
          >
          >
          >>
          >> Thanks in advance
          >>
          >> Sergi
          >>
          >>
          >>
          >> Tom Barnes <[email protected]> wrote:
          >>
          >>>Hi Sergi,
          >>>
          >>>It turns out that the "half+1" MDB thread usage
          >>>limit was put in effect in 6.1SP4, 7.0SP1, and 8.1.
          >>>In previous versions, I highly
          >>>recommend setting the MDB's "max-beans-in-free-pool"
          >>>to something reasonably smaller than the default execute thread
          >>>pool size to help prevent possible dead locks.
          >>>
          >>>To provide more control, 7.0SP? and 8.1 allow you to
          >>>specify "dispatch-policy" in the weblogic descriptor xml
          >>>to cause the MDB run in a thread pool you
          >>>have configured. In which case the "half-plus-one"
          >>>limit is not imposed.
          >>>
          >>>Tom
          >>>
          >>>Sergi Vaz wrote:
          >>>
          >>>>Hello Tom,
          >>>>
          >>>>you wrote that :
          >>>>
          >>>>"Remember that an MDB will use up to half+1 of the thread pool."
          >>>>
          >>>>Sorry, but I've not understood.
          >>>>
          >>>>Do you mean that, if I have one MDB, 12 available threads (considering
          >>>
          >>>3 threads
          >>>
          >>>>for container's activities), I can have a max concurrency of 6+1 MDB
          >>>
          >>>executing
          >>>
          >>>>?
          >>>>
          >>>>I've implemented a simple MDB with a sleep inside.
          >>>>I've sent 12 messages to the destination (queue).
          >>>>
          >>>>All 12 threads have been "occupied" by the MDBs (and the 13th message
          >>>
          >>>is not processed,
          >>>
          >>>>until one of the 12 MDBs wakes up), and I've not seen this limit (half+1).
          >>>>
          >>>>Please can you explain ?
          >>>>
          >>>>Thanks in advance
          >>>>
          >>>>Sergi
          >>>>
          >>>>
          >>>>
          >>>
          >>
          >

Similar Messages

Adapter queues and thread allocation

I have browsed through the forums for Adapter threads and message queue related issues but still dont have complete clarity on this topic.
Scenario-
Say i have only one file adapter interface in my XI box, an that file adapter is reading a 500 mb file and it has a pollling interval of 5mins, the file is not completely read within the first 5 mins.
Question-
Now will the thread allocated to this adapter be alive and keep reading this file or will it be released when the next polling interval starts?
So what happens when the polling interval is exceeded?
(Assume there is no parallel processing)
will a new thread be allocated to the adapter ?
If yes will it start processing the file or will it wait until the completion of the first thread ?
According to the New Queueing Scheme in XI 3.0 SP19 / 7.0 SP11
a sender file adaper in sync mode has one queue assigned to it and Send.maxConsumers=5, say.
Consider a situation where i have 6 file adapters all reading 50mb files,
Will one of the file adapter threads will be blocked because all the 5 threads would be in use simultaneously?
If a large file is being read and is being written in the message queue all the other threads would have to wait till the file is fully read and will be in the blocked state right?
Appreciate any help.
Thanx
Siva

Hi,
For each adapter there are four queues..
File_http://sap.com/xi/XI/SystemCall
File_http://sap.com/xi/XI/SystemRecv
File_http://sap.com/xi/XI/SystemRqst
File_http://sap.com/xi/XI/SystemSend
and each of the above queues will have threads assigned.(5 by default)
If these queue threads are all busy at atime then the message status will be set in Waiting Status...
Once a message is read via Call queue ,data will be sent to Adapter engine Messaging System via Recv queue...
Similarly in recieving side data will be received from IE via Rqst and send to adapter via Send queue..if target system is busy i.e adapter thread is keep running and there are 6 instances of the same type then message status will be Waiting/To Be Delivered while the message status of processing messages will be Delivering.
So in your case data will be read via Call queue and passed on the Recv queue..which result in availability of queue ..even if set interval elapses..
Hope this gives you an insight
Regards
Rajesh

Starvation in EJB/MDB thread pool ?

I am re-posting this article including the acronym EJB in the subject so that the EJB experts don't overlook this question. This question was moved from the JMS newsgroup to this newsgroup by a BEA moderator.
Our application receives 10 different types of messages on one queue each. Thus we have 10 queues (MQ as a Foreign JMS provider with MDBs in a WLS). We have MDBs processing each of these queues. The producer (mainframe) that sends messages to these queues operates in batch mode.
Option (1) Configure all MDBs in the same custom thread pool. If a blast of 500 messages arrives on one of the queues and all the threads start consuming messages, what happens to new messages that arrive on other queues ? Do they have to wait until these 500 messages are processed ? I would like someone from the BEA JMS implementation team to comment on this.
Option (2) Configure smaller custom thread pools - one for each queue. Solves the problem above. Let us say we allocate 2 threads per MDB in custom thread pools. This ensures that none of the queues starve, however, if there is a practical limit on the maximum number of threads that can be configured, then this option introduces an inefficiency. What if there are 200 messages in one queue and zero messages in all others ? We are allowing only two threads to process those 200 messages while the other threads just sit and watch.

I am re-posting this article including the acronym EJB in the subject so that the EJB experts don't overlook this question. This question was moved from the JMS newsgroup to this newsgroup by a BEA moderator.
Our application receives 10 different types of messages on one queue each. Thus we have 10 queues (MQ as a Foreign JMS provider with MDBs in a WLS). We have MDBs processing each of these queues. The producer (mainframe) that sends messages to these queues operates in batch mode.
Option (1) Configure all MDBs in the same custom thread pool. If a blast of 500 messages arrives on one of the queues and all the threads start consuming messages, what happens to new messages that arrive on other queues ? Do they have to wait until these 500 messages are processed ? I would like someone from the BEA JMS implementation team to comment on this.
Option (2) Configure smaller custom thread pools - one for each queue. Solves the problem above. Let us say we allocate 2 threads per MDB in custom thread pools. This ensures that none of the queues starve, however, if there is a practical limit on the maximum number of threads that can be configured, then this option introduces an inefficiency. What if there are 200 messages in one queue and zero messages in all others ? We are allowing only two threads to process those 200 messages while the other threads just sit and watch.

Thread safe doubt

Hi every1
My question:
Multiple threads enter the method att()...i want to count how much time does attacher.attach() method takes for every thread that comes in...i think the code below works... but if i declared the timeTakenForAttach as global variable..someone told me its not thread safe...can some1 please explain me the meaning of all this OR can i declare timeTakenForAttach as global and it won't be a problem..
class A{
long totalAttachSetupMillis=0L;
public void att() {
      long start = System.currentTimeMillis();
               attacher.attach();
      long timeTakenForAttach = System.currentTimeMillis() - start;
       recordAttachSuccess (timeTakenForAttach);
   public synchronized void recordAttachSuccess(long timeForAttach){
          totalAttachSetupMillis += timeForAttach;
}Thankyou..

javanewbie83 wrote:
I have to sychronize record sucess as different threads would enter att() and enter record success method and simultaneously update, so i will end up getting a wrong value.Let me give you a more detailed explanation of why NOT having it synchronized would not work.
First of all, let's take a look at the statement of concern:
totalAttachSetupMillis += timeForAttach;For the purposes of synchronization, however, we need to look at it like this:
int temp = totalAttachSetupMillis + timeForAttach; //call this LINE A
totalAttachSetupMillis = temp; //call this LINE BNow, lets say we had threads named 1 and 2. If you didn't sychronize the method, you could possibly have this execution flow:
//initial values: totalAttachSetupMillis = 0, timeForAttack(1) = 20, timeForAttack(2) = 30. Total should be 50
1A //temp(1) = 0 + 20 = 20
2A //temp(2) = 0 + 30 = 30 (remember totalAttachSetupMillis isn't set until B)
2B //totalAttachSetupMillis = temp(2) = 30
1B //totalAttachSetupMillis = temp(1) = 20 (instead of 50)In other words, total disaster could possibly ensue. Which is why you wanted to synchronize it. Ed's explanation of your other question was right on the money, though.

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

JMS consumers and MDBs in free pool

          Hello
          I am using WLS 7.0 SP1. I notice the following when using MDBs listening on
          a JMS queue.
          The WLS console shows the number of JMS consumers to be equal to the <max-free-beans-in-pool>
          parameter value in the MDBs deployment descriptor. I would expect the number of
          JMS consumers to be equal to the <initial-free-beans-in-pool> value before I start
          posting messages to the queue.
          Thanks
          Ramdas


Hi Ramdas,
          I'm fairly sure that this is long-standing behavior, that
          also occurs in 6.1 and 8.1. Since the number of beans
          is limited by the number of available threads, the fact
          that all of them are allocated right away is usually not
          an issue.
          Post to the ejb newsgroup to make sure.
          Tom
          P.S. If you haven't already, I suggest reading
          the most recent version of the JMS performance guide. It
          contains info on tuning MDB threading and pooling. You
          can find the guide on dev2dev.
          Ramdas Hegde wrote:
          > Hello
          >
          > I am using WLS 7.0 SP1. I notice the following when using MDBs listening on
          > a JMS queue.
          > The WLS console shows the number of JMS consumers to be equal to the <max-free-beans-in-pool>
          > parameter value in the MDBs deployment descriptor. I would expect the number of
          > JMS consumers to be equal to the <initial-free-beans-in-pool> value before I start
          > posting messages to the queue.
          >
          > Thanks
          >
          > Ramdas

HP-UX Kernel Params for WLS 6.0SP2 Cluster to Avoid java.lang.outofmemory and/or thread death

          I'm running a WLS 6.0 SP2 clustered application on HP-UX 11i. I'm seeing heap and
          thread issues on start-up or invocation of my application as I deploy EJB's and create
          DB connection pools. These are fairly trivial tasks that don't give me any issues
          when starting the first node. It's only when I invoke the second node.
          I'm pretty sure that my issue is tied to the following kernel areas:
          1. Thread allocation
          2. Heap allocation
          3. Max Processes per user
          Can anyone make some kernel recommendations that might be beneficial to my deployment?
          My app runs on NT/2000 and Sun as well, and I haven't seen these issues. I typically
          allocate 50 to 100 threads per node (3 nodes on a 4 CPU machine) and allocate about
          1GB of RAM per node on a 4GB machine...
          Regards,
          Steve


I'm running a WLS 6.0 SP2 clustered application on HP-UX 11i. I'm seeing          heap and
          > thread issues on start-up or invocation of my application as I deploy
          EJB's and create
          > DB connection pools. These are fairly trivial tasks that don't give me any
          issues
          > when starting the first node. It's only when I invoke the second node.
          >
          > I'm pretty sure that my issue is tied to the following kernel areas:
          >
          > 1. Thread allocation
          > 2. Heap allocation
          > 3. Max Processes per user
          >
          > Can anyone make some kernel recommendations that might be beneficial to my
          deployment?
          > My app runs on NT/2000 and Sun as well, and I haven't seen these issues. I
          typically
          > allocate 50 to 100 threads per node (3 nodes on a 4 CPU machine) and
          allocate about
          > 1GB of RAM per node on a 4GB machine...
          HP has some kernel tuning guidelines for Java server apps on their web site,
          and BEA has some notes as well in their platform support page.
          What issues specifically are you seeing?
          Peace,
          Cameron Purdy
          Tangosol, Inc.
          Clustering Weblogic? You're either using Coherence, or you should be!
          Download a Tangosol Coherence eval today at http://www.tangosol.com/
          "Steve Feldman" <[email protected]> wrote in message
          news:3cdc046e$[email protected]..
          >

Update doubt

I have a problem using update query, for updating one column in a table with another column in another table. For eg say i have two tables, collector and survey
Fields in Collector:
col_n_account_num
col_v_email
col_n_phone_number
Fields in survey
sur_v_question_id
sur_n_account_num
sur_v_response
update collector
case when sur_v_question_id=collector_email then col_v_email=sur_v_response end,
case when sur_v_question_id=collector_phone then col_n_phone_number=sur_v_response end
Thanks in advance
Regards,
ss

Please don't create duplicate threads.
Doubt in Update query

Thread Monitoring in a clustered BPEL environment

Hi BPEL community,
does anybody know how I can monitor the "Pending Requests" and "Thread Allocation Activity" (BPEL Console - Threads) over all cluster-nodes? Inside the BPEL Console I only see the data of the cluster-node I'm logged in.
I was not able to see an over-all cluster-nodes view of the load on the bpel-engine.
Regards, Harald

I am not familior with anything called Quartz but I think this issue should be handled task scheduler itself.
In the place I work the task scheduler we use (I house developed one) has following approach
Once the task is posted it is in "posted" state and once a batch server (Thats what we call the service that executes it) picks a task up it changes the state to "executing". Once the execution is complete it change the state to "ready". If an exception occures it will abort the operation and set the state to "error".
Batch Server can pick up only the tasks with state "Posted" so two services will not pick up same task.
By the way the tasks with error state can be reset to posted state by the user.
probably you need a solution like this. Either you have to develop one or find one which considers the existance of multiple execution services

Db_checkpoint: Unable to allocate thread control block

Hello,
Every second day BDB 4.8 runs out of cache memory (size = 512MB).
We have 10 static worker processes (no segfaults) and one
db_checkpoint-process (checkpoints once a minute and exists).
We use only DB_WRITE_NOSYNC
After two days the db_checkpoint-process reports:
db_checkpoint: Unable to allocate thread control block
As soon as this error apears, I can neither checkpoint nor
db_recover.
Is there any chance (or a patch) to track down the memory leak?
Thanks

Hi Sandra,
It happened again one hour ago. I had hardly problems with BDB 4.6
Down below you will find a current "db_stat -e"
We have 10 workers with persistent db-connection and once a minute
a cronjob starts a checkpoint, then the cron-process exists.
Every second day (40 to 48 hours) the checkpoint-process can't connect
to the database and "db_checkpoint -1" says:
db_checkpoint: Unable to allocate thread control block
A normal "db_recover" would corrupt the database, I had to recover
catastrophic.
For sure the cache is not to small (512 MB, all database files: 1,3 GB)
Thanks
Markus
Mon Nov 30 17:32:44 2009 Local time
0x120897 Magic number
0 Panic value
4.8.24 Environment version
9 Btree version
9 Hash version
1 Lock version
15 Log version
4 Queue version
2 Sequence version
1 Txn version
Mon Nov 30 16:31:06 2009 Creation time
0x9d316701 Environment ID
2 Primary region allocation and reference count mutex [0/360 0% !Own]
11 References
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Thread tracking information
75 Thread blocks allocated
4096 Thread allocation threshold
521 Thread hash buckets
Thread status blocks:
process/thread 5055/3086948768: out
process/thread 5686/3086850464: out
[...snip...]
process/thread 6056/3086653856: out
process/thread 6087/3086649760: out
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
0x40988 Log magic number
15 Log version number
16MB Log record cache size
0 Log file mode
10Mb Current log file size
370618 Records entered into the log
370MB 354KB 853B Log bytes written
4MB 466KB 1001B Log bytes written since last checkpoint
17691 Total log file I/O writes
0 Total log file I/O writes due to overflow
198 Total log file flushes
665 Total log file I/O reads
1786 Current log file number
8303086 Current log file offset
1786 On-disk log file number
3630597 On-disk log file offset
1 Maximum commits in a log flush
1 Minimum commits in a log flush
17MB Log region size
9 The number of region locks that required waiting (0%)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
5387 Last allocated locker ID
0x7fffffff Current maximum unused locker ID
9 Number of lock modes
131072 Maximum number of locks possible
131072 Maximum number of lockers possible
131072 Maximum number of lock objects possible
30 Number of lock object partitions
622 Number of current locks
797 Maximum number of locks at any one time
13 Maximum number of locks in any one bucket
0 Maximum number of locks stolen by for an empty partition
0 Maximum number of locks stolen for any one partition
632 Number of current lockers
708 Maximum number of lockers at any one time
69 Number of current lock objects
160 Maximum number of lock objects at any one time
2 Maximum number of lock objects in any one bucket
0 Maximum number of objects stolen by for an empty partition
0 Maximum number of objects stolen for any one partition
13M Total number of locks requested (13372706)
13M Total number of locks released (13372083)
0 Total number of locks upgraded
5313 Total number of locks downgraded
9 Lock requests not available due to conflicts, for which we waited
1 Lock requests not available due to conflicts, for which we did not wait
0 Number of deadlocks
60M Lock timeout value (60000000)
0 Number of locks that have timed out
60M Transaction timeout value (60000000)
0 Number of transactions that have timed out
66MB 904KB The size of the lock region
2141 The number of partition locks that required waiting (0%)
465 The maximum number of times any partition lock was waited for (0%)
0 The number of object queue operations that required waiting (0%)
3 The number of locker allocations that required waiting (0%)
0 The number of region locks that required waiting (0%)
2 Maximum hash bucket length
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
320MB 1KB 604B Total cache size
1 Number of caches
1 Maximum number of caches
320MB 8KB Pool individual cache size
0 Maximum memory-mapped file size
0 Maximum open file descriptors
0 Maximum sequential buffer writes
0 Sleep after writing maximum sequential buffers
0 Requested pages mapped into the process' address space
17M Requested pages found in the cache (99%)
71264 Requested pages not found in the cache
67 Pages created in the cache
71264 Pages read into the cache
17944 Pages written from the cache to the backing file
0 Clean pages forced from the cache
0 Dirty pages forced from the cache
0 Dirty pages written by trickle-sync thread
71298 Current total page count
71014 Current clean page count
284 Current dirty page count
32771 Number of hash buckets used for page location
4096 Assumed page size used
16M Total number of times hash chains searched for a page (16751183)
8 The longest hash chain searched for a page
39M Total number of hash chain entries checked for page (39437498)
0 The number of hash bucket locks that required waiting (0%)
0 The maximum number of times any hash bucket lock was waited for (0%)
7 The number of region locks that required waiting (0%)
0 The number of buffers frozen
0 The number of buffers thawed
0 The number of frozen buffers freed
71627 The number of page allocations
0 The number of hash buckets examined during allocations
0 The maximum number of hash buckets examined for an allocation
0 The number of pages examined during allocations
0 The max number of pages examined for an allocation
0 Threads waited on page I/O
0 The number of times a sync is interrupted
Pool File: article.db
4096 Page size
0 Requested pages mapped into the process' address space
1868517 Requested pages found in the cache (99%)
13311 Requested pages not found in the cache
0 Pages created in the cache
13311 Pages read into the cache
3428 Pages written from the cache to the backing file
[...snip...]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
1786/3630541 File/offset for last checkpoint LSN
Mon Nov 30 17:32:01 2009 Checkpoint timestamp
0x8000675a Last transaction ID allocated
4096 Maximum number of active transactions configured
0 Active transactions
3 Maximum active transactions
26458 Number of transactions begun
0 Number of transactions aborted
26458 Number of transactions committed
0 Snapshot transactions
0 Maximum snapshot transactions
0 Number of transactions restored
1MB 192KB Transaction region size
0 The number of region locks that required waiting (0%)
Active transactions:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
31MB 32KB Mutex region size
3 The number of region locks that required waiting (0%)
4 Mutex alignment
150 Mutex test-and-set spins
254163 Mutex total count
149165 Mutex free count
104998 Mutex in-use count
104998 Mutex maximum in-use count
Mutex counts
149165 Unallocated
1 env region
33 lock region
797 logical lock
1 log filename
1 log flush
1 log region
74 mpoolfile handle
71298 mpool buffer
17 mpool file bucket
32771 mpool hash bucket
1 mpool region
1 mutex region
1 transaction checkpoint
1 txn region

BPEL Client API - Query Domain for Number of Active Threads ?

Hi,
Is there a method to query the number of active threads within the domain ? i.e. the same value displayed under Thread Allocation Activity shown on http://localhost/BPELConsole/default/domain.jsp?mode=thread
I've browsed the API docs but can't find a way to do this... I might have missed something thought.
Cheers,
Rob

Thanks Marc.
How would I go about getting a domain handle ? The bit I'm stuck on in obtaining the initial authenticated connection to the server. The ngThreadInfo code does this:
Server server = ServletUtils.getServer( request, response );
String token = server.getServerAuth().getToken();
and I guess the request/response vars provide the security context in which the getServerAuth operates ?
Which API functions can I embed in a BPEL process to connect to the server and subsequently obtain the domain handle ?
Cheers,
Rob J.

Server threads

how can i know server threads allocated to the Essbase Server process. If it is default server threads ,it depends on the ports.
Could u please tell how server threads depend on ports

Thanx for yuor information sandeep.
But my intention is to know the server threads(exact count) allocated to the Essbase Server process initially.
I know that it equals to some value depending on the default ports.
But the ports are of three types here.
In our case,
number of ports in use = 1
number of ports available =65534
number of licensed ports = 65535
I am not sure of licensed ports as i have taken that value in the LICENSE tab having number of installed ports.
Now my question is to know the server threads which ports i have to consider
Your advise is highly appreciated

Unable to Start Presentation Server - Allocation of SQLEnvironment failed

Hi Team,
i am facing the following issue. could someone please assit.
Oracle BI Presentation Services 10.1.3.4 (Build 080726.1900) are starting up.
Type: Error
Severity: 20
Time: Sat Jun 11 10:32:05 2011
File: project/webodbcaccess/odbcenvironment.cpp Line: 98
Properties: ThreadID-4012
Location:
     saw.webextensionbase.staticinit
     saw.sawserver
     saw.sawserver.initializesawserver
     saw.threads
ODBC driver preload failed. ODBC library name: 'nqsodbc.dll'
Type: Error
Severity: 20
Time: Sat Jun 11 10:32:05 2011
File: project/webodbcaccess/odbcenvironment.cpp Line: 100
Properties: ThreadID-4012
Location:
     saw.webextensionbase.staticinit
     saw.sawserver
     saw.sawserver.initializesawserver
     saw.threads
The specified module could not be found.
Type: Error
Severity: 42
Time: Sat Jun 11 10:32:05 2011
File: project/webodbcaccess/odbcenvironment.cpp Line: 195
Properties: ThreadID-4012
Location:
     saw.webextensionbase.staticinit
     saw.sawserver
     saw.sawserver.initializesawserver
     saw.threads
Type: Error
Severity: 20
Time: Sat Jun 11 10:32:05 2011
File: project/sawserver/winmain.cpp Line: 74
Properties: ThreadID-4012
Location:
     saw.sawserver.initializesawserver
     saw.threads
Allocation of SQLEnvironment failed (SQLError: -1). Please ensure that the odbc driver is in your environment path.
Type: Error
Severity: 30
Time: Sat Jun 11 10:32:05 2011
File: project/webcomm/rpcserver.cpp Line: 145
Properties:
Location:
     saw.unknown
Assertion failure: m_pImpl != 0 at line 145 of ./project/webcomm/rpcserver.cpp
Type: Information
Severity: 30
Time: Sat Jun 11 10:33:34 2011
File: project/sawserver/sawserver.cpp Line: 386
Properties: ThreadID-4264
Location:
     saw.sawserver
     saw.sawserver.initializesawserver
     saw.threads

It seems you've got the wrong forum. Look for a different forum category covering BI products.

LV threading 8.5 much worse than 8.2??? (or is it VISA or NIDAQmxbase?)

I have an application that is heavily threaded and has multiple (ie 6 or more) parallel loops. I recently migrated this from LV 8.2.1 to LV 8.5.1. With one exception (bad control that crashed LV) it upgraded fine. However performance has degraded immensely!!!! This program does multiple serial I/O, GPIB I/O, DAQ, Digital I/O etc. all in different loops.
The DAQ used to loop at a 1 second time and keep up with 80 kHz on 32 channels (6033 board). Now it doesn't keep up most of the time at 16 kHz and I am plagued by buffer overruns. This is 5 times slower and still not keeping up. This is a dual CPU system and has almost maxed out one of the CPUs now.
I have also migrated from VISA 4.2 to 4.4 and NIDAQmx base from 3.0 to 3.2. This is all under Mac OS X just so folks don't suggest using regular NIDAQmx. The VISA updates are minor and should not affect this as are the NIDAQmx updates.
Any ideas as to why the simple upgrade from 8.2.1 to 8.5.1 would result is such a terrible loss of performance?

Actually the loops are all on an independent 1 second cycle. There is very little data passed between loops. Mostly written to a local array. One slow loop (ie 15 minute cycle) writes to a data log file from that array. Others do independent PID etc. One checks and pages operators.
The only synchronization is an occurance that I use to create an interruptible wait in the loops of 1 second.
Ben,
Yes, I open the DAQ reference and don't close it ever. In fact this is one of the large problems with NIDAQmx base. I have to have the data acquired continuously and then read it. If I keep the reference but "restart" the DAQ every loop it re-initializes the hardware and is VERY slow. So I actually start the DAQ outside the loop. I then read continuously, when there is the inevitable buffer overrun, the DAQ stops and I detect this error and restart it in this case. But that is a good point and was a BIG problem in moving from old DAQ to NIDAQmx base when I upgraded from LV 5.1 to LV 8.0!
This app has exposed many weaknesses in LV since I wrote it as a massively parallel system back in 199X (Started in LV 3 and finished in LV 5.1). Since then I have made minimal tweaks as it upgraded to newer hardware and newer LV.
At the moment I am suspecting the Asynchronous VISA calls. I have found that Asynchronous VISA calls actually chew up CPU more than Synchronous ones. (Yes I did not reverse the terminology). An asynchronous VISA call actually internally spins a poll on the I/O and uses a lot of CPU time. A synchronous call just blocks that thread. Since it is in maintenance mode there may be something that is unplugged and taking a long time to timeout and locking up the CPU.
Today's project is to run the profiler and find the VISA calls (there should be only 4 of them) and mess with the async vs. Sync setting. Also to crank up the number of threads allocated to the execution systems. ASFAIK this system ran perfectly fine yesterday with LV 8.2 and is now having buffer overruns with LV 8.5. This was supposed to be a simple upgrade. Of course I have all the old stuff saved and can back out.

Cannot allocate native thread

Hello,
After having fix a fd limit, I get now exceptions about thread allocation. I'm using latest JRockit for JBoss on a Fedora Core 4.
The exception is :
<pre>java.lang.Error: Error starting thread: Cannot allocate memory.
at java.lang.Thread.start0()V(Native Method)
at java.lang.Thread.start()V(Unknown Source)</pre>
I've tried decreasing max heap memory to ~600m (of 1Gb total) but it does not solve the trouble.
I get the same error with sun JDK, thread-max of OS is set to 32761.

Threads are not all mine in fact, most of them are jboss threads. Watching java proc, VmRSS seems to be too high considering VmSize.
<pre>Fri Oct 27 09:57:02 CEST 2006:Name: java; State: S (sleeping); SleepAVG: 88%; Tgid: 22095; Pid: 22095; PPid: 22089; TracerPid: 0; Uid: 0 0 0 0; Gid: 0 0 0 0; FDSize: 1024; Groups: 0 1 2 3 4 6 10 ; VmSize: 1001880 kB; VmLck: 0 kB; VmRSS: 978188 kB; VmData: 990624 kB; VmStk: 2048 kB; VmExe: 60 kB; VmLib: 7620 kB; VmPTE: 1980 kB; StaBrk: 08058000 kB; Brk: 08be9000 kB; StaStk: bfc8e430 kB; ExecLim: ffffffff; Threads: 60; SigQ: 1/24572; SigPnd: 0000000000000000; ShdPnd: 0000000000000000; SigBlk: 0000000000000000; SigIgn: 0000000000000000; SigCgt: 3000000180405ecf; CapInh: 0000000000000000; CapPrm: 00000000fffffeff; CapEff: 00000000fffffeff; Cpus_allowed: ffffffff; Mems_allowed: 1;</pre>

MDB / threads allocation : doubt

Similar Messages

Maybe you are looking for