Search Results

Search found 1122 results on 45 pages for 'concurrent'.

Page 12/45 | < Previous Page | 8 9 10 11 12 13 14 15 16 17 18 19  | Next Page >

• Problem reading from two separate InputStreams

  - by Emil H

  I'm building a Yammer client for Android in Scala and have encountered the following issue. When two AsyncTasks try to parse an XML response (not the same, each task has it's own InputStream) from the Yammer API the underlying stream throws a IOException with the message "null SSL pointer", as seen below: Uncaught handler: thread AsyncTask #1 exiting due to uncaught exception java.lang.RuntimeException: An error occured while executing doInBackground() at android.os.AsyncTask$3.done(AsyncTask.java:200) at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:234) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:258) at java.util.concurrent.FutureTask.run(FutureTask.java:122) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:648) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:673) at java.lang.Thread.run(Thread.java:1060) Caused by: java.io.IOException: null SSL pointer at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.nativeread(Native Method) at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.access$300(OpenSSLSocketImpl.java:55) at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl$SSLInputStream.read(OpenSSLSocketImpl.java:524) at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:103) at org.apache.http.impl.io.AbstractSessionInputBuffer.read(AbstractSessionInputBuffer.java:134) at org.apache.http.impl.io.ContentLengthInputStream.read(ContentLengthInputStream.java:174) at org.apache.http.impl.io.ContentLengthInputStream.read(ContentLengthInputStream.java:188) at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:178) at org.apache.harmony.xml.ExpatParser.parseFragment(ExpatParser.java:504) at org.apache.harmony.xml.ExpatParser.parseDocument(ExpatParser.java:467) at org.apache.harmony.xml.ExpatReader.parse(ExpatReader.java:329) at org.apache.harmony.xml.ExpatReader.parse(ExpatReader.java:286) at javax.xml.parsers.SAXParser.parse(SAXParser.java:361) at org.mediocre.util.XMLParser$.loadXML(XMLParser.scala:28) at org.mediocre.util.XMLParser$.loadXML(XMLParser.scala:12) ..... Searching for the error didn't give much clarity. Does this have something to do with the response from the server? Or is it something else? Complete code can be found at: http://github.com/archevel/YammerTime I get no error if I wait until the first repsponse is finished and then let the other complete. The request is made with the DefaultHttpClient, but this is supposedly thread safe. What am I missing? If anything needs to be clarified just ask :) Cheers, Emil H

  Read the article

• How to deploy on a remote machine using hudson's WAS Builder Plugin?

  - by Peter Schuetze

  I have a hudson build server (Windows) that does not have Websphere installed. I created a Hudson node that I connect to via SSH. I also installed the WAS Builder Plugin to run jython scripts on the AIX machine. The job that uses the WAS Builder Plugin is tied to the AIX box. I run into errors. Does anybody know, whether that setup might work or if a different setup will work for the WAS Builder Plugin? EDIT: I get following Error Message: [test] $ cmd /c call /tmp/hudson9035964108103168395.bat FATAL: command execution failed java.io.IOException: cmd: not found at java.lang.UNIXProcess.fullPath(UNIXProcess.java:372) at java.lang.UNIXProcess.<init>(UNIXProcess.java:178) at java.lang.ProcessImpl.start(ProcessImpl.java:114) at java.lang.ProcessBuilder.start(ProcessBuilder.java:466) at hudson.Proc$LocalProc.<init>(Proc.java:149) at hudson.Proc$LocalProc.<init>(Proc.java:121) at hudson.Launcher$LocalLauncher.launch(Launcher.java:633) at hudson.Launcher$ProcStarter.start(Launcher.java:268) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:778) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:754) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:270) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:432) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:284) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:810) Finished: FAILURE I am wondering whether that plugin can be executed on a slave, especially in my case where the master is on Windows and the slave on AIX.

  Read the article

• Android - How to Use SQLiteDatabase.open?

  - by Edwin Lee

  Hi all, i'm trying to use SQLiteDatabase.openDatabase( "/data/data/edwin11.myapp/databases/myapp.db", null, (SQLiteDatabase.CREATE_IF_NECESSARY | SQLiteDatabase.NO_LOCALIZED_COLLATORS)); to create/open a database instead of making use of the SQLiteOpenHelper (because i want to pass in the flag SQLiteDatabase.NO_LOCALIZED_COLLATORS. However, i am getting this exception for that line of code: 04-18 09:50:03.585: ERROR/Database(3471): sqlite3_open_v2("/data/data/edwin11.myapp/databases/myapp.db", &handle, 6, NULL) failed 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): java.lang.RuntimeException: An error occured while executing doInBackground() 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): at android.os.AsyncTask$3.done(AsyncTask.java:200) 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:234) 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:258) 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): at java.util.concurrent.FutureTask.run(FutureTask.java:122) 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:648) 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:673) 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): at java.lang.Thread.run(Thread.java:1060) 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): Caused by: android.database.sqlite.SQLiteException: unable to open database file 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): at android.database.sqlite.SQLiteDatabase.dbopen(Native Method) 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): at android.database.sqlite.SQLiteDatabase.<init>(SQLiteDatabase.java:1584) 04-18 09:50:03.665: ERROR/AndroidRuntime(3471): at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:638) ... Doing some testing just before that line of code (using File.isExists) shows that the file /data/data/edwin11.myapp/databases/myapp.db does not exist. Would that be the cause of the error? (Or am i just using SQLiteDatabase.openDatabase the wrong way?) Would it help if i create the file beforehand? (Shouldn't that be taken care of by the SQLiteDatabase.CREATE_IF_NECESSARY flag that i passed in?) If creating the file manually is the way to go, is it just an empty file, or do i have to write something to it? Thanks and Regards.

  Read the article

• hudson.util.ProcessTreeTest test error

  - by senzacionale

  error: Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running hudson.util.ProcessTreeTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.181 sec <<< FAILURE! Running hudson.model.LoadStatisticsTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.089 sec Running hudson.util.ArgumentListBuilderTest Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec Running hudson.util.RobustReflectionConverterTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec Running hudson.util.VersionNumberTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.074 sec Running hudson.util.CyclicGraphDetectorTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.038 sec Results : Tests in error: testRemoting(hudson.util.ProcessTreeTest) Tests run: 102, Failures: 0, Errors: 1, Skipped: 0 [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] There are test failures. Please refer to D:\PROJEKTI\Maven\hudson\main\core\target\surefire-reports for the individual test results. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 17 minutes 58 seconds [INFO] Finished at: Fri Jun 11 21:04:46 CEST 2010 [INFO] Final Memory: 85M/152M [INFO] ------------------------------------------------------------------------ error log: ------------------------------------------------------------------------------- Test set: hudson.util.ProcessTreeTest ------------------------------------------------------------------------------- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.181 sec <<< FAILURE! testRemoting(hudson.util.ProcessTreeTest) Time elapsed: 0.169 sec <<< ERROR! org.jvnet.winp.WinpException: Failed to read environment variable table error=299 at .\envvar-cmdline.cpp:114 at org.jvnet.winp.Native.getCmdLineAndEnvVars(Native Method) at org.jvnet.winp.WinProcess.parseCmdLineAndEnvVars(WinProcess.java:114) at org.jvnet.winp.WinProcess.getEnvironmentVariables(WinProcess.java:109) at hudson.util.ProcessTree$Windows$1.getEnvironmentVariables(ProcessTree.java:419) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:270) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) does anyone have any idea what can be wrong in test? Regards

  Read the article

• Java Hibernate/C3P0 error: "Could not obtain connection metadata. An attempt by a client to checkout

  - by Allan

  I'm trying to get some code I was passed up and running. It appears to use the Hibernate framework. I've gotten past most of the errors tweaking the configuration, but this one has me dead stumped. It's trying to connect to two databases: gameapp and gamelog. Both exist. It seems to have issues connecting to gamelog, but none connecting to gameapp (later in the init, it connects to and loads other DBs just fine). Below, I've pasted the error and exception stack dump. I imaging there's something else in the configs, so I've also included the configuration file for that db. I know this is very vague, but I'm hoping some pro can see the stupid mistake I'm missing. <?xml version="1.0" encoding="GBK"?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> <hibernate-configuration> <session-factory> <property name="dialect">org.hibernate.dialect.MySQLDialect</property> <property name="connection.driver_class">com.mysql.jdbc.Driver</property> <property name="connection.url">jdbc:mysql://127.0.0.1:3306/gamelog</property> <property name="connection.username">root</property> <property name="connection.password"></property> <property name="connection.useUnicode">true</property> <property name="connection.characterEncoding">UTF-8</property> <property name="hibernate.jdbc.batch_size">100</property> <property name="jdbc.fetch_size">1</property> <property name="hbm2ddl.auto">none</property><!-- update --> <property name="connection.useUnicode">true</property> <property name="show_sql">true</property> <!-- c3p0-configuration --> <property name="hibernate.connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property> <property name="hibernate.c3p0.min_size">5</property> <property name="hibernate.c3p0.max_size">10</property> <property name="hibernate.c3p0.timeout">30</property> <property name="hibernate.c3p0.idle_test_period">30</property> <property name="hibernate.c3p0.max_statements">0</property> <property name="hibernate.c3p0.acquire_increment">5</property> </session-factory> </hibernate-configuration> Exception and stack trace: 2010-04-30 17:50:00,411 WARN [org.hibernate.cfg.SettingsFactory] - Could not obtain connection metadata java.sql.SQLException: An attempt by a client to checkout a Connection has timed out. at com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:106) at com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:65) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:527) at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) at org.hibernate.connection.C3P0ConnectionProvider.getConnection(C3P0ConnectionProvider.java:35) at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:76) at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:1933) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1216) at com.database.hibernate.util.HibernateFactory.<init>(Unknown Source) at com.database.hibernate.util.HibernateUtil.<clinit>(Unknown Source) at com.server.databaseop.goodOp.GoodOpImpl.initBreedGoods(Unknown Source) at com.server.databaseop.goodOp.GoodOpImpl.access$000(Unknown Source) at com.server.databaseop.goodOp.GoodOpImpl$1.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Caused by: com.mchange.v2.resourcepool.TimeoutException: A client timed out while waiting to acquire a resource from com.mchange.v2.resourcepool.BasicResourcePool@ca470 -- timeout at awaitAvailable() at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1317) at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:557) at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:477) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) ... 18 more

  Read the article

• Cascading S3 Sink Tap not being deleted with SinkMode.REPLACE

  - by Eric Charles

  We are running Cascading with a Sink Tap being configured to store in Amazon S3 and were facing some FileAlreadyExistsException (see [1]). This was only from time to time (1 time on around 100) and was not reproducable. Digging into the Cascading codem, we discovered the Hfs.deleteResource() is called (among others) by the BaseFlow.deleteSinksIfNotUpdate(). Btw, we were quite intrigued with the silent NPE (with comment "hack to get around npe thrown when fs reaches root directory"). From there, we extended the Hfs tap with our own Tap to add more action in the deleteResource() method (see [2]) with a retry mechanism calling directly the getFileSystem(conf).delete. The retry mechanism seemed to bring improvement, but we are still sometimes facing failures (see example in [3]): it sounds like HDFS returns isDeleted=true, but asking directly after if the folder exists, we receive exists=true, which should not happen. Logs also shows randomly isDeleted true or false when the flow succeeds, which sounds like the returned value is irrelevant or not to be trusted. Can anybody bring his own S3 experience with such a behavior: "folder should be deleted, but it is not"? We suspect a S3 issue, but could it also be in Cascading or HDFS? We run on Hadoop Cloudera-cdh3u5 and Cascading 2.0.1-wip-dev. [1] org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory s3n://... already exists at org.apache.hadoop.mapreduce.lib.output.FileOutputFormat.checkOutputSpecs(FileOutputFormat.java:132) at com.twitter.elephantbird.mapred.output.DeprecatedOutputFormatWrapper.checkOutputSpecs(DeprecatedOutputFormatWrapper.java:75) at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:923) at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:882) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1278) at org.apache.hadoop.mapred.JobClient.submitJobInternal(JobClient.java:882) at org.apache.hadoop.mapred.JobClient.submitJob(JobClient.java:856) at cascading.flow.hadoop.planner.HadoopFlowStepJob.internalNonBlockingStart(HadoopFlowStepJob.java:104) at cascading.flow.planner.FlowStepJob.blockOnJob(FlowStepJob.java:174) at cascading.flow.planner.FlowStepJob.start(FlowStepJob.java:137) at cascading.flow.planner.FlowStepJob.call(FlowStepJob.java:122) at cascading.flow.planner.FlowStepJob.call(FlowStepJob.java:42) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.j [2] @Override public boolean deleteResource(JobConf conf) throws IOException { LOGGER.info("Deleting resource {}", getIdentifier()); boolean isDeleted = super.deleteResource(conf); LOGGER.info("Hfs Sink Tap isDeleted is {} for {}", isDeleted, getIdentifier()); Path path = new Path(getIdentifier()); int retryCount = 0; int cumulativeSleepTime = 0; int sleepTime = 1000; while (getFileSystem(conf).exists(path)) { LOGGER .info( "Resource {} still exists, it should not... - I will continue to wait patiently...", getIdentifier()); try { LOGGER.info("Now I will sleep " + sleepTime / 1000 + " seconds while trying to delete {} - attempt: {}", getIdentifier(), retryCount + 1); Thread.sleep(sleepTime); cumulativeSleepTime += sleepTime; sleepTime *= 2; } catch (InterruptedException e) { e.printStackTrace(); LOGGER .error( "Interrupted while sleeping trying to delete {} with message {}...", getIdentifier(), e.getMessage()); throw new RuntimeException(e); } if (retryCount == 0) { getFileSystem(conf).delete(getPath(), true); } retryCount++; if (cumulativeSleepTime > MAXIMUM_TIME_TO_WAIT_TO_DELETE_MS) { break; } } if (getFileSystem(conf).exists(path)) { LOGGER .error( "We didn't succeed to delete the resource {}. Throwing now a runtime exception.", getIdentifier()); throw new RuntimeException( "Although we waited to delete the resource for " + getIdentifier() + ' ' + retryCount + " iterations, it still exists - This must be an issue in the underlying storage system."); } return isDeleted; } [3] INFO [pool-2-thread-15] (BaseFlow.java:1287) - [...] at least one sink is marked for delete INFO [pool-2-thread-15] (BaseFlow.java:1287) - [...] sink oldest modified date: Wed Dec 31 23:59:59 UTC 1969 INFO [pool-2-thread-15] (HiveSinkTap.java:148) - Now I will sleep 1 seconds while trying to delete s3n://... - attempt: 1 INFO [pool-2-thread-15] (HiveSinkTap.java:130) - Deleting resource s3n://... INFO [pool-2-thread-15] (HiveSinkTap.java:133) - Hfs Sink Tap isDeleted is true for s3n://... ERROR [pool-2-thread-15] (HiveSinkTap.java:175) - We didn't succeed to delete the resource s3n://... Throwing now a runtime exception. WARN [pool-2-thread-15] (Cascade.java:706) - [...] flow failed: ... java.lang.RuntimeException: Although we waited to delete the resource for s3n://... 0 iterations, it still exists - This must be an issue in the underlying storage system. at com.qubit.hive.tap.HiveSinkTap.deleteResource(HiveSinkTap.java:179) at com.qubit.hive.tap.HiveSinkTap.deleteResource(HiveSinkTap.java:40) at cascading.flow.BaseFlow.deleteSinksIfNotUpdate(BaseFlow.java:971) at cascading.flow.BaseFlow.prepare(BaseFlow.java:733) at cascading.cascade.Cascade$CascadeJob.call(Cascade.java:761) at cascading.cascade.Cascade$CascadeJob.call(Cascade.java:710) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619)

  Read the article

• How does this method give me a -61 Error?

  - by prestonmarshall

  This is in an application I am using called Mirth, but it appears to be coming from inside an Apache Commons library from a method that checks if something is indeed Base64 encoded or not. All of the docs say the only return is true or false, so how am I getting -61? -61 org.apache.commons.codec.binary.Base64.isBase64(Base64.java:137) org.apache.commons.codec.binary.Base64.discardNonBase64(Base64.java:478) org.apache.commons.codec.binary.Base64.decodeBase64(Base64.java:374) org.apache.commons.codec.binary.Base64.decode(Base64.java:220) com.webreach.mirth.plugins.pdfviewer.PDFViewer.viewAttachments(PDFViewer.java:51) com.webreach.mirth.client.ui.browsers.message.MessageBrowser$16.doInBackground(MessageBrowser.java:1429) com.webreach.mirth.client.ui.browsers.message.MessageBrowser$16.doInBackground(MessageBrowser.java:1426) org.jdesktop.swingworker.SwingWorker$1.call(SwingWorker.java:276) java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) java.util.concurrent.FutureTask.run(FutureTask.java:138) org.jdesktop.swingworker.SwingWorker.run(SwingWorker.java:315) java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) java.lang.Thread.run(Thread.java:637)

  Read the article

• Is there an existing solution to the multithreaded data structure problem?

  - by thr

  I've had the need for a multi-threaded data structure that supports these claims: Allows multiple concurrent readers and writers Is sorted Is easy to reason about Fulfilling multiple readers and one writer is a lot easier, but I really would wan't to allow multiple writers. I've been doing research into this area, and I'm aware of ConcurrentSkipList (by Lea based on work by Fraser and Harris) as it's implemented in Java SE 6. I've also implemented my own version of a concurrent Skip List based on A Provably Correct Scalable Concurrent Skip List by Herlihy, Lev, Luchangco and Shavit. These two implementations are developed by people that are light years smarter then me, but I still (somewhat ashamed, because it is amazing work) have to ask the question if these are the two only viable implementations of a concurrent multi reader/writer data structures available today?

  Read the article

• Twitter 2 for Android crash every time I try uploading multi photos [closed]

  - by Hazz

  Hello, I'm using the new Twitter 2 on Android 2.1. Whenever I hit the button which enables me to upload multiple photos in a single tweet, I always get the error "The application Camera (process com.sonyericsson.camera) has stopped unexpectidly. Please try again". However, uploading a single photo using the camera button in Twitter have no problem, it works. My phone is Sony Ericsson x10 mini pro. I tried signing out and back in, same result. Anything I can do to fix this? This is the log info I got using Log Collector: 02-23 15:05:57.328 I/ActivityManager( 1240): Starting activity: Intent { act=com.twitter.android.post.status cmp=com.twitter.android/.PostActivity } 02-23 15:05:57.338 D/PhoneWindow(15095): couldn't save which view has focus because the focused view com.android.internal.policy.impl.PhoneWindow$DecorView@45726938 has no id. 02-23 15:05:57.688 I/ActivityManager( 1240): Displayed activity com.twitter.android/.PostActivity: 340 ms (total 340 ms) 02-23 15:05:59.018 I/ActivityManager( 1240): Starting activity: Intent { act=android.intent.action.PICK typ=vnd.android.cursor.dir/image cmp=com.sonyericsson.camera/com.sonyericsson.album.grid.GridActivity } 02-23 15:05:59.038 I/ActivityManager( 1240): Start proc com.sonyericsson.camera for activity com.sonyericsson.camera/com.sonyericsson.album.grid.GridActivity: pid=15113 uid=10057 gids={1006, 1015, 3003} 02-23 15:05:59.128 I/dalvikvm(15113): Debugger thread not active, ignoring DDM send (t=0x41504e4d l=38) 02-23 15:05:59.158 I/dalvikvm(15113): Debugger thread not active, ignoring DDM send (t=0x41504e4d l=50) 02-23 15:05:59.448 I/ActivityManager( 1240): Displayed activity com.sonyericsson.camera/com.sonyericsson.album.grid.GridActivity: 423 ms (total 423 ms) 02-23 15:05:59.458 W/dalvikvm(15113): threadid=15: thread exiting with uncaught exception (group=0x4001e160) 02-23 15:05:59.458 E/AndroidRuntime(15113): Uncaught handler: thread AsyncTask #1 exiting due to uncaught exception 02-23 15:05:59.468 E/AndroidRuntime(15113): java.lang.RuntimeException: An error occured while executing doInBackground() 02-23 15:05:59.468 E/AndroidRuntime(15113): at android.os.AsyncTask$3.done(AsyncTask.java:200) 02-23 15:05:59.468 E/AndroidRuntime(15113): at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:273) 02-23 15:05:59.468 E/AndroidRuntime(15113): at java.util.concurrent.FutureTask.setException(FutureTask.java:124) 02-23 15:05:59.468 E/AndroidRuntime(15113): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:307) 02-23 15:05:59.468 E/AndroidRuntime(15113): at java.util.concurrent.FutureTask.run(FutureTask.java:137) 02-23 15:05:59.468 E/AndroidRuntime(15113): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068) 02-23 15:05:59.468 E/AndroidRuntime(15113): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561) 02-23 15:05:59.468 E/AndroidRuntime(15113): at java.lang.Thread.run(Thread.java:1096) 02-23 15:05:59.468 E/AndroidRuntime(15113): Caused by: java.lang.IllegalArgumentException: Unsupported MIME type. 02-23 15:05:59.468 E/AndroidRuntime(15113): at com.sonyericsson.album.grid.GridActivity$AlbumTask.doInBackground(GridActivity.java:202) 02-23 15:05:59.468 E/AndroidRuntime(15113): at com.sonyericsson.album.grid.GridActivity$AlbumTask.doInBackground(GridActivity.java:124) 02-23 15:05:59.468 E/AndroidRuntime(15113): at android.os.AsyncTask$2.call(AsyncTask.java:185) 02-23 15:05:59.468 E/AndroidRuntime(15113): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305) 02-23 15:05:59.468 E/AndroidRuntime(15113): ... 4 more 02-23 15:05:59.628 E/SemcCheckin(15113): Get crash dump level : java.io.FileNotFoundException: /data/semc-checkin/crashdump 02-23 15:05:59.628 W/ActivityManager( 1240): Unable to start service Intent { act=com.sonyericsson.android.jcrashcatcher.action.BUGREPORT_AUTO cmp=com.sonyericsson.android.jcrashcatcher/.JCrashCatcherService (has extras) }: not found 02-23 15:05:59.648 I/Process ( 1240): Sending signal. PID: 15113 SIG: 3 02-23 15:05:59.648 I/dalvikvm(15113): threadid=7: reacting to signal 3 02-23 15:05:59.778 I/dalvikvm(15113): Wrote stack trace to '/data/anr/traces.txt' 02-23 15:06:00.388 E/SemcCheckin( 1673): Get Crash Level : java.io.FileNotFoundException: /data/semc-checkin/crashdump 02-23 15:06:01.708 I/DumpStateReceiver( 1240): Added state dump to 1 crashes 02-23 15:06:02.008 D/iddd-events( 1117): Registering event com.sonyericsson.idd.probe.android.devicemonitor::ApplicationCrash with 4314 bytes payload. 02-23 15:06:06.968 D/dalvikvm( 1673): GC freed 661 objects / 126704 bytes in 124ms 02-23 15:06:11.928 D/dalvikvm( 1379): GC freed 19753 objects / 858832 bytes in 84ms 02-23 15:06:13.038 I/Process (15113): Sending signal. PID: 15113 SIG: 9 02-23 15:06:13.048 I/WindowManager( 1240): WIN DEATH: Window{4596ecc0 com.sonyericsson.camera/com.sonyericsson.album.grid.GridActivity paused=false} 02-23 15:06:13.048 I/ActivityManager( 1240): Process com.sonyericsson.camera (pid 15113) has died. 02-23 15:06:13.048 I/WindowManager( 1240): WIN DEATH: Window{459db5e8 com.sonyericsson.camera/com.sonyericsson.album.grid.GridActivity paused=false} 02-23 15:06:13.078 I/UsageStats( 1240): Unexpected resume of com.twitter.android while already resumed in com.sonyericsson.camera 02-23 15:06:13.098 W/InputManagerService( 1240): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@456e7168 02-23 15:06:21.278 D/dalvikvm( 1745): GC freed 2032 objects / 410848 bytes in 60ms

  Read the article

• Does WCF use the ThreadPool to bring up new instances for a PerCall service?

  - by theburningmonk

  Hi, for a PerCall WCF service whose throttling has been set to be high (say, 200 max concurrent calls) would WCF bring up a new instance and invoke the request on a threadpool thread? If it does, then does this have an impact on the total number of concurrent calls allowed? I ask because I don't seem to ever hit the max number of concurrent calls I've set in the service throttling config but instead a fraction of that number - up to 50 on a 100 MaxConcurrentCalls setting and 160 on a 200 MaxConcurrentCalls setting. Thanks,

  Read the article

• android ftp upload has stopped error

  - by Goxel Arp

  class Asenkron extends AsyncTask<String,Integer,Long> { @Override protected Long doInBackground(String... aurl) { FTPClient con=null; try ` { con = new FTPClient(); con.connect(aurl[0]); if (con.login(aurl[1], aurl[2])) { con.enterLocalPassiveMode(); // important! con.setFileType(http://FTP.BINARY_FILE_TYPE); FileInputStream in = new FileInputStream(new File(aurl[3])); boolean result = con.storeFile(aurl[3], in); in.close(); con.logout(); con.disconnect(); } } catch (Exception e) { Toast.makeText(getApplicationContext(), e.toString(), Toast.LENGTH_LONG).show(); } return null; } protected void onPostExecute(String result) {} } I AM USING THIS CLASS LIKE BELOW.THERE IS BUTTON AND WHENEVER I CLICK THE BUTTON IT SHOULD START FTP UPLOAD PROCESS IN BACKGROUND BUT I GET "PROGRAM HAS STOPPED UNFORTUNATELY" ERROR. Assume that The ftp address and username password pathfile sections are true and I get the internet and network permissions already by the way ... button1.setOnClickListener(new OnClickListener() { public void onClick(View arg0) { new Asenkron().execute("ftpaddress","username","pass","pathfileon telephone"); } }); And here is the logcat for you to analyse the potential error and help me ... 10-13 13:01:25.591: I/dalvikvm(633): threadid=3: reacting to signal 3 10-13 13:01:25.711: I/dalvikvm(633): Wrote stack traces to '/data/anr/traces.txt' 10-13 13:01:25.921: D/gralloc_goldfish(633): Emulator without GPU emulation detected. 10-13 13:01:31.441: W/dalvikvm(633): threadid=11: thread exiting with uncaught exception (group=0x409c01f8) 10-13 13:01:31.461: E/AndroidRuntime(633): FATAL EXCEPTION: AsyncTask #1 10-13 13:01:31.461: E/AndroidRuntime(633): java.lang.RuntimeException: An error occured while executing doInBackground() 10-13 13:01:31.461: E/AndroidRuntime(633): at android.os.AsyncTask$3.done(AsyncTask.java:278) 10-13 13:01:31.461: E/AndroidRuntime(633): at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:273) 10-13 13:01:31.461: E/AndroidRuntime(633): at java.util.concurrent.FutureTask.setException(FutureTask.java:124) 10-13 13:01:31.461: E/AndroidRuntime(633): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:307) 10-13 13:01:31.461: E/AndroidRuntime(633): at java.util.concurrent.FutureTask.run(FutureTask.java:137) 10-13 13:01:31.461: E/AndroidRuntime(633): at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:208) 10-13 13:01:31.461: E/AndroidRuntime(633): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076) 10-13 13:01:31.461: E/AndroidRuntime(633): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569) 10-13 13:01:31.461: E/AndroidRuntime(633): at java.lang.Thread.run(Thread.java:856) 10-13 13:01:31.461: E/AndroidRuntime(633): Caused by: java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare() 10-13 13:01:31.461: E/AndroidRuntime(633): at android.os.Handler.<init>(Handler.java:121) 10-13 13:01:31.461: E/AndroidRuntime(633): at android.widget.Toast$TN.<init>(Toast.java:317) 10-13 13:01:31.461: E/AndroidRuntime(633): at android.widget.Toast.<init>(Toast.java:91) 10-13 13:01:31.461: E/AndroidRuntime(633): at android.widget.Toast.makeText(Toast.java:233) 10-13 13:01:31.461: E/AndroidRuntime(633): at com.example.ftpodak.ODAK$Asenkron.doInBackground(ODAK.java:74) 10-13 13:01:31.461: E/AndroidRuntime(633): at com.example.ftpodak.ODAK$Asenkron.doInBackground(ODAK.java:1) 10-13 13:01:31.461: E/AndroidRuntime(633): at android.os.AsyncTask$2.call(AsyncTask.java:264) 10-13 13:01:31.461: E/AndroidRuntime(633): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305) 10-13 13:01:31.461: E/AndroidRuntime(633): ... 5 more By the way I changed the relevant code like that ; instead of catch (Exception e) { Toast.makeText(getApplicationContext(), e.toString(), Toast.LENGTH_LONG).show(); } I replaced with this code catch (Exception e) { HATA=e.toString(); } And I added the code to button textview1.setText(HATA); So I can see the error on the textview and it is writing that "Android java.net.UnknownHostException: Host is unresolved" But i know that the ftp server is correct and I check the ftp server from the AndFTP application. With the same address login and pass information ftp server is working.So the problem is in my code I think.Any help will be too much appreciated.Anyone who can help me I can give teamviewer to analyse what is the problem ...

  Read the article

• C# 4: The Curious ConcurrentDictionary

  - by James Michael Hare

  In my previous post (here) I did a comparison of the new ConcurrentQueue versus the old standard of a System.Collections.Generic Queue with simple locking.  The results were exactly what I would have hoped, that the ConcurrentQueue was faster with multi-threading for most all situations.  In addition, concurrent collections have the added benefit that you can enumerate them even if they're being modified. So I set out to see what the improvements would be for the ConcurrentDictionary, would it have the same performance benefits as the ConcurrentQueue did?  Well, after running some tests and multiple tweaks and tunes, I have good and bad news. But first, let's look at the tests.  Obviously there's many things we can do with a dictionary.  One of the most notable uses, of course, in a multi-threaded environment is for a small, local in-memory cache.  So I set about to do a very simple simulation of a cache where I would create a test class that I'll just call an Accessor.  This accessor will attempt to look up a key in the dictionary, and if the key exists, it stops (i.e. a cache "hit").  However, if the lookup fails, it will then try to add the key and value to the dictionary (i.e. a cache "miss").  So here's the Accessor that will run the tests: 1: internal class Accessor 2: { 3: public int Hits { get; set; } 4: public int Misses { get; set; } 5: public Func<int, string> GetDelegate { get; set; } 6: public Action<int, string> AddDelegate { get; set; } 7: public int Iterations { get; set; } 8: public int MaxRange { get; set; } 9: public int Seed { get; set; } 10:  11: public void Access() 12: { 13: var randomGenerator = new Random(Seed); 14:  15: for (int i=0; i<Iterations; i++) 16: { 17: // give a wide spread so will have some duplicates and some unique 18: var target = randomGenerator.Next(1, MaxRange); 19:  20: // attempt to grab the item from the cache 21: var result = GetDelegate(target); 22:  23: // if the item doesn't exist, add it 24: if(result == null) 25: { 26: AddDelegate(target, target.ToString()); 27: Misses++; 28: } 29: else 30: { 31: Hits++; 32: } 33: } 34: } 35: } Note that so I could test different implementations, I defined a GetDelegate and AddDelegate that will call the appropriate dictionary methods to add or retrieve items in the cache using various techniques. So let's examine the three techniques I decided to test: Dictionary with mutex - Just your standard generic Dictionary with a simple lock construct on an internal object. Dictionary with ReaderWriterLockSlim - Same Dictionary, but now using a lock designed to let multiple readers access simultaneously and then locked when a writer needs access. ConcurrentDictionary - The new ConcurrentDictionary from System.Collections.Concurrent that is supposed to be optimized to allow multiple threads to access safely. So the approach to each of these is also fairly straight-forward.  Let's look at the GetDelegate and AddDelegate implementations for the Dictionary with mutex lock: 1: var addDelegate = (key,val) => 2: { 3: lock (_mutex) 4: { 5: _dictionary[key] = val; 6: } 7: }; 8: var getDelegate = (key) => 9: { 10: lock (_mutex) 11: { 12: string val; 13: return _dictionary.TryGetValue(key, out val) ? val : null; 14: } 15: }; Nothing new or fancy here, just your basic lock on a private object and then query/insert into the Dictionary. Now, for the Dictionary with ReadWriteLockSlim it's a little more complex: 1: var addDelegate = (key,val) => 2: { 3: _readerWriterLock.EnterWriteLock(); 4: _dictionary[key] = val; 5: _readerWriterLock.ExitWriteLock(); 6: }; 7: var getDelegate = (key) => 8: { 9: string val; 10: _readerWriterLock.EnterReadLock(); 11: if(!_dictionary.TryGetValue(key, out val)) 12: { 13: val = null; 14: } 15: _readerWriterLock.ExitReadLock(); 16: return val; 17: }; And finally, the ConcurrentDictionary, which since it does all it's own concurrency control, is remarkably elegant and simple: 1: var addDelegate = (key,val) => 2: { 3: _concurrentDictionary[key] = val; 4: }; 5: var getDelegate = (key) => 6: { 7: string s; 8: return _concurrentDictionary.TryGetValue(key, out s) ? s : null; 9: };                    Then, I set up a test harness that would simply ask the user for the number of concurrent Accessors to attempt to Access the cache (as specified in Accessor.Access() above) and then let them fly and see how long it took them all to complete.  Each of these tests was run with 10,000,000 cache accesses divided among the available Accessor instances.  All times are in milliseconds. 1: Dictionary with Mutex Locking 2: --------------------------------------------------- 3: Accessors Mostly Misses Mostly Hits 4: 1 7916 3285 5: 10 8293 3481 6: 100 8799 3532 7: 1000 8815 3584 8:  9:  10: Dictionary with ReaderWriterLockSlim Locking 11: --------------------------------------------------- 12: Accessors Mostly Misses Mostly Hits 13: 1 8445 3624 14: 10 11002 4119 15: 100 11076 3992 16: 1000 14794 4861 17:  18:  19: Concurrent Dictionary 20: --------------------------------------------------- 21: Accessors Mostly Misses Mostly Hits 22: 1 17443 3726 23: 10 14181 1897 24: 100 15141 1994 25: 1000 17209 2128 The first test I did across the board is the Mostly Misses category.  The mostly misses (more adds because data requested was not in the dictionary) shows an interesting trend.  In both cases the Dictionary with the simple mutex lock is much faster, and the ConcurrentDictionary is the slowest solution.  But this got me thinking, and a little research seemed to confirm it, maybe the ConcurrentDictionary is more optimized to concurrent "gets" than "adds".  So since the ratio of misses to hits were 2 to 1, I decided to reverse that and see the results. So I tweaked the data so that the number of keys were much smaller than the number of iterations to give me about a 2 to 1 ration of hits to misses (twice as likely to already find the item in the cache than to need to add it).  And yes, indeed here we see that the ConcurrentDictionary is indeed faster than the standard Dictionary here.  I have a strong feeling that as the ration of hits-to-misses gets higher and higher these number gets even better as well.  This makes sense since the ConcurrentDictionary is read-optimized. Also note that I tried the tests with capacity and concurrency hints on the ConcurrentDictionary but saw very little improvement, I think this is largely because on the 10,000,000 hit test it quickly ramped up to the correct capacity and concurrency and thus the impact was limited to the first few milliseconds of the run. So what does this tell us?  Well, as in all things, ConcurrentDictionary is not a panacea.  It won't solve all your woes and it shouldn't be the only Dictionary you ever use.  So when should we use each? Use System.Collections.Generic.Dictionary when: You need a single-threaded Dictionary (no locking needed). You need a multi-threaded Dictionary that is loaded only once at creation and never modified (no locking needed). You need a multi-threaded Dictionary to store items where writes are far more prevalent than reads (locking needed). And use System.Collections.Concurrent.ConcurrentDictionary when: You need a multi-threaded Dictionary where the writes are far more prevalent than reads. You need to be able to iterate over the collection without locking it even if its being modified. Both Dictionaries have their strong suits, I have a feeling this is just one where you need to know from design what you hope to use it for and make your decision based on that criteria.

  Read the article

• AWS elastic load balancer basic issues

  - by Jones

  I have an array of EC2 t1.micro instances behind a load balancer and each node can manage ~100 concurrent users before it starts to get wonky. i would THINK if i have 2 such instances it would allow my network to manage 200 concurrent users... apparently not. When i really slam the server (blitz.io) with a full 275 concurrents, it behaves the same as if there is just one node. it goes from 400ms response time to 1.6 seconds (which for a single t1.micro is expected, but not 6). So the question is, am i simply not doing something right or is ELB effectively worthless? Anyone have some wisdom on this? AB logs: Loadbalancer (3x m1.medium) Document Path: /ping/index.html Document Length: 185 bytes Concurrency Level: 100 Time taken for tests: 11.668 seconds Complete requests: 50000 Failed requests: 0 Write errors: 0 Non-2xx responses: 50001 Total transferred: 19850397 bytes HTML transferred: 9250185 bytes Requests per second: 4285.10 [#/sec] (mean) Time per request: 23.337 [ms] (mean) Time per request: 0.233 [ms] (mean, across all concurrent requests) Transfer rate: 1661.35 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 1 2 4.3 2 63 Processing: 2 21 15.1 19 302 Waiting: 2 21 15.0 19 261 Total: 3 23 15.7 21 304 Single instance (1x m1.medium direct connection) Document Path: /ping/index.html Document Length: 185 bytes Concurrency Level: 100 Time taken for tests: 9.597 seconds Complete requests: 50000 Failed requests: 0 Write errors: 0 Non-2xx responses: 50001 Total transferred: 19850397 bytes HTML transferred: 9250185 bytes Requests per second: 5210.19 [#/sec] (mean) Time per request: 19.193 [ms] (mean) Time per request: 0.192 [ms] (mean, across all concurrent requests) Transfer rate: 2020.01 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 1 9 128.9 3 3010 Processing: 1 10 8.7 9 141 Waiting: 1 9 8.7 8 140 Total: 2 19 129.0 12 3020

  Read the article

• pdns-recursor allocates resources to non-existing queries

  - by azzid

  I've got a lab-server running pdns-recursor. I set it up to experiment with rate limiting, so it has been resolving requests openly from the whole internet for weeks. My idea was that sooner or later it would get abused, giving me a real user case to experiment with. To keep track of the usage I set up nagios to monitor the number of concurrent-queries to the server. Today I got notice from nagios that my specified limit had been reached. I logged in to start trimming away the malicious questions I was expecting, however, when I started looking at it I couldn't see the expected traffic. What I found is that even though I have over 20 concurrent-queries registered by the server I see no requests in the logs. The following command describes the situation well: $ sudo rec_control get concurrent-queries; sudo rec_control top-remotes 22 Over last 0 queries: How can there be 22 concurrent-queries when the server has 0 queries registered? EDIT: Figured it out! To get top-remotes working I needed to set ################################# # remotes-ringbuffer-entries maximum number of packets to store statistics for # remotes-ringbuffer-entries=100000 It defaults to 0 storing no information to base top-remotes statistics on.

  Read the article

• Why lock-free data structures just aren't lock-free enough

  - by Alex.Davies

  Today's post will explore why the current ways to communicate between threads don't scale, and show you a possible way to build scalable parallel programming on top of shared memory. The problem with shared memory Soon, we will have dozens, hundreds and then millions of cores in our computers. It's inevitable, because individual cores just can't get much faster. At some point, that's going to mean that we have to rethink our architecture entirely, as millions of cores can't all access a shared memory space efficiently. But millions of cores are still a long way off, and in the meantime we'll see machines with dozens of cores, struggling with shared memory. Alex's tip: The best way for an application to make use of that increasing parallel power is to use a concurrency model like actors, that deals with synchronisation issues for you. Then, the maintainer of the actors framework can find the most efficient way to coordinate access to shared memory to allow your actors to pass messages to each other efficiently. At the moment, NAct uses the .NET thread pool and a few locks to marshal messages. It works well on dual and quad core machines, but it won't scale to more cores. Every time we use a lock, our core performs an atomic memory operation (eg. CAS) on a cell of memory representing the lock, so it's sure that no other core can possibly have that lock. This is very fast when the lock isn't contended, but we need to notify all the other cores, in case they held the cell of memory in a cache. As the number of cores increases, the total cost of a lock increases linearly. A lot of work has been done on "lock-free" data structures, which avoid locks by using atomic memory operations directly. These give fairly dramatic performance improvements, particularly on systems with a few (2 to 4) cores. The .NET 4 concurrent collections in System.Collections.Concurrent are mostly lock-free. However, lock-free data structures still don't scale indefinitely, because any use of an atomic memory operation still involves every core in the system. A sync-free data structure Some concurrent data structures are possible to write in a completely synchronization-free way, without using any atomic memory operations. One useful example is a single producer, single consumer (SPSC) queue. It's easy to write a sync-free fixed size SPSC queue using a circular buffer*. Slightly trickier is a queue that grows as needed. You can use a linked list to represent the queue, but if you leave the nodes to be garbage collected once you're done with them, the GC will need to involve all the cores in collecting the finished nodes. Instead, I've implemented a proof of concept inspired by this intel article which reuses the nodes by putting them in a second queue to send back to the producer. * In all these cases, you need to use memory barriers correctly, but these are local to a core, so don't have the same scalability problems as atomic memory operations. Performance tests I tried benchmarking my SPSC queue against the .NET ConcurrentQueue, and against a standard Queue protected by locks. In some ways, this isn't a fair comparison, because both of these support multiple producers and multiple consumers, but I'll come to that later. I started on my dual-core laptop, running a simple test that had one thread producing 64 bit integers, and another consuming them, to measure the pure overhead of the queue. So, nothing very interesting here. Both concurrent collections perform better than the lock-based one as expected, but there's not a lot to choose between the ConcurrentQueue and my SPSC queue. I was a little disappointed, but then, the .NET Framework team spent a lot longer optimising it than I did. So I dug out a more powerful machine that Red Gate's DBA tools team had been using for testing. It is a 6 core Intel i7 machine with hyperthreading, adding up to 12 logical cores. Now the results get more interesting. As I increased the number of producer-consumer pairs to 6 (to saturate all 12 logical cores), the locking approach was slow, and got even slower, as you'd expect. What I didn't expect to be so clear was the drop-off in performance of the lock-free ConcurrentQueue. I could see the machine only using about 20% of available CPU cycles when it should have been saturated. My interpretation is that as all the cores used atomic memory operations to safely access the queue, they ended up spending most of the time notifying each other about cache lines that need invalidating. The sync-free approach scaled perfectly, despite still working via shared memory, which after all, should still be a bottleneck. I can't quite believe that the results are so clear, so if you can think of any other effects that might cause them, please comment! Obviously, this benchmark isn't realistic because we're only measuring the overhead of the queue. Any real workload, even on a machine with 12 cores, would dwarf the overhead, and there'd be no point worrying about this effect. But would that be true on a machine with 100 cores? Still to be solved. The trouble is, you can't build many concurrent algorithms using only an SPSC queue to communicate. In particular, I can't see a way to build something as general purpose as actors on top of just SPSC queues. Fundamentally, an actor needs to be able to receive messages from multiple other actors, which seems to need an MPSC queue. I've been thinking about ways to build a sync-free MPSC queue out of multiple SPSC queues and some kind of sign-up mechanism. Hopefully I'll have something to tell you about soon, but leave a comment if you have any ideas.

  Read the article

• Launch market place with id of an application that doesn't exist in the android market place

  - by Gaurav

  Hi, I am creating an application that checks the installation of a package and then launches the market-place with its id. When I try to launch market place with id of an application say com.mybrowser.android by throwing an intent android.intent.action.VIEW with url: market://details?id=com.mybrowser.android, the market place application does launches but crashes after launch. Note: the application com.mybrowser.android doesn't exists in the market-place. MyApplication is my application. $ adb logcat I/ActivityManager( 1030): Starting activity: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=myapp.testapp/.MyApplication } I/ActivityManager( 1030): Start proc myapp.testapp for activity myapp.testapp/.MyApplication: pid=3858 uid=10047 gids={1015, 3003} I/MyApplication( 3858): [ Activity CREATED ] I/MyApplication( 3858): [ Activity STARTED ] I/MyApplication( 3858): onResume D/dalvikvm( 1109): GC freed 6571 objects / 423480 bytes in 73ms I/MyApplication( 3858): Pressed OK button I/MyApplication( 3858): Broadcasting Intent: android.intent.action.VIEW, data: market://details?id=com.mybrowser.android I/ActivityManager( 1030): Starting activity: Intent { act=android.intent.action.VIEW dat=market://details?id=com.mybrowser.android flg=0x10000000 cmp=com.android.ven ding/.AssetInfoActivity } I/MyApplication( 3858): onPause I/ActivityManager( 1030): Start proc com.android.vending for activity com.android.vending/.AssetInfoActivity: pid=3865 uid=10023 gids={3003} I/ActivityThread( 3865): Publishing provider com.android.vending.SuggestionsProvider: com.android.vending.SuggestionsProvider D/dalvikvm( 1030): GREF has increased to 701 I/vending ( 3865): com.android.vending.api.RadioHttpClient$1.handleMessage(): Handle DATA_STATE_CHANGED event: NetworkInfo: type: WIFI[], state: CONNECTED/CO NNECTED, reason: (unspecified), extra: (none), roaming: false, failover: false, isAvailable: true I/ActivityManager( 1030): Displayed activity com.android.vending/.AssetInfoActivity: 609 ms (total 7678 ms) D/dalvikvm( 1030): GC freed 10458 objects / 676440 bytes in 128ms I/MyApplication( 3858): [ Activity STOPPED ] D/dalvikvm( 3865): GC freed 3538 objects / 254008 bytes in 84ms W/dalvikvm( 3865): threadid=19: thread exiting with uncaught exception (group=0x4001b180) E/AndroidRuntime( 3865): Uncaught handler: thread AsyncTask #1 exiting due to uncaught exception E/AndroidRuntime( 3865): java.lang.RuntimeException: An error occured while executing doInBackground() E/AndroidRuntime( 3865): at android.os.AsyncTask$3.done(AsyncTask.java:200) E/AndroidRuntime( 3865): at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:273) E/AndroidRuntime( 3865): at java.util.concurrent.FutureTask.setException(FutureTask.java:124) E/AndroidRuntime( 3865): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:307) E/AndroidRuntime( 3865): at java.util.concurrent.FutureTask.run(FutureTask.java:137) E/AndroidRuntime( 3865): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068) E/AndroidRuntime( 3865): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561) E/AndroidRuntime( 3865): at java.lang.Thread.run(Thread.java:1096) E/AndroidRuntime( 3865): Caused by: java.lang.NullPointerException E/AndroidRuntime( 3865): at com.android.vending.AssetItemAdapter$ReloadLocalAssetInformationTask.doInBackground(AssetItemAdapter.java:845) E/AndroidRuntime( 3865): at com.android.vending.AssetItemAdapter$ReloadLocalAssetInformationTask.doInBackground(AssetItemAdapter.java:831) E/AndroidRuntime( 3865): at android.os.AsyncTask$2.call(AsyncTask.java:185) E/AndroidRuntime( 3865): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305) E/AndroidRuntime( 3865): ... 4 more I/Process ( 1030): Sending signal. PID: 3865 SIG: 3 I/dalvikvm( 3865): threadid=7: reacting to signal 3 I/dalvikvm( 3865): Wrote stack trace to '/data/anr/traces.txt' I/DumpStateReceiver( 1030): Added state dump to 1 crashes D/AndroidRuntime( 3865): Shutting down VM W/dalvikvm( 3865): threadid=3: thread exiting with uncaught exception (group=0x4001b180) E/AndroidRuntime( 3865): Uncaught handler: thread main exiting due to uncaught exception E/AndroidRuntime( 3865): java.lang.NullPointerException E/AndroidRuntime( 3865): at com.android.vending.controller.AssetInfoActivityController.getIdDeferToLocal(AssetInfoActivityController.java:637) E/AndroidRuntime( 3865): at com.android.vending.AssetInfoActivity.displayAssetInfo(AssetInfoActivity.java:556) E/AndroidRuntime( 3865): at com.android.vending.AssetInfoActivity.access$800(AssetInfoActivity.java:74) E/AndroidRuntime( 3865): at com.android.vending.AssetInfoActivity$LoadAssetInfoAction$1.run(AssetInfoActivity.java:917) E/AndroidRuntime( 3865): at android.os.Handler.handleCallback(Handler.java:587) E/AndroidRuntime( 3865): at android.os.Handler.dispatchMessage(Handler.java:92) E/AndroidRuntime( 3865): at android.os.Looper.loop(Looper.java:123) E/AndroidRuntime( 3865): at android.app.ActivityThread.main(ActivityThread.java:4363) E/AndroidRuntime( 3865): at java.lang.reflect.Method.invokeNative(Native Method) E/AndroidRuntime( 3865): at java.lang.reflect.Method.invoke(Method.java:521) E/AndroidRuntime( 3865): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860) E/AndroidRuntime( 3865): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) E/AndroidRuntime( 3865): at dalvik.system.NativeStart.main(Native Method) I/Process ( 1030): Sending signal. PID: 3865 SIG: 3 W/ActivityManager( 1030): Process com.android.vending has crashed too many times: killing! D/ActivityManager( 1030): Force finishing activity com.android.vending/.AssetInfoActivity I/dalvikvm( 3865): threadid=7: reacting to signal 3 D/ActivityManager( 1030): Force removing process ProcessRecord{44e48548 3865:com.android.vending/10023} (com.android.vending/10023) However, when I try to launch the market place for a package that exists in the market place say com.opera.mini.android, everything works. Log for this case: D/dalvikvm( 966): GC freed 2781 objects / 195056 bytes in 99ms I/MyApplication( 1165): Pressed OK button I/MyApplication( 1165): Broadcasting Intent: android.intent.action.VIEW, data: market://details?id=com.opera.mini.android I/ActivityManager( 78): Starting activity: Intent { act=android.intent.action.VIEW dat=market://details?id=com.opera.mini.android flg=0x10000000 cmp=com.android.vending/.AssetInfoActivity } I/AndroidRuntime( 1165): AndroidRuntime onExit calling exit(0) I/WindowManager( 78): WIN DEATH: Window{44c72308 myapp.testapp/myapp.testapp.MyApplication paused=true} I/ActivityManager( 78): Process myapp.testapp (pid 1165) has died. I/WindowManager( 78): WIN DEATH: Window{44c72958 myapp.testapp/myapp.testapp.MyApplication paused=false} D/dalvikvm( 78): GC freed 31778 objects / 1796368 bytes in 142ms I/ActivityManager( 78): Displayed activity com.android.vending/.AssetInfoActivity: 214 ms (total 22866 ms) W/KeyCharacterMap( 978): No keyboard for id 65540 W/KeyCharacterMap( 978): Using default keymap: /system/usr/keychars/qwerty.kcm.bin V/RenderScript_jni( 966): surfaceCreated V/RenderScript_jni( 966): surfaceChanged V/RenderScript( 966): setSurface 480 762 0x573430 D/ViewFlipper( 966): updateRunning() mVisible=true, mStarted=true, mUserPresent=true, mRunning=true D/dalvikvm( 978): GC freed 10065 objects / 624440 bytes in 95ms Any ideas? Thanks in advance!

  Read the article

• Amazon java.lang.VerifyError Android

  - by easycheese

  I have been trying to submit 2 separate apps into the Amazon App store but they keep being rejected. Here is the stack trace for the first: 11-05 11:14:36.488 E/AndroidRuntime(28128): FATAL EXCEPTION: AsyncTask #1 11-05 11:14:36.488 E/AndroidRuntime(28128): java.lang.RuntimeException: An error occured while executing doInBackground() 11-05 11:14:36.488 E/AndroidRuntime(28128): at android.os.AsyncTask$3.done(AsyncTask.java:200) 11-05 11:14:36.488 E/AndroidRuntime(28128): at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:273) 11-05 11:14:36.488 E/AndroidRuntime(28128): at java.util.concurrent.FutureTask.setException(FutureTask.java:124) 11-05 11:14:36.488 E/AndroidRuntime(28128): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:307) 11-05 11:14:36.488 E/AndroidRuntime(28128): at java.util.concurrent.FutureTask.run(FutureTask.java:137) 11-05 11:14:36.488 E/AndroidRuntime(28128): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068) 11-05 11:14:36.488 E/AndroidRuntime(28128): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561) 11-05 11:14:36.488 E/AndroidRuntime(28128): at java.lang.Thread.run(Thread.java:1096) 11-05 11:14:36.488 E/AndroidRuntime(28128): Caused by: java.lang.VerifyError: com.companionfree.WLThemeViewer.AmazonClientManager 11-05 11:14:36.488 E/AndroidRuntime(28128): at com.companionfree.WLThemeViewer.UpdateDBs.doInBackground(UpdateDBs.java) 11-05 11:14:36.488 E/AndroidRuntime(28128): at com.companionfree.WLThemeViewer.UpdateDBs.doInBackground(UpdateDBs.java) 11-05 11:14:36.488 E/AndroidRuntime(28128): at android.os.AsyncTask$2.call(AsyncTask.java:185) 11-05 11:14:36.488 E/AndroidRuntime(28128): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305) 11-05 11:14:36.488 E/AndroidRuntime(28128): ... 4 more And the relevant logcat for the second 10-12 15:41:48.929 D/dalvikvm( 2451): GC_FOR_MALLOC freed 8099 objects / 524416 bytes in 34ms 10-12 15:41:49.327 I/RPC ( 1563): rx thread timeout (1 clients): 10-12 15:41:49.828 I/RPC ( 1563): rx thread timeout (1 clients): 10-12 15:41:50.089 I/ActivityManager( 1563): Starting activity: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.companionfree.pushup/.MainScreen } 10-12 15:41:50.099 D/SurfaceFlinger( 1563): Layer::setBuffers(this=0xeafa50), pid=1563, w=1, h=1 10-12 15:41:50.099 D/SurfaceFlinger( 1563): Layer::setBuffers(this=0xeafa50), pid=1563, w=1, h=1 10-12 15:41:50.139 D/SurfaceFlinger( 1563): Layer::requestBuffer(this=0xeafa50), index=0, pid=1563, w=480, h=800 success 10-12 15:41:50.189 I/ActivityManager( 1563): Start proc com.companionfree.pushup for activity com.companionfree.pushup/.MainScreen: pid=2644 uid=10129 gids={1015, 3003} 10-12 15:41:50.319 I/RPC ( 1563): rx thread timeout (1 clients): 10-12 15:41:50.359 W/dalvikvm( 2644): VFY: Lcom/companionfree/pushup/WorkoutDbAdapter; is not instance of Landroid/app/Activity; 10-12 15:41:50.369 W/dalvikvm( 2644): VFY: bad arg 0 (into Landroid/app/Activity;) 10-12 15:41:50.369 W/dalvikvm( 2644): VFY: rejecting call to Lcom/amazon/android/Kiwi;.onActivityResult (Landroid/app/Activity;IILandroid/content/Intent;)Z 10-12 15:41:50.369 W/dalvikvm( 2644): VFY: rejecting opcode 0x71 at 0x0000 10-12 15:41:50.369 W/dalvikvm( 2644): VFY: rejected Lcom/companionfree/pushup/WorkoutDbAdapter;.onActivityResult (IILandroid/content/Intent;)V 10-12 15:41:50.369 W/dalvikvm( 2644): Verifier rejected class Lcom/companionfree/pushup/WorkoutDbAdapter; 10-12 15:41:50.369 D/AndroidRuntime( 2644): Shutting down VM 10-12 15:41:50.369 W/dalvikvm( 2644): threadid=1: thread exiting with uncaught exception (group=0x40025a70) 10-12 15:41:50.369 E/AndroidRuntime( 2644): FATAL EXCEPTION: main 10-12 15:41:50.369 E/AndroidRuntime( 2644): java.lang.VerifyError: com.companionfree.pushup.WorkoutDbAdapter 10-12 15:41:50.369 E/AndroidRuntime( 2644): at com.companionfree.pushup.MainScreen.onCreateMainScreen(MainScreen.java) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at com.companionfree.pushup.MainScreen.onCreate(MainScreen.java) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1088) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2802) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2859) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at android.app.ActivityThread.access$2300(ActivityThread.java:136) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2179) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at android.os.Handler.dispatchMessage(Handler.java:99) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at android.os.Looper.loop(Looper.java:143) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at android.app.ActivityThread.main(ActivityThread.java:5073) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at java.lang.reflect.Method.invokeNative(Native Method) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at java.lang.reflect.Method.invoke(Method.java:521) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:858) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616) 10-12 15:41:50.369 E/AndroidRuntime( 2644): at dalvik.system.NativeStart.main(Native Method) 10-12 15:41:50.379 W/ActivityManager( 1563): Force finishing activity com.companionfree.pushup/.MainScreen 10-12 15:41:50.399 D/SurfaceFlinger( 1563): Layer::setBuffers(this=0xeff6b8), pid=1563, w=1, h=1 10-12 15:41:50.399 D/SurfaceFlinger( 1563): Layer::setBuffers(this=0xeff6b8), pid=1563, w=1, h=1 10-12 15:41:50.419 D/SurfaceFlinger( 1563): Layer::requestBuffer(this=0xeff6b8), index=0, pid=1563, w=480, h=337 success 10-12 15:41:50.469 D/dalvikvm( 2451): GC_FOR_MALLOC freed 7889 objects / 521072 bytes in 105ms 10-12 15:41:50.819 I/RPC ( 1563): rx thread timeout (1 clients): I see the same verify error on both but I can't figure it out. The only common library used between the 2 apps is the FlurryAgent.jar for analytics. For the top app I have For the bottom app I have in the manifests. The only information I have been able to find out is about libraries (GSON) and needing to use dx but I am using Eclipse so that doesn't help. To make this more difficult, the error does NOT occur on the Android Market. Yet the testers at Amazon say that it FC 5/5 times on each of their devices (I tried using an emulator for their test devices and they worked fine). I know they use "wrapper" code around my app and I think it must be interfering in some way. Does anyone have any experience with this?

  Read the article

• [Android] Force close when trying to parse JSON with AsyncTask in the background

  - by robs

  Hello everyone, i'm new to android development and i'm playing around with json data. I managed to get the parsing to work. I want to show a ProgressDialog and i read that i need to use AsyncTask that. But for some reason i get a force close as soon as i put the same working code inside doInBackground() eventhough eclipse says everything is fine. Here is the source code: public class HomeActivity extends Activity { public class BackgroundAsyncTask extends AsyncTask<Void, Integer, Void> { ProgressDialog dialog = new ProgressDialog (HomeActivity.this); @Override protected void onPreExecute() { dialog.setMessage("Loading...please wait"); dialog.setIndeterminate(true); dialog.setCancelable(false); dialog.show(); } protected void onPostExecute() { dialog.dismiss(); } @Override protected Void doInBackground(Void... params) { try { URL json = new URL("http://www.corps-marchia.de/jsontest.php"); URLConnection tc = json.openConnection(); BufferedReader in = new BufferedReader(new InputStreamReader(tc.getInputStream())); String line; while ((line = in.readLine()) != null) { JSONArray ja = new JSONArray(line); JSONObject jo = (JSONObject) ja.get(0); TextView txtView = (TextView)findViewById(R.id.TextView01); txtView.setText(jo.getString("text")); } } catch (MalformedURLException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } catch (JSONException e) { e.printStackTrace(); } return null; } } @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); new BackgroundAsyncTask().execute(); } } Here is the error log: 01-08 12:33:48.225: ERROR/AndroidRuntime(815): FATAL EXCEPTION: AsyncTask #1 01-08 12:33:48.225: ERROR/AndroidRuntime(815): java.lang.RuntimeException: An error occured while executing doInBackground() 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.os.AsyncTask$3.done(AsyncTask.java:200) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:274) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at java.util.concurrent.FutureTask.setException(FutureTask.java:125) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:308) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at java.util.concurrent.FutureTask.run(FutureTask.java:138) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1088) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:581) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at java.lang.Thread.run(Thread.java:1019) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): Caused by: android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views. 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.view.ViewRoot.checkThread(ViewRoot.java:2932) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.view.ViewRoot.requestLayout(ViewRoot.java:629) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.view.View.requestLayout(View.java:8267) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.view.View.requestLayout(View.java:8267) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.view.View.requestLayout(View.java:8267) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.view.View.requestLayout(View.java:8267) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.view.View.requestLayout(View.java:8267) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.widget.TextView.checkForRelayout(TextView.java:5521) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.widget.TextView.setText(TextView.java:2724) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.widget.TextView.setText(TextView.java:2592) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.widget.TextView.setText(TextView.java:2567) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at net.ajzele.demo.andy1.HomeActivity$BackgroundAsyncTask.doInBackground(HomeActivity.java:52) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at net.ajzele.demo.andy1.HomeActivity$BackgroundAsyncTask.doInBackground(HomeActivity.java:1) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at android.os.AsyncTask$2.call(AsyncTask.java:185) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:306) 01-08 12:33:48.225: ERROR/AndroidRuntime(815): ... 4 more 01-08 12:33:51.605: ERROR/WindowManager(815): Activity net.ajzele.demo.andy1.HomeActivity has leaked window com.android.internal.policy.impl.PhoneWindow$DecorView@4051d0c0 that was originally added here 01-08 12:33:51.605: ERROR/WindowManager(815): android.view.WindowLeaked: Activity net.ajzele.demo.andy1.HomeActivity has leaked window com.android.internal.policy.impl.PhoneWindow$DecorView@4051d0c0 that was originally added here 01-08 12:33:51.605: ERROR/WindowManager(815): at android.view.ViewRoot.<init>(ViewRoot.java:258) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:148) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:91) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.view.Window$LocalWindowManager.addView(Window.java:424) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.app.Dialog.show(Dialog.java:241) 01-08 12:33:51.605: ERROR/WindowManager(815): at net.ajzele.demo.andy1.HomeActivity$BackgroundAsyncTask.onPreExecute(HomeActivity.java:33) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.os.AsyncTask.execute(AsyncTask.java:391) 01-08 12:33:51.605: ERROR/WindowManager(815): at net.ajzele.demo.andy1.HomeActivity.onCreate(HomeActivity.java:72) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1586) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1638) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.app.ActivityThread.access$1500(ActivityThread.java:117) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:928) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.os.Handler.dispatchMessage(Handler.java:99) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.os.Looper.loop(Looper.java:123) 01-08 12:33:51.605: ERROR/WindowManager(815): at android.app.ActivityThread.main(ActivityThread.java:3647) 01-08 12:33:51.605: ERROR/WindowManager(815): at java.lang.reflect.Method.invokeNative(Native Method) 01-08 12:33:51.605: ERROR/WindowManager(815): at java.lang.reflect.Method.invoke(Method.java:507) 01-08 12:33:51.605: ERROR/WindowManager(815): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839) 01-08 12:33:51.605: ERROR/WindowManager(815): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597) 01-08 12:33:51.605: ERROR/WindowManager(815): at dalvik.system.NativeStart.main(Native Method) Any hints? I hope you can help me out ive searched the net and didnt find any working solution...Thanks in advance

  Read the article

• Limit number of simultaneous connections squid makes to a single server

  - by Ben Voigt

  Note: I am asking about outbound concurrent connection limits, not inbound, which is sufficiently covered on existing questions Modern browsers typically open a large number of simultaneous connections, to take advantage of the fact that TCP fairly shares bandwidth between connections. Of course, this doesn't result in fair sharing between users, so some servers have started penalizing hosts which open too many connections. This limit can be configured client-side (e.g. IE MaxConnectionsPerServer, Firefox network.http.max-connections-per-server), but the method differs for each browser and version, and many users aren't competent to adjust it themselves. So we turn to a squid transparent HTTP proxy for central management of HTTP download. How can the number of simultaneous connections from squid to a remote webserver be limited, so the webserver doesn't perceive it as abuse of concurrent connections? Ideally the limit would be per source address. Squid should accept virtually unlimited concurrent requests from the client browser, and issue them sequentially to the remote server, only N at a time, delaying (but not dropping) the others.

  Read the article

• How can I determine Breaking point of my Web application using JMeter?

  - by Gopu Alakrishna

  How can I determine Breaking point of my Web application using JMeter? I have executed the JMeter Testplan with different concurrent users load. EX. 300 users(0% error), 400 users(7% error in a sample, 5% error in another sample), 500 users(more than 10% error in 4 out of 6 samples). At What value of % Error, I can say system reached the Breaking point.I used concurrent users 300, 400, 500 in a PHP website. Should I consider any other parameter to determine breaking point. How many maximum concurrent users my application can support?

  Read the article

• problem with send me log

  - by Lynnooi

  Hi, I had try to implement the send me log feature into my apps but I can't get it right. Can anyone please help me with it? In the logcat, it shows the errors: 03-29 21:23:37.636: ERROR/AndroidRuntime(820): Uncaught handler: thread AsyncTask #1 exiting due to uncaught exception 03-29 21:23:37.726: ERROR/AndroidRuntime(820): java.lang.RuntimeException: An error occured while executing doInBackground() 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at android.os.AsyncTask$3.done(AsyncTask.java:200) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:234) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:258) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at java.util.concurrent.FutureTask.run(FutureTask.java:122) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:648) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:673) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at java.lang.Thread.run(Thread.java:1058) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): Caused by: java.lang.NullPointerException 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at resonet.android.androidgallery.helloAndroid$CheckForceCloseTask.doInBackground(helloAndroid.java:1565) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at resonet.android.androidgallery.helloAndroid$CheckForceCloseTask.doInBackground(helloAndroid.java:1) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at android.os.AsyncTask$2.call(AsyncTask.java:185) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:256) 03-29 21:23:37.726: ERROR/AndroidRuntime(820): ... 4 more Thanks. Here is my code: public class helloAndroid extends Activity implements OnClickListener { public static final int DIALOG_SEND_LOG = 345350; protected static final int DIALOG_PROGRESS_COLLECTING_LOG = 3255; protected static final int DIALOG_FAILED_TO_COLLECT_LOGS = 3535122; private static final int DIALOG_REPORT_FORCE_CLOSE = 3535788; private LogCollector mLogCollector; public void onCreate(Bundle savedInstanceState) { requestWindowFeature(Window.FEATURE_NO_TITLE); Bundle b = this.getIntent().getExtras(); s = b.getString("specialValue").trim(); String xmlURL = ""; CheckForceCloseTask task = new CheckForceCloseTask(); task.execute(); } private void throwException() { throw new NullPointerException(); } @Override protected Dialog onCreateDialog(int id) { Dialog dialog = null; switch (id) { case DIALOG_SEND_LOG: case DIALOG_REPORT_FORCE_CLOSE: Builder builder = new AlertDialog.Builder(this); String message; if (id==DIALOG_SEND_LOG) message = "Do you want to send me your logs?"; else message = "It appears this app has been force-closed, do you want to report it to me?"; builder.setTitle("Warning") .setIcon(android.R.drawable.ic_dialog_alert) .setMessage(message) .setPositiveButton("Yes", this) .setNegativeButton("No", this); dialog = builder.create(); break; case DIALOG_PROGRESS_COLLECTING_LOG: ProgressDialog pd = new ProgressDialog(this); pd.setTitle("Progress"); pd.setMessage("Collecting logs..."); pd.setIndeterminate(true); dialog = pd; break; case DIALOG_FAILED_TO_COLLECT_LOGS: builder = new AlertDialog.Builder(this); builder.setTitle("Error") .setMessage("Failed to collect logs.") .setNegativeButton("OK", null); dialog = builder.create(); } return dialog; } class CheckForceCloseTask extends AsyncTask { @Override protected Boolean doInBackground(Void... params) { return mLogCollector.hasForceCloseHappened(); } @Override protected void onPostExecute(Boolean result) { if (result) { showDialog(DIALOG_REPORT_FORCE_CLOSE); } else Toast.makeText(getApplicationContext(), "No force close detected.", Toast.LENGTH_LONG).show(); } } public void onClick(DialogInterface dialog, int which) { switch (which) { case DialogInterface.BUTTON_POSITIVE: new AsyncTask() { @Override protected Boolean doInBackground(Void... params) { return mLogCollector.collect(); } @Override protected void onPreExecute() { showDialog(DIALOG_PROGRESS_COLLECTING_LOG); } @Override protected void onPostExecute(Boolean result) { dismissDialog(DIALOG_PROGRESS_COLLECTING_LOG); if (result) mLogCollector.sendLog("[email protected]", "Error Log", "Preface\nPreface line 2"); else showDialog(DIALOG_FAILED_TO_COLLECT_LOGS); } }.execute(); } dialog.dismiss(); } }

  Read the article

• Play! Framework 1.2.4 --- C3P0 settings to avoid Communications link failure do to idle time

  - by HelpMeStackOverflowMyOnlyHope

  I'm trying to customize my C3P0 settings to avoid the error shown at the bottom of this post. It was suggested at this url --- http://make-it-open.blogspot.com/2008/12/sql-error-0-sqlstate-08s01.html --- to adjust the settings as follows: In hibernate.cfg.xml, write <property name="c3p0.min_size">5</property> <property name="c3p0.max_size">20</property> <property name="c3p0.timeout">1800</property> <property name="c3p0.max_statements">50</property> Then create "c3p0.properties" in your root classpath folder and write c3p0.testConnectionOnCheckout=true c3p0.acquireRetryDelay=1000 c3p0.acquireRetryAttempts=1 I've tried to make those adjustments following the direction of the Play! Framework documentation, where they say use "db.pool..." as follows: db.pool.timeout=1800 db.pool.maxSize=15 db.pool.minSize=5 db.pool.initialSize=5 db.pool.acquireRetryAttempts=1 db.pool.preferredTestQuery=SELECT 1 db.pool.testConnectionOnCheckout=true db.pool.acquireRetryDelay=1000 db.pool.maxStatements=50 Are those settings not going to work? Should I be trying to set them in a different way? With those settings I still get the error shown below, that is due to to long of a idle time. Complete Stack Trace of Error: 23:00:44,932 WARN ~ SQL Error: 0, SQLState: 08S01 2012-04-13T23:00:44+00:00 app[web.1]: 23:00:44,932 ERROR ~ Communications link failure 2012-04-13T23:00:44+00:00 app[web.1]: 2012-04-13T23:00:44+00:00 app[web.1]: The last packet successfully received from the server was 274,847 milliseconds ago. The last packet sent successfully to the server was 7 milliseconds ago. 2012-04-13T23:00:44+00:00 app[web.1]: 23:00:44,934 ERROR ~ Why the driver complains here? 2012-04-13T23:00:44+00:00 app[web.1]: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed.Connection was implicitly closed by the driver. 2012-04-13T23:00:44+00:00 app[web.1]: at com.mysql.jdbc.Util.handleNewInstance(Util.java:407) 2012-04-13T23:00:44+00:00 app[web.1]: at com.mysql.jdbc.Util.getInstance(Util.java:382) 2012-04-13T23:00:44+00:00 app[web.1]: at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1013) 2012-04-13T23:00:44+00:00 app[web.1]: at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) 2012-04-13T23:00:44+00:00 app[web.1]: at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:982) 2012-04-13T23:00:44+00:00 app[web.1]: at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927) 2012-04-13T23:00:44+00:00 app[web.1]: at com.mysql.jdbc.ConnectionImpl.throwConnectionClosedException(ConnectionImpl.java:1213) 2012-04-13T23:00:44+00:00 app[web.1]: at com.mysql.jdbc.ConnectionImpl.getMutex(ConnectionImpl.java:3101) 2012-04-13T23:00:44+00:00 app[web.1]: at com.mysql.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:4975) 2012-04-13T23:00:44+00:00 app[web.1]: at org.hibernate.jdbc.BorrowedConnectionProxy.invoke(BorrowedConnectionProxy.java:74) 2012-04-13T23:00:44+00:00 app[web.1]: at $Proxy49.setAutoCommit(Unknown Source) 2012-04-13T23:00:44+00:00 app[web.1]: at play.db.jpa.JPAPlugin.closeTx(JPAPlugin.java:368) 2012-04-13T23:00:44+00:00 app[web.1]: at play.db.jpa.JPAPlugin.onInvocationException(JPAPlugin.java:328) 2012-04-13T23:00:44+00:00 app[web.1]: at play.plugins.PluginCollection.onInvocationException(PluginCollection.java:447) 2012-04-13T23:00:44+00:00 app[web.1]: at play.Invoker$Invocation.onException(Invoker.java:240) 2012-04-13T23:00:44+00:00 app[web.1]: at play.jobs.Job.onException(Job.java:124) 2012-04-13T23:00:44+00:00 app[web.1]: at play.jobs.Job.call(Job.java:163) 2012-04-13T23:00:44+00:00 app[web.1]: at play.jobs.Job$1.call(Job.java:66) 2012-04-13T23:00:44+00:00 app[web.1]: at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) 2012-04-13T23:00:44+00:00 app[web.1]: at java.util.concurrent.FutureTask.run(FutureTask.java:166) 2012-04-13T23:00:44+00:00 app[web.1]: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) 2012-04-13T23:00:44+00:00 app[web.1]: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) 2012-04-13T23:00:44+00:00 app[web.1]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 2012-04-13T23:00:44+00:00 app[web.1]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 2012-04-13T23:00:44+00:00 app[web.1]: at java.lang.Thread.run(Thread.java:636) 2012-04-13T23:00:44+00:00 app[web.1]: Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

  Read the article

• New Whitepaper: Best Practices for Gathering EBS Database Statistics

  - by Elke Phelps (Oracle Development)

  Most Oracle Applications DBAs and E-Business Suite users understand the importance of accurate database statistics.  Missing, stale or skewed statistics can adversely affect performance.  Oracle E-Business Suite statistics should only be gathered using FND_STATS or the Gather Statistics concurrent request. Gathering statistics with DBMS_STATS or the desupported ANALYZE command may result in suboptimal executions plans for E-Business Suite. Our E-Business Suite Performance Team has been busy implementing and testing new features for gathering statistics using FND_STATS in Oracle E-Business Suite databases.  The new features and guidelines for when and how to gather statistics are published in the following whitepaper: Best Practices for Gathering Statistics with Oracle E-Business Suite (Note 1586374.1) The new white paper details the following options for gathering statistics using FND_STATS and the Gather Statistics concurrent request:: History Mode - backup existing statistics prior to gather new statistics GATHER_AUTO Option - gather statistics for tables based upon % change Histograms - collect statistics for histograms AUTO Sampling - use the new FND_STATS feature that supports the AUTO option for using AUTO sample size Extended Statistics - use the new FND_STATS feature that supports the creation of column groups and automatic statistics collection on the column groups when table statistics are gathered Incremental Statistics - gather incremental statistics for partitioned tables The new white paper also includes examples and performance test cases for the following: Extended Optimizer Statistics Incremental Statistics Gathering Concurrent Statistics Gathering This white paper includes details about the standalone Oracle E-Business Suite Release 11i and 12 patches that are required to take advantage of this new functionality. Your feedback is welcome We would be very interested in hearing about your experiences with these new options for gathering statistics.  Please feel free to post your comments here or drop us a line privately.Related Oracle OpenWorld 2013 Session Getting Optimal Performance from Oracle E-Business Suite (CON8485) Related My Oracle Support Notes Collecting Statistics with Oracle EBS 11i and R12 (Note 368252.1) Non-EBS Related Blogs, White Papers and My Oracle Support Notes  Oracle Optimizer Blog Understanding Optimizer Statistic (white paper) Fixed Objects Statistics(GATHER_FIXED_OBJECTS_STATS) Considerations (Note 798257.1)

  Read the article

• New Release of Oracle Berkeley DB

  - by Eric Jensen

  We are pleased to announce that a new release of Oracle Berkeley DB, version 11.2.5.2.28, is available today. Our latest release includes yet more value added features for SQLite users, as well as several performance enhancements and new customer-requested features to the key-value pair API.  We continue to provide technology leadership, features and performance for SQLite applications.  This release introduces additional features that are not available in native SQLite, and adds functionality allowing customers to create richer, more scalable, more concurrent applications using the Berkeley DB SQL API. This release is compelling to Oracle’s customers and partners because it: delivers a complete, embeddable SQL92 database as a library under 1MB size drop-in API compatible with SQLite version 3 no-oversight, zero-touch database administration industrial quality, battle tested Berkeley DB B-TREE for concurrent transactional data storage New Features Include: MVCC support for even higher concurrency direct SQL support for HA/replication transactionally protected Sequence number generation functions lower memory requirements, shared memory regions and faster/smaller memory on startup easier B-TREE page size configuration with new ''db_tuner" utility New Key-Value API Features Include: HEAP access method for constrained disk-space applications (key-value API) faster QUEUE access method operations for highly concurrent applications -- up 2-3X faster! (key-value API) new X/open compliant XA resource manager, easily integrated with Oracle Tuxedo (key-value API) additional HA/replication management and communication options (key-value API) and a lot more! BDB is hands-down the best edge, mobile, and embedded database available to developers. Downloads available today on the Berkeley DB download pageProduct Documentation

  Read the article

• Timeout Considerations for Solicit Response

  - by Michael Stephenson

  Background One of the clients I work with had been experiencing some issues for a while surrounding web service timeouts.  It's been a little challenging to work through the problems due to limitations in the diagnostic information available from one of the applications, but I learned some interesting things while troubleshooting the problem which don't seem to have been discussed much in the community so I thought I'd share my findings. In the scenario we have BizTalk trying to make calls to a .net web service which was exposed as a WSE 2 endpoint.  In the process BizTalk will try to make a large number of concurrent web service calls to the application, and the backend application has more than enough infrastructure and capability to handle the load. We have configured the <ConnectionManagement> section of the BizTalk configuration file to support up to 100 concurrent connections from each of our 2 BizTalk send servers to the web servers of the application. The problem we were facing was that the BizTalk side was reporting a significant number of timeouts when calling the web service.   One of the biggest issues was the challenge of being able to correlate a message from BizTalk to the IIS log in the .net application and the custom logs in the application especially when there was a fairly large number of servers hosting the web services.  However the key moment came when we were able to identify a specific call which had taken 40 seconds to execute on the server (yes a long time I know but that's a different story!).  Anyway we were able to identify that this had timed out on the BizTalk side.  Based on the normal 2 minute timeout we knew something unexpected was going on. From here I decided to do some experimentation and I wanted to start outside of BizTalk because my hunch was this was not a BizTalk behaviour but something which was being highlighted by BizTalk because of our large load.     Server-side - Sample Web Service To begin with I created a sample web service.  Nothing special just a vanilla asmx web service hosted in IIS6 on Windows 2003 Standard Edition.  The web service is just a hello world style web service as shown in the below picture.  The only key feature is that the server side web method has a 30 second sleep in it and will trace out some information before and after the thread is set to sleep.      In the configuration for this web service there again is nothing special it's pretty much the most plain simple web service you could build. Client-Side To begin looking at what was happening with our example I created a number of different ways to consume the web service. SoapHttpClientProtocol Example I created a small application which would use a normal proxy generated to call the web service.  It would iterate around a loop and make calls using the begin/end methods so I can do this asynchronously.  I would do a loop of 20 calls with the ConnectionManager configuration section supporting only 5 concurrent connections to the server.     <connectionManagement> <remove address="*"/> <add address = "*" maxconnection = "12" /> <add address = "http://<ServerName>" maxconnection = "5" />                         </connectionManagement> </system.net>     The below picture shows an example of the service calling code, key points are: I have configured the timeout of 40 seconds for the proxy I am using the asynchronous methods on the proxy to call the web service         The Test I would run the client and execute 21 calls to the web service.   The Results  Below is the client side trace showing what's happening on the client. In the below diagram is the web service side trace showing what's happening on the server Some observations on the results are: All of the calls were successful from the clients perspective You could see the next call starting on the server as soon as the previous one had completed Calls took significantly longer than 40 seconds from the start of our call to the return. In fact call 20 took 2 minutes and 30 seconds from the perspective of my code to execute even though I had set the timeout to 40 seconds     WSE 2 Sample In the second example I used the exact same code to call the web service again with a single exception that I modified the web service proxy to derive from WebServiceClient protocol which is part of WSE 2 (using SP3).  The below picture shows the basic code and the key points are: I have configured the timeout of 40 seconds for the proxy I am using the asynchronous methods on the proxy to call the web service        The Test This test would execute 21 calls from the client to the web service.   The Results  The below trace is from the client side: The below trace is from the server side:   Some observations on the trace results for this scenario are: With call 4 if you look at the server side trace it did not start executing on the server for a number of seconds after the other 4 initial calls which were accepted by the server. I re-ran the test and this happened a couple of times and not on most others so at this point I'm just putting this down to something unexpected happening on the development machine and we will leave this observation out of scope of this article. You can see that the client side trace statement executed almost immediately in all cases All calls after the initial few calls would timeout On the client side the calls that did timeout; timed out in a longer duration than the 40 seconds we set as the timeout You can see that as calls were completing on the server the next calls were starting to come through The calls that timed out on the client did actually connect to the server and their server side execution completed successfully     Elaboration on the findings Based on the above observations I have drawn the below sequence diagram to illustrate conceptually what is happening.  Everything except the final web service object is on the client side of the call. In the diagram below I've put two notes on the Web Service Proxy to show the two different places where the different base classes seem to start their timeout counters. From the earlier samples we can work out that the timeout counter for the WSE web service proxy starts before the one for the SoapHttpClientProtocol proxy and the WSE one includes the time to get a connection from the pool; whereas the Soap proxy timeout just covers the method execution. One interesting observation is if we rerun the above sample and increase the number of calls from 21 to 100,000 then for the WSE sample we will see a similar pattern where everything after the first few calls will timeout on the client as soon as it makes a connection to the server whereas the soap proxy will happily plug away and process all of the calls without a single timeout. I have actually set the sample running overnight and this did happen. At this point you are probably thinking the same thoughts I was at the time about the differences in behaviour and which is right and why are they different? I'm not sure there is a definitive answer to this in the documentation, or at least not that I could find! I think you just have to consider that they are different and they could have different effects depending on your messaging solution. In lots of situations this is just not an issue as your concurrent requests doesn't get to the situation where you end up throttling the web service calls on the client side, however this is definitely more common with an integration broker such as BizTalk where you often have high throughput requirements.  Some of the considerations you should make Based on this behaviour you should be aware of the following: In a .net application if you are making lots of concurrent web service calls from an application in an asynchronous manner your user may thing they are experiencing poor performance but you think your web service is working well. The problem could be that the client will have a default of 2 connections to remote servers so you should bear this in mind When you are developing a BizTalk solution or a .net solution with the WSE 2 stack you may experience timeouts under load and throttling the number of connections using the max connections element in the configuration file will not help you For an application using WSE2 or SoapHttpClientProtocol an expired timeout will not throw an error until after a connection to the server has been made so you should consider this in your transaction and durability patterns     Our Work Around In the short term for our specific scenario we know that we can handle this by just increasing our timeout value.  There is only a specific small window when we get lots of concurrent traffic that causes this scenario so we should be able to increase the timeout to take into consideration the additional client side wait, and on the odd occasion where we do get a timeout the BizTalk send port retry will handle this. What was causing our original problem was that for that short window we were getting a lot of retries which significantly increased the load on our send servers and highlighted the issue.  Longer Term Solution As a longer term solution this really gives us more ammunition to argue a migration to WCF. The application we are calling has some factors which limit the protocols we can use but with WCF we would have more control on the various timeout options because in WCF you can configure specific parts of the timeout. Summary I've had this blog post on my to do list for ages but hopefully it will be useful to some people to just understand this behaviour and to possibly help you with some performance issues you may have. I do not believe there is too much in the way of documentation particularly around WSE2 and ASMX in this area so again another bit of ammunition for migrating to WCF. I'll try to do a follow up post with the sample for WCF to show how this changes things.

  Read the article

< Previous Page | 8 9 10 11 12 13 14 15 16 17 18 19  | Next Page >